Truncated /etc/gettytab



  • My syslog was swamped with messages like:

    Jan 3 10:24:35 	getty[84645]: getty: unknown gettytab entry 'Pc'
    Jan 3 10:24:35 	getty[84645]: getty: unknown gettytab entry 'Pc'
    Jan 3 10:24:35 	getty[84645]: tcsetattr /dev/console: Operation not supported
    Jan 3 10:24:35 	getty[84645]: tcsetattr /dev/console: Operation not supported
    Jan 3 10:24:35 	init: getty repeating too quickly on port /dev/console, sleeping 30 secs
    Jan 3 10:24:35 	init: getty repeating too quickly on port /dev/console, sleeping 30 secs
    
    

    It turned out that /etc/gettytab was just a little short one (it only had the first 3 lines of the normal full one).
    This issue gets reported occasionally - e.g. http://forum.pfsense.org/index.php/topic,21765.0.html and http://forum.pfsense.org/index.php/topic,41680.0.html
    This Alix 2D13 has a bunch of OpenVPN servers on it, and currently it runs out of real memory during bootup (that issue is in another forum thread and I plan to get around to sorting out the nanoBSD low-memory and multiple OpenVPN servers startup sequence some day!). A process (or 2…) get killed "randomly" during boot with "out of swap space" (="out of real memory").
    pfsense-utils.inc auto_login() runs at every boot and rewrites /etc/gettytab to set or clear the console auto-login state. Unfortunately, it seems that the "out of swap space" happened during rewriting of /etc/gettytab !
    The recovery is to put back the default gettytab:

    cp /nano/base/etc/gettytab /etc/gettytab
    

    It would be nicer if auto_login() checked first to see if /etc/gettytab already had the correct entries in it for enabling/disabling console auto login, matching the config setting. Then it could only rewrite the file when needed. In theory it only needs rewriting at boot time after a firmware upgrade. When the setting is modified from the WebGUI, /etc/gettytab is updated immediately, so will be correct at boot time.
    I have a proposed change to pfsense-utils.inc that I will submit in GitHub. It should avoid the possibility of this problem by avoiding unnecessary rewriting of /etc/gettytab at boot time.





  • Thanks! Yeah that's been a rare but recurring issue for a long time. Could you test the same change on RELENG_2_0 and make a merge request for that as well? May just be able to cherry-pick it over to RELENG_2_0. We'll be rolling a 2.0.3 soon, would like for that to make it.



  • OK, no trouble - I have a 2.0.2 system at home. Will fire that up tonight, merge the changes into the 2.0.2 version of pfsense-utils.inc, test and submit a pull request.
    Edit: pfsense-utils.inc version done and tested for 2.0.2 - pull request is in GitHub.


Locked