Hide Forgot
I noticed that since today something goes wrong with getty handling. I was frequently switched to the tty terminal. Also syslog was populated with the following lines: Jan 16 12:52:23 work systemd[1]: getty holdoff time over, scheduling restart. Jan 16 12:56:29 work systemd[1]: getty holdoff time over, scheduling restart. Jan 16 17:32:33 work systemd[1]: getty holdoff time over, scheduling restart. Jan 16 17:35:56 work systemd[1]: getty holdoff time over, scheduling restart. Jan 16 17:37:19 work systemd[1]: getty holdoff time over, scheduling restart. Jan 16 17:38:36 work systemd[1]: getty holdoff time over, scheduling restart. Jan 16 17:39:39 work systemd[1]: getty holdoff time over, scheduling restart. Jan 16 17:41:11 work systemd[1]: getty holdoff time over, scheduling restart. Jan 16 17:42:53 work systemd[1]: getty holdoff time over, scheduling restart. Jan 16 17:44:10 work systemd[1]: getty holdoff time over, scheduling restart. Jan 16 17:45:01 work systemd[1]: getty holdoff time over, scheduling restart. Nothing suspicious was found in Xorg.log though except the following which I believe is normal (since systemd switches me to the VT so Xorg just logs this event): [ 17498.645] (II) AIGLX: Suspending AIGLX clients for VT switch [ 17498.645] (II) AIGLX: Resuming AIGLX clients after VT switch [ 17498.706] (II) intel(0): EDID vendor "SAM", prod id 286 [ 17498.706] (II) intel(0): Using hsync ranges from config file [ 17498.706] (II) intel(0): Using vrefresh ranges from config file [ 17498.706] (II) intel(0): Printing DDC gathered Modelines: [ 17498.706] (II) intel(0): Modeline "1280x1024"x0.0 108.00
What's the systemd version? Is this a regression after an update?
(In reply to comment #1) > What's the systemd version? Is this a regression after an update? I can't say for sure that this is a regression - I'm downgrading to previous 37-3 now. This happened two times today (with vt6 and with vt2) - each time was a series of switches on a short period which ends as soon as I logged in a given getty.
Ok, now I much more certain that this is a regression in systemd-37-6+. When I had downgraded to 37-3 yesterday, this issue was gone. And not so long ago I upgraded to 37-7 from updates-testing and I just received another one switch: Jan 17 15:44:35 work yum[22543]: Updated: systemd-37-7.fc16.x86_64 Jan 17 15:44:36 work yum[22543]: Updated: systemd-units-37-7.fc16.x86_64 Jan 17 15:44:36 work yum[22543]: Updated: systemd-sysv-37-7.fc16.x86_64 Jan 17 15:44:36 work systemd[1]: Reloading. ... Jan 17 17:20:20 work systemd-logind[22609]: Removed session 8. Jan 17 17:20:20 work systemd[1]: getty holdoff time over, scheduling restart.
No idea what's happening. The "getty holdoff time over" message itself does not imply a problem. A detailed log would help. Please boot with 'log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg' and when you reproduce the problem, save the output of the dmesg command and attach it here.
Peter, noone else has reported anything similar so far. We could really use that log from your system.
Created attachment 915410 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Created attachment 915411 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Please, for long listings use attachments. Check /var/log/secure. Are there any unusual "FAILED LOGIN" messages? What do these commands say?: cat /sys/class/tty/tty0/active ps -eo tty,pid,cmd | grep ^tty
Created attachment 559431 [details] /var/log/secure date:20120204
~>cat /sys/class/tty/tty0/active tty2 ~>ps -eo tty,pid,cmd | grep ^tty tty6 1273 /sbin/agetty tty6 38400 tty4 1274 /sbin/agetty tty4 38400 tty3 1275 /sbin/agetty tty3 38400 tty5 1277 /sbin/agetty tty5 38400 tty2 3297 /bin/login --
Also noticed, that ctrl+alt+fnX key sequence does nothing, except when I am switching away from the tty2 after random switching to that. I do not know if these are related. I have found couple of bugs reported about nonfunctional ctrl+alt+fnX, but no working solution so far.
There are indeed a few unusual FAILED LOGIN messages, e.g.: FAILED LOGIN 1 FROM (null) FOR su -, User not known to the underlying authentication module My theory is that you typed the command "su -" into a graphical terminal emulator (Konsole/xterm/...) and it somehow ended up as being passed as input to a login process running on tty2. Then after you've typed some more text, it got interpreted as the password for the user called "su -". The login obviously failed, the error message got logged, the login process exited, the getty exited. Then systemd respawned the service with the side-effect of resetting the terminal. The reset is what you observe as a switch to the getty. Now the root problem is of course not that systemd resets the terminal for the getty service, but that your keyboard input goes to the tty in the first place. (In reply to comment #10) > ~>cat /sys/class/tty/tty0/active > tty2 Here you are working in your X session, while tty2 is the active console... > ~>ps -eo tty,pid,cmd | grep ^tty > tty6 1273 /sbin/agetty tty6 38400 > tty4 1274 /sbin/agetty tty4 38400 > tty3 1275 /sbin/agetty tty3 38400 > tty5 1277 /sbin/agetty tty5 38400 > tty2 3297 /bin/login -- ... and at the same time a login process runs on tty2 too. Looks like a problem in the way Xorg is started on your system. I see you have some KDE-related processes. Do you use kdm for your graphical login? Do you have a file /etc/X11/xorg.conf? Could you attach your /var/log/Xorg.0.log?
(In reply to comment #11) > Also noticed, that ctrl+alt+fnX key sequence does nothing, except when I am > switching away from the tty2 after random switching to that. I do not know if > these are related. I have found couple of bugs reported about nonfunctional > ctrl+alt+fnX, but no working solution so far. The same for me. I suspect this issue is also related. Someone grabs our keysyms and interprets them differently.(In reply to comment #12) > Looks like a problem in the way Xorg is started on your system. > I see you have some KDE-related processes. Do you use kdm for your graphical > login? > Do you have a file /etc/X11/xorg.conf? > Could you attach your /var/log/Xorg.0.log? I'm using xdm. And here is my Xorg.0.log (attached).
Created attachment 559580 [details] Peter Lemenkov's Xorg.0.log
Created attachment 559581 [details] Peter Lemenkov's ~/.xsession file My ~/.xsession
(In reply to comment #14) > Peter Lemenkov's Xorg.0.log It shows: [ 14.091] (--) using VT number 2 Peter, try changing the line in /etc/X11/xdm/Xservers to say this and see if it helps: :0 local /usr/bin/X :0 vt1
Created attachment 559732 [details] /var/log/Xorg.0.log of Marko Kosunen
Currently I do not have /etc/X11/xorg.conf file.
Marko, what's your display manager? kdm, gdm, xdm, ... If you're not sure, show me the output of "systemctl status prefdm.service".
From /var/log/secure Following sequence is repeated quite often Feb 6 21:01:09 treehugger login: pam_unix(login:auth): check pass; user unknown Feb 6 21:01:09 treehugger login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= Feb 6 21:01:11 treehugger login: FAILED LOGIN 1 FROM (null) FOR qless , User not known to the underlying authentication module To me it seems, that for some unknown reason, authentication sequence is started in tty2, and whatever you happen to be writing at that moment gets handled as username. (It keeps switching me to tty2 while I am writing this, which is quite annoying) :)
systemctl status prefdm.service prefdm.service - Display Manager Loaded: loaded (/lib/systemd/system/prefdm.service; static) Active: active (running) since Mon, 06 Feb 2012 20:22:50 +0200; 49min ago Main PID: 1372 (kdm) CGroup: name=systemd:/system/prefdm.service ├ 1372 /usr/bin/kdm -nodaemon └ 1380 /usr/bin/X :0 vt2 -background none -nolisten tcp -auth /var/run/kdm/A:0-quSPRa
My guess is that X is somehow forcibly taking over vt2 and clashes with a getty there. This might indicate that kdm's vt allocation is borked. What is the precise command line of X that you see in ps?
Peter uses xdm, not kdm. xdm is not plymouth-aware. If not configured explicitly to do otherwise, xdm grabs the first unallocated VT, which can be vt2 at that point in time. getty may start later.
Marko uses kdm. kdm is plymouth-aware and will normally do the takeover and start on vt1. Marko's log however shows that plymouth died before kdm was started: [ 7.454270] systemd[1]: Received SIGCHLD from PID 209 (plymouthd). [ 7.454307] systemd[1]: Got SIGCHLD for process 209 (plymouthd) [ 7.454374] systemd[1]: Child 209 died (code=killed, status=6/ABRT) ... [ 8.908172] systemd[1]: About to execute: /etc/X11/prefdm -nodaemon [ 8.917384] systemd[1]: Forked /etc/X11/prefdm as 1363 It's possible that in that case kdm would behave in the same way as xdm.
(plymouthd dying with SIGABRT doesn't sound right really.) So, in F16 and newer we don't actually start gettys at boot, but only on demand when the user swicthes to a VT, and no process is using the VT already. For upgraded systems however the symlinks to force-start the gettys are still in place, and this auto-spawn getty logic is turned off. It would be good to know whether in this case the gettys are auto-spawned or force started. What is the contents of /etc/systemd/system/getty.target.wants/? I have one possible explanation here: kdm/xdm first chvt to the VT they want to run on and only then open it. That might cause a race with logind, which notices the switch but when it checks whether the VT is used still sees nothing going on, and spawns the getty, at the same time as kdm/xdm spawn X, and then things are borked. But that's just a wild guess.
ll /etc/systemd/system/getty.target.wants/ total 0 lrwxrwxrwx. 1 root root 34 May 13 2011 getty -> /lib/systemd/system/getty@.service lrwxrwxrwx. 1 root root 34 May 13 2011 getty -> /lib/systemd/system/getty@.service lrwxrwxrwx. 1 root root 34 May 13 2011 getty -> /lib/systemd/system/getty@.service lrwxrwxrwx. 1 root root 34 May 13 2011 getty -> /lib/systemd/system/getty@.service lrwxrwxrwx. 1 root root 34 May 13 2011 getty -> /lib/systemd/system/getty@.service lrwxrwxrwx. 1 root root 34 May 13 2011 getty -> /lib/systemd/system/getty@.service
The kdm/X related processes are ps -ef | grep 1300 root 1300 1 0 20:46 ? 00:00:00 /usr/bin/kdm -nodaemon root 1307 1300 2 20:46 ? 00:03:55 /usr/bin/X :0 vt2 -background none -nolisten tcp -auth /var/run/kdm/A:0-Qh1OMb root 1319 1300 0 20:46 ? 00:00:00 -:0 root 4226 4195 0 23:26 pts/0 00:00:00 grep --color=auto 1300
(In reply to comment #22) > My guess is that X is somehow forcibly taking over vt2 and clashes with a getty > there. This might indicate that kdm's vt allocation is borked. > > What is the precise command line of X that you see in ps? 1041 ? Ss 0:00 /usr/bin/xdm -nodaemon 1050 ? Ss 3:28 \_ /usr/bin/X :0 -auth /var/lib/xdm/authdir/authfiles/A:0-MWPKsK 1061 ? Ss 0:00 \_ -:0 1072 ? Ss 0:00 \_ /usr/bin/ck-xinit-session /usr/bin/ssh-agent /home/petro/.xsession 1171 ? S 0:01 \_ fvwm
(In reply to comment #16) > (In reply to comment #14) > > Peter Lemenkov's Xorg.0.log > > It shows: > [ 14.091] (--) using VT number 2 > > Peter, try changing the line in /etc/X11/xdm/Xservers to say this and see > if it helps: > :0 local /usr/bin/X :0 vt1 I've just did that. Let's see if it fixes the issue.
(In reply to comment #29) > (In reply to comment #16) > > (In reply to comment #14) > > > Peter Lemenkov's Xorg.0.log > > > > It shows: > > [ 14.091] (--) using VT number 2 > > > > Peter, try changing the line in /etc/X11/xdm/Xservers to say this and see > > if it helps: > > :0 local /usr/bin/X :0 vt1 > > I've just did that. Let's see if it fixes the issue. It does fixes this issue. All sudden switches are gone now.
*** Bug 787655 has been marked as a duplicate of this bug. ***
One other very odd thing I've noticed, if it might help track down the cause. When it happens, I still see my X cursor on the screen, and at the same time my gpm block cursor. And both of them move with my mouse. (Well, technically, with my trackball.) I've never seen anything like that before.
*** Bug 786809 has been marked as a duplicate of this bug. ***
Any workarounds for KDM? I understand that the modification of /etc/X11/xdm/Xservers is only for XDM. Should we remove getty targets from /etc/systemd/system/getty.target.wants/? It's full of tty1 to tty6 like Marko's for me as well. I've checked that clean F16 installation creates only /etc/systemd/system/getty.target.wants/getty.
Looks like there is no answer on what to do with kdm. Ideas? Do we remove the symlinks in systemd?
kdm is configured with /etc/kde/kdm/kdmrc. You'll likely find the needed options configurable there, but I am not familiar with it.
My sample size so far is only three reboots, but since I've updated to kernel-3.2.9-1.fc16.x86_64, this hasn't been happening to me. At least in my case, it was randomly happening or not after each reboot, and continued doing it or not until a reboot. And it hasn't been happening yet. Next boot will be with 3.2.9-2. Maybe it's fixed, or maybe I've just been randomly lucky (if it were even odds, which seems about right, I'd have a 1/8 chance of getting the first three boots working well).
Hmm, so I am not sure what the issue is here now. a) is this about kdm or about xdm? b) does kdm/xdm (whatever this is about) configure a fix VT assignment right now? If not, it should configure one, and use VT1. [ Note that VT1 on Fedora is where we start the display manager, and this should be encoded in the display manager configuration file, instead of leaving it to automatic allocation of the first free VT. Why? Because automatic VT allocation will very likely pick VT2 instead of VT1 in case systemd is printing a status update string at the same time to VT1 which might make the VT appear busy, although it really isn't and is only used for writing. ] Is there anything to fix in systemd here really? Otherwise I'd just reassign this to either kdm or xdm (whatever this is about).
Same behavior here - the switch from X to tty2 is pretty annoying. It started today. I found following message 52 times during last 2 hours in /var/log/messages: Mar 13 18:39:47 tml systemd[1]: getty holdoff time over, scheduling restart. from /var/log/yum.log: Mar 12 10:15:06 Updated: systemd-units-37-15.fc16.x86_64 Mar 12 10:15:08 Updated: systemd-37-15.fc16.x86_64 Mar 12 10:15:08 Updated: systemd-sysv-37-15.fc16.x86_64 ... Mar 12 10:16:54 Installed: kernel-3.2.9-2.fc16.x86_64 from /var/log/secure: Mar 13 18:33:08 tml login: pam_unix(login:auth): check pass; user unknown Mar 13 18:33:08 tml login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= Mar 13 18:33:09 tml login: FAILED LOGIN 1 FROM (null) FOR less [2~, User not known to the underlying authentication module # cat /sys/class/tty/tty0/active tty2 # ps -eo tty,pid,cmd | grep ^tty tty5 1287 /sbin/agetty tty5 38400 tty3 1288 /sbin/agetty tty3 38400 tty4 1289 /sbin/agetty tty4 38400 tty6 1290 /sbin/agetty tty6 38400 tty2 9226 /bin/login -- # cat /sys/class/tty/tty0/active tty2 # ps -eo tty,pid,cmd | grep ^tty tty5 1287 /sbin/agetty tty5 38400 tty3 1288 /sbin/agetty tty3 38400 tty4 1289 /sbin/agetty tty4 38400 tty6 1290 /sbin/agetty tty6 38400 tty2 9226 /bin/login -- # systemctl status prefdm.service prefdm.service - Display Manager Loaded: loaded (/lib/systemd/system/prefdm.service; static) Active: active (running) since Tue, 13 Mar 2012 15:38:56 +0100; 2h 56min ago Main PID: 1284 (kdm) CGroup: name=systemd:/system/prefdm.service ├ 1284 /usr/bin/kdm -nodaemon └ 1316 /usr/bin/X :0 vt2 -background none -nolisten tcp -auth /var/... ps: root 1316 2.8 2.4 210756 97728 ? Rs 15:38 5:01 /usr/bin/X :0 vt2 -background none -nolisten tcp -auth /var/run/kdm/A:0-ABZEpa Going to downgrade ...
All that has to be done is eliminate the symlinks to tty's in systemd, as was said in comment #25. # rm -f /etc/systemd/system/getty.target.wants/* At least that solved the problem for me.
I had the same problem after today's update of my Fedora 16 running KDE. System was not installed from scratch, but upgraded from F14. # rpm -q systemd systemd-37-19.fc16.x86_64 Problem solved as per comment #40. # rm -f /etc/systemd/system/getty.target.wants/*
answers for comment #38 would still be cool. Or should we close the bug?
(In reply to comment #42) > answers for comment #38 would still be cool. Or should we close the bug? Oh, sorry for the delay. I'm using XDM and I must say that this issue was gone. I did few fresh installs since then, and I don't see it anymore. No additional configuration required (VT assignment, etc).
I think it should be closed now.
In my opinion, since the solution is to remove the entries of /etc/systemd/system/getty.target.wants/*, it should be encoded as a post script installation in the systemd package. a) it affects both xdm and kdm b) KDM offers the following in the /etc/kde/kdm/kdmrc: # VTs to allocate to X-servers. A negative number means that the VT will be # used only if it is free. If all VTs in this list are used up, the next free # one greater than the last one in this list will be allocated. # Default is "" ServerVTs=-1 I don't know if it should be fixed, but having deleted the entries as suggested here, the issue has gone for good.