Version: (using KDE 4.3.0) Compiler: gcc OS: Linux Installed from: Unlisted Binary Package I use KDM When logging in for the first time, it works well. But when i want to leave KDE, it doesn't return back to kdm as expected, but rather i see a black screen w/ cursor blinking (can't type) I had to switch to another tty, and #/etc/rc.d/kdm restart (kdm seems to be running as output is: stopping kdm [done] starting kdm..[done])
Hi ! same thing on kubuntu with kde 4.3.0 from ppa.
Created attachment 36164 [details] Logs from x.org logs from X.org
Created attachment 36165 [details] Logs from KDM This is the same situation from mine, I don't know if its X or KDM well, I'll leave you guys up to decide :) I hope these logs are a bit useful at least.
I copy and paste from the Debian report for this bug which also gives a workaround. It's probably a intel graphics bug (I only see it on a machine with an GM945 graphics chip) Package: kdm Version: 4:4.3.0-2 Severity: normal Hi, I recently installed kdm, and I noticed the following behaviour: Initially kdm would load the X server and I could log in. However, after logging out it would not start the X server again; instead I would see in the logs: kdm[2572]: X server for display :0 terminated unexpectedly kdm[2572]: Unable to fire up local display :0; disabling. Thanks to a bit of digging around on the web, I found out that I could fix this problem by adding the following option to /etc/kde4/kdm/kdmrc: TerminateServer=true I'm not sure if the best way to fix this is to make this the default, or to somehow prevent the X server from terminating when the user logs out, but in any case this is a problem with the default settings that should be fixed. Thanks, Vasilis
intel graphics bug ? maybe, but i have got a two nvidia videocard on this computer.
(In reply to comment #4) > I copy and paste from the Debian report for this bug which also gives a > workaround. It's probably a intel graphics bug (I only see it on a machine with > an GM945 graphics chip) > > > Package: kdm > Version: 4:4.3.0-2 > Severity: normal > > > Hi, > > I recently installed kdm, and I noticed the following behaviour: Initially > kdm would load the X server and I could log in. However, after logging out > it would not start the X server again; instead I would see in the logs: > > kdm[2572]: X server for display :0 terminated unexpectedly > kdm[2572]: Unable to fire up local display :0; disabling. > > Thanks to a bit of digging around on the web, I found out that I could fix > this problem by adding the following option to /etc/kde4/kdm/kdmrc: > > TerminateServer=true > > I'm not sure if the best way to fix this is to make this the default, or > to somehow prevent the X server from terminating when the user logs out, but > in any case this is a problem with the default settings that should be > fixed. > > Thanks, > Vasilis At least for me, this fixed the issue and it's working as expected. Thanks :)
Hi, may I ask what's status of this bug? As of kde 4.3.1 the problem still persists on my system. PS: I didnt try the ' I found out that I could fix > this problem by adding the following option to /etc/kde4/kdm/kdmrc: > > TerminateServer=true' workaround as this file doesn't exist on my system. Although, should it help, it'd be an easy fix. Good day :)
little surprisingly, the location of the kdmrc is system-specific. $prefix/share/config/kdm/ is the default location.
well guys, atleast for me, the solution is: in /etc/inittab edit the greeter line x:5:respawn:/usr/bin/kdm -nodaemon and remove the -nodaemon option. After this change, everything is all right, after logout a get the welcome screen. Is this solution correct? I suspect it is a distribution bug? (i my case archlinux) Bye, mark
hello :) bump and question: sb still having the problem or could you fix it in inittab? shall we mark this as closed?
confirmed here with kde 4.3.4 on ubuntu karmic with kubuntu's kde updated packages the bug can be workarounded by putting TerminateServer=true in group [X-:*-Core] into /etc/kde4/kdm/kdmrc See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541272 best regards, bráulio
x server bug
It's a DM bug that the X server is not restarted. Here's the full explanation: Since time immemorial the MIT(etc) X server has auto-restarted when all clients disconnect - it tries to do pretty much of an exec(itself) to completely reset its own state. This was always the default - you have to say "-terminate" to the X server to get it to exit (ever). kdm relies on this - it expects not to need to restart the server after every session. Here's what kdm runs on my gentoo machine: /usr/bin/X -br -novtswitch -quiet -nolisten tcp :0 vt7 -auth /var/run/xauth/xxxx Ok, that's fine, but if the X server *crashes* then the DM has to start it again (obviously), and if the DM fails to do this then that is a BUG in the DM. It isn't possible to manually restart the X server (so far as I can see); I can't generate the right xauth into. I can't restart kdm because that would kill *all* the X sessions attached to the machine (including those on independent heads and on remote X terminals); not a good idea ;-) Normally kdm *does* restart the server. I can send the server SEGV during regular sessions or while the login window is up and kdm nicely restarts it. *But* on my system the X server SEGVs inside the driver shutdown and then, for some reason, can't be immediately restarted, so I see: May 08 08:51:14 [kdm] X server for display :0 terminated unexpectedly May 08 08:51:14 [kdm] Unable to fire up local display :0; disabling. Ok, it's a bug probably in a driver, but kdm needs to handle this better. Since the X server has already worked once (else how did kdm get all the way to a logout!) kdm should know that the problem is almost certainly not permanent. I suggest an Ethernet style back-off - try again after 1 second, then 5, then 60 then 10 minutes etc. BTW; it's a pretty serious error. It can leave the whole machine unuseable since the X server may be the only interface!
It's actually nothing to do with the driver, it's a straightforward bug or two around line 1561 of kde-4.3.5/kdm/backend/dm.c There are two problems: 1) If the XOpenDisplay fails xdm (since this is xdm code) calls exitDisplay with XS_RETRY and, if it is less than 120 seconds since the start of *this* session the display is disabled. 120 seconds, at the very least, needs documenting. It's not clear why the *time* matters. 2) The above behavior means that if a server crashes on reset (as is the case in this bug) no attempt is made to restart it, even though it won't crash if restarted because it won't have to reset itself... It looks like the 120s may have been an attempt to deal with (2) - if a previous session has lasted from more than 120s then *don't* do a stopDisplay. However, the calculation used takes a value from 'lastStart' and this has already been reset (in startDisplayP2) to the new session by the time the server crashes (see the default case, in the parent process, after the 'gFork'.) The way I fixed this was: 1) Use 30s not 120s for the timeout (gee, it's 2010, not 1990). 2) In server.c set a new struct display field 'serverStart' to now when the server is actually started, and change the condition in dm.c to require both the time since the start of the session *and* the time since the server start to exceed 30s. Note that the time change is necessary - I can log in and log out in no more than 30s on my system (an old P4 system). Even 30s means that a fast log in/log out followed by a crash can potentially cause the stopDisplay(). One final note: on my system it's nothing to do with my NVidia Nouveau driver, it's something crashing in 'OpenFont' when opening the default font after the reset. I suspect it may be something to do with the fact that I use a font server (xfs) on another machine, but I haven't verified that.
See the gentoo bug for the patch - it only affects the xdm code (which has been copied into kdm), I'm going to try to report this upstream, but this may fail (I had problems before with the X Consortium.) http://bugs.gentoo.org/show_bug.cgi?id=278473 The patch is against kdm-4.3.5
I couldn't find you guy's upstream bug - are you sure you actually entered one? Anyway, I entered this one: https://bugs.freedesktop.org/show_bug.cgi?id=28034
i suggest you actually verify the applicability of your conclusions before bothering xorg next time. i'm pretty sure xdm behaves differently unless they adopted my code. the upstream tag refers exclusively to the crashing x server. the connection timeout 120s is certainly excessive for local displays. it's like that simply because nobody bothered to make it different from the one for remote diplays. the timeout for firing up the x server is a mere 15s. however, you have a point about the sequencing. it's somewhat weird that kdm thinks it just fired up the x server. the question is only how to make the crash obvious (and thus have it reported upstream) when we simply restart it. probably the user should be bothered with a dialog box. fwiw, reviving dead displays is as simple as running "killall -1 kdm".
Comment #17: "i'm pretty sure xdm behaves differently" Sorry about the apps/xdm report - when I searched and couldn't find the upstream report even though *this* bug was resolved "UPSTREAM" I figured I had to do something to bring it down. It was a mistake on my part not to verify how little (much) you had changed the code (I was working from memory of the code from about 1992, it kinda looked the same, oops.) Comment #17: "it's somewhat weird that kdm thinks it just fired up the x server". I think you are misreading the code in dm.c, I did the same thing too initially. The (unpatched) code is unambiguous - it's in XOpenDisplay after a server reset when it reaps a dead child (the server), then the XOpenDisplay errors out. The code doesn't think it fired up a server, indeed, my patch records the time when the server was actually started (in the local case) and that time corresponds to the start of the *first* session (the one that just logged out). The bug is that dm.c is recording the time of the fork of the greeter, not the fork of the server, and the greeter just started for the new session. (That's what it needs for XDMCP sessions, where it doesn't start the server itself). Comment #17: "the question is only how to make the crash obvious" It's there in syslog; see my report above ('server terminated unexpectedly'). You have no output device other than syslog, since the server terminated. Perhaps raising the priority of the log message would help - traditionally such things would appear on the root console. Anwyay, it's not a problem if the server crash occurs *immediately* - then it's obvious what is happening. In this case, however, everything worked once so people are mystified.
so here's a proper analysis of the problem: the lastStart variable records the last time the slave was started. the sole purpose of this is to avoid getting into an infinite loop when the slave or greeter crashes during startup (hence the hardcoded 120s in this place, and the number still *is* realistic under adverse conditions). the problem is that if the x server crashes during regen, the master will falsely believe that the slave/greeter crashed, as it does not correlate the two events. i'll come up with a fix. having a message only in the syslog is as good as not having it at all. why would anyone look there if everything just works? the message box will of course pop up on the restarted x display.
Any news on this?
KDM is unmaintained and not used in KDE Plasma 5. SDDM is the login manager used in KDE Plasma 5. If you still have this same issue with SDDM, please file an issue on the SDDM bugtracker (after doing a search for existing issues first!): https://github.com/sddm/sddm/issues/