My syslog was swamped with messages like:
Jan 3 10:24:35 getty: getty: unknown gettytab entry 'Pc' Jan 3 10:24:35 getty: getty: unknown gettytab entry 'Pc' Jan 3 10:24:35 getty: tcsetattr /dev/console: Operation not supported Jan 3 10:24:35 getty: 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.
change committed in GitHub - https://github.com/bsdperimeter/pfsense/commit/adc0f2fe63c53182012d8d928181156c9bc6855e
cmb last edited by
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.