Bug 192461
Summary: | gdm no longer honors -nodaemon | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Ball <chris-rhbugs> | ||||
Component: | gdm | Assignee: | Ray Strode [halfline] <rstrode> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | clint, oliva, valdis.kletnieks | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-05-24 18:36:11 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Chris Ball
2006-05-19 19:58:09 UTC
Created attachment 129623 [details]
strace
Speaking of which, shouldn't that == above be a =? So, the question is, how did prefdm get started twice? Basically, it execs gdm, which fails (as it's already running), so it restarts, so it execs gdm... Let's look at this code: # Fallbacks, in order gdm "$@" >/dev/null 2>&1 if [ $? -ne 127 ]; then exec $0 "$@" exit $? fi Now what happens if /usr/sbin/gdm manages to leave with a return code of 0? Yes, that's right, it will exec prefdm again... Whoops. Maybe that should be 'exec gdm $@' instead? (and similarly for the other places? Look at /etc/inittab - prefdm is 'once',not 'respawn'. So it's written this way so that gdm (or whatever) will respawn. Re comment #4. In /etc/X11/prefdm a little bit above quoted code there is that: if [ -n "$preferred" ]; then $preferred "$@" >/dev/null 2>&1 if [ $? -ne 127 ]; then exec $0 "$@" exit $? fi fi so if $preferred is not blank we are doing the same crazy re-execs a bit earlier. Makes /var/log/messages quite boring. :-) Hm, 'once' in inittab does not seem to help. Once versus respawn isn't the point - the problem is that init spawns prefdm once, then prefdm spawns gdm. It then botches the return code check, and as a result respawns gdm and then exec's itself. The exec'ed copy (still on the same PID, as it hasn't forked, so it's still the some "once" to init) then tries to spawn gdm, botches the return code check, and execs itself. Lather, rinse, repeat. It's quite possible for '$preferred' to not be set - unless there's a settig in /etc/sysconfig/desktop for $DISPLAYMANAGER, it won't be set. At least in mine, there was a setting for $DESKTOP, but not $DISPLAYMANAGER. I'm still confused as to what you mean. It runs the display manager once, and waits for it to exit. When the display manager exits, it respawns itself, so the display manager will then get run again. This behavior seems correct to me. With the behavior you're suggesting, if gdm exits zero during normal use it will never respawn. Looking at gdm 2.15.3 source, in daemon/gdm.c, function gdm_daemonify certainly looks like it's doing the usual fork-to-detach - and the parent is going to exit very soon - at which point prefdm's wait() will be fulfilled. Quick test, which I can't try right this instant - does changing the invocation to 'gdm -nodaemon' stop the prefdm looping? If so, that's the problem. But, -nodaemon should be inherited from the prefdm args, unless I'm misreading. It is indeed being inherited: [pid 1283] execve("/usr/sbin/gdm-binary", ["/usr/sbin/gdm-binary", "-nodaemon"], [/* 27 vars */]) = 0 We discussed this a bit on IRC - gdm 2.15 moves to GOption based parsing, and lost the support for the -nodaemon commandline option (it does take --nodaemon). *** Bug 192464 has been marked as a duplicate of this bug. *** That's a simple one-liner fix in /etc/inittab then. I added code to gdm to make it recognize -nodaemon. Can someone try the updated package in tomorrow's compose and tell me if it fixes the problem? Tested today's package, and fixed. Many thanks. great, thanks. closing. *** Bug 193284 has been marked as a duplicate of this bug. *** |