I just updated my kernel on an Ubuntu 9.10 system from 2.6.32.1 to 2.6.33.5, and everything seemed to go well, except now my system log is getting flooded with errors from getty:
Jul 25 11:01:54 kobol getty[2414]: /dev/tty4: cannot open as standard input: No such device
Jul 25 11:01:54 kobol getty[2415]: /dev/tty2: cannot open as standard input: No such device
Jul 25 11:01:54 kobol getty[2416]: /dev/tty6: cannot open as standard input: No such device
Jul 25 11:01:54 kobol getty[2417]: /dev/tty3: cannot open as standard input: No such device
Jul 25 11:01:54 kobol getty[2418]: /dev/tty5: cannot open as standard input: No such device
Jul 25 11:01:54 kobol init: tty4 main process (2409) terminated with status 1
Jul 25 11:01:54 kobol init: tty4 main process ended, respawning
Jul 25 11:01:54 kobol init: tty2 main process (2410) terminated with status 1
Jul 25 11:01:54 kobol init: tty2 main process ended, respawning
Jul 25 11:01:54 kobol init: tty6 main process (2411) terminated with status 1
Jul 25 11:01:54 kobol init: tty6 main process ended, respawning
Jul 25 11:01:54 kobol init: tty3 main process (2412) terminated with status 1
Jul 25 11:01:54 kobol init: tty3 main process ended, respawning
Jul 25 11:01:54 kobol init: tty5 main process (2413) terminated with status 1
Jul 25 11:01:54 kobol init: tty5 main process ended, respawning
Any idea what is causing this and how to get it to stop? I realize its not a critical issue, but it's still annoying that it's constantly happening (and filling up log files) and I don't know why.
UPDATE: This is the listing for my tty devices, the permissions of which seem to be reset on reboot
crw------- 1 root root 4, 0 2010-07-26 10:00 /dev/tty1
crw--w---- 1 root tty 4, 1 2010-07-26 10:00 /dev/tty2
crw--w---- 1 root tty 4, 2 2010-07-26 10:00 /dev/tty3
crw--w---- 1 root tty 4, 3 2010-07-26 10:00 /dev/tty4
crw--w---- 1 root tty 4, 4 2010-07-26 10:00 /dev/tty5
crw--w---- 1 root tty 4, 5 2010-07-26 10:00 /dev/tty6
crw--w---- 1 root tty 4, 6 2010-07-26 10:00 /dev/tty7
crw--w---- 1 root tty 4, 7 2010-07-26 10:00 /dev/tty8
And the init script for tty1:
# tty1 - getty
#
# This service maintains a getty on tty1 from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
respawn
exec /sbin/getty -8 38400 tty1
And the (practically identical) init scripts for tty2-tty6:
# tty2 - getty
#
# This service maintains a getty on tty2 from the point the system is
# started until it is shut down again.
start on runlevel [23]
stop on runlevel [!23]
respawn
exec /sbin/getty -8 38400 tty2
UPDATE 2: Permissions for the init scripts follow...
-rw-r--r-- 1 root root 228 2009-12-10 11:00 /etc/init/tty1.conf
-rw-r--r-- 1 root root 213 2009-12-10 11:00 /etc/init/tty2.conf
-rw-r--r-- 1 root root 213 2009-12-10 11:00 /etc/init/tty3.conf
-rw-r--r-- 1 root root 213 2009-12-10 11:00 /etc/init/tty4.conf
-rw-r--r-- 1 root root 213 2009-12-10 11:00 /etc/init/tty5.conf
-rw-r--r-- 1 root root 213 2009-12-10 11:00 /etc/init/tty6.conf
A grep of running getty instances shows this:
$ ps auxww|grep [g]etty
root 2228 0.0 0.2 5992 604 ? Ss+ 10:00 0:00 /sbin/getty -8 38400 tty1
root 6352 0.8 0.2 5988 688 ? Ss 11:06 0:00 /sbin/getty -8 38400 tty3
root 6355 0.5 0.2 5988 684 ? Ss 11:06 0:00 /sbin/getty -8 38400 tty4
root 6356 0.5 0.2 5988 684 ? Ss 11:06 0:00 /sbin/getty -8 38400 tty6
root 6357 0.8 0.2 5988 684 ? Ss 11:06 0:00 /sbin/getty -8 38400 tty2
root 6358 0.6 0.2 5988 684 ? Ss 11:06 0:00 /sbin/getty -8 38400 tty5
UPDATE 3: After downgrading to 2.6.32.1 the errors disappeared. I recently upgraded again to 2.6.34.1 and they showed up again. I'm superbly baffled now.
I had this same issue with a Rackspace-hosted server that I recently upgraded to Ubuntu 12.04 LTS. My /var/log/auth.log file was getting flooded with
All I did was remove (after backing up) the following files:
After I rebooted the problem was solved. No more noise in the log file and the Rackspace console still works, although with only one virtual terminal. (I never use virtual terminals on the console anyway.)
Look to see if those devices exist:
If they don't then do this:
That command name is in all caps. The
-n
switch (for "no action") will show you the actionsMAKEDEV
will take. If you are satisfied with what it proposes, then change the-n
to-v
(for "verbose") and run it again.