Bug 192461 - gdm no longer honors -nodaemon
Summary: gdm no longer honors -nodaemon
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Mike McLean
URL:
Whiteboard:
: 192464 193284 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-05-19 19:58 UTC by Chris Ball
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-05-24 18:36:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
strace (3.88 MB, text/plain)
2006-05-19 19:58 UTC, Chris Ball
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 342831 0 None None None Never

Description Chris Ball 2006-05-19 19:58:09 UTC
Description of problem:
prefdm is chewing CPU after an upgrade to today's (20050519) Rawhide.

I did update yesterday and this issue wasn't present, so I suspect one of the
packages in today's update.  gdm was updated, but initscripts wasn't.  

Version-Release number of selected component (if applicable):

unity:cjb~ % rpm -q initscripts
initscripts-8.33-1
unity:cjb~ % rpm -q gdm
gdm-2.15.3-1

How reproducible:

Always, on reboot.

Steps to Reproduce:
1. Log in to gnome via GDM.

Additional info:

I'll attach an strace of a couple of seconds of prefdm time.  /usr/sbin/gdm
-nodaemon is spawned as often as possible, even though it's already running.

I'm also seeing the below on logging in to the tty.  It's also new either today
or recently.
/etc/profile.d/kde.sh:4: = not found

The top of kde.sh is:

# When/if using prelinking, avoids (some) use of kdeinit
if [ -f /etc/sysconfig/prelink ] ; then
   source /etc/sysconfig/prelink
   if [ "$PRELINKING" == yes ] ; then
      [ -z "$KDE_IS_PRELINKED" ] && KDE_IS_PRELINKED=1 && export KDE_IS_PRELINKED
   fi
fi

Comment 1 Chris Ball 2006-05-19 19:58:11 UTC
Created attachment 129623 [details]
strace

Comment 2 Chris Ball 2006-05-19 20:01:37 UTC
Speaking of which, shouldn't that == above be a =?

Comment 3 Bill Nottingham 2006-05-19 20:11:27 UTC
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...



Comment 4 Valdis Kletnieks 2006-05-23 15:35:01 UTC
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?


Comment 5 Bill Nottingham 2006-05-23 15:43:21 UTC
Look at /etc/inittab - prefdm is 'once',not 'respawn'. So it's written this way
so that gdm (or whatever) will respawn.

Comment 6 Michal Jaegermann 2006-05-23 16:01:16 UTC
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.

Comment 7 Valdis Kletnieks 2006-05-23 16:05:16 UTC
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.

Comment 8 Bill Nottingham 2006-05-23 19:08:35 UTC
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.

Comment 9 Valdis Kletnieks 2006-05-23 19:21:57 UTC
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.

Comment 10 Bill Nottingham 2006-05-23 19:28:30 UTC
But, -nodaemon should be inherited from the prefdm args, unless I'm misreading.



Comment 11 Chris Ball 2006-05-23 19:39:01 UTC
It is indeed being inherited:

[pid  1283] execve("/usr/sbin/gdm-binary", ["/usr/sbin/gdm-binary",
"-nodaemon"], [/* 27 vars */]) = 0

Comment 12 Bill Nottingham 2006-05-23 19:47:32 UTC
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).

Comment 13 Bill Nottingham 2006-05-23 19:48:32 UTC
*** Bug 192464 has been marked as a duplicate of this bug. ***

Comment 14 Valdis Kletnieks 2006-05-23 19:51:20 UTC
That's a simple one-liner fix in /etc/inittab then.

Comment 15 Ray Strode [halfline] 2006-05-23 20:19:09 UTC
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?

Comment 16 Chris Ball 2006-05-24 18:15:57 UTC
Tested today's package, and fixed.  Many thanks.

Comment 17 Ray Strode [halfline] 2006-05-24 18:36:11 UTC
great, thanks. closing.

Comment 18 Bill Nottingham 2006-05-26 20:24:09 UTC
*** Bug 193284 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.