Bug 103817

This was discussed in bug 44124, too. Are daemons still running 5 minutes after
leaving GNOME session?

They should be dying pretty much immediately - this was fixed for 9.3 in evolution.

bonobo-activation-server and evolution-data-server keep running forever.
I am not leaving a gnome session but a KDE session, the Xserver terminated by
segfault.

I started gedit & evo (not doing anything useful with either) as a new user
under KDE, and after I logged out, gconfd was still running.

I believe gconf exits after a number of seconds.

b-a-s will run as long as it's clients are alive & registered.
=> this is most likely e-d-s not quitting cleanly.
How the session terminated shouldn't be too much of an issue - e-d-s can tell
when  all it's clients are dead quite easily.

Harish, this was fixed in 2.2 for 9.3, whats up?

I suspect this is related to my problem running a remote gnome session for
administration of my SUSU 10 beta3 box. On my Fedora Core 4 system (sorry :-),
I run this script:

#!/bin/bash
#
# Run a gnome session as root in an Xnest window
#
Xnest -depth 24 -geometry 1024x769 -name 'ROOT batcave ROOT' :2 &
nestpid=$!
DISPLAY=:2
export DISPLAY
ssh -X -A root@batcave /root/scripts/remote-command gnome-session
kill -9 $nestpid

That ssh command never finishes, and in the Xnest window, logging out
also never finishes. I try to log out, but it acts like some component
somewhere isn't getting the message to quit. I'll attach a ps listing of
the processes that started up after my session started and were still
running after I told it to logout, and also (for whatever the gibberish
is worth) the stdout/stderr from the gnome-session command itself.

P.S. I do a similar command to administer the Fedora box, and the gnome
session logs out with no problem there.

Created attachment 47912 [details]
ps listing showing leftover processes still running after logout

Created attachment 47915 [details]
stdout/stderr from the gnome-session command

The line at the end saying "terminated by remote
system" appeared only after I did a kill -9 of the
list of processes from the ps command shown in the
previous attachment, till then it was just
hung.

Are you using kdm or gdm?

I'd hope running either one over on the :0.0 display wouldn't have an
effect on a completely separate gnome-session run over ssh X forwarding
to an Xnest display on another machine :-).

However, I probably am running kdm on the main X display.

I tried replicating this with xnest and gdm locally.  Are you able to test with
batcave locally to confirm this only occurs in the remote case for you?

Created attachment 49128 [details]
Session log from native Xnest on batcave

Interesting. I ran the same shell script native on
batcave with the Xnest session running as a client
on the native display, and it seems to log out
normally. I've attached the stdout/stderr and
at the point where it hangs when I run remote, I see
a message about "best" losing the connection
followed by everyone else losing their connection too.

Maybe some property of the Xnest provided on
fedora is different than the Xnest on Suse and it
confuses the clients somehow?

I suspect the session is not exiting cleanly some how on the remote machine and
hence not killing everything.  Which is the SuSE machine and which the fedora?

Lowering priority do to mixed OS and remote only nature of problem.

on RC1, no gnome stuff was autostarted during KDE login.
So i started "Beagle Search" from the menu and clicked on "Start the beagle daemon".
Then i logged out and everything but esd and artsd was gone. So i tried again,
but could not reproduce this anymore: any subsequent tries cleaned up after
themselves, so this seems to be fixed for me. If i encounter this again and can
reproduce it, i'll reopen the bug.
Thanks,

I don't know about the "session" being on the remote machine or not.
Here's exactly where everything is running:

batcave: suse box
spike: fedora box

On spike: run Xnest locally, set DISPLAY to the Xnest display, then
run ssh -X root@batcave gnome-session

So the "session" presumably would be that created by the gnome-session
command which is running on batcave. Nothing on spike is talking to the
Xnest server, Xnest is strictly a client on spike.

In any case, this doesn't seem like a really important bug. I can
always kill off stuff manually, and it seems as though everything
eventually dies if I just kill the Xnest client from spike. It is only
when I try to close the gnome-session normally by telling it to quit
from the menu item that it hangs.

Moving back to the pool for re-assignment.

JP said:
> I tried replicating this with xnest and gdm locally.

but the reporter isn't using gdm, he's starting gnome-session directly.
This seems to be the problem. gnome-session makes no attempt to clean up
after its children when it exits, because it assumes it's being invoked
from gdm, which does the cleanup for it.

(I'm not sure why it works when doing it to the Fedora box. I checked Fedora's
gnome-session SRPM, and they're not patching it in any way relevant to this.)

So - does e-d-s run indefinately without any clients connected ? surely [ now we have the panel / addressbook thing ] 30 secs without any connected clients is a good heuristic for session death ? :-)

Of course when e-d-s goes, b-a-s will go too.

Michael: the original eds/bas bug was indeed fixed (comment 16). We're only
talking about Thomas Horsley's gnome-session/Xnest bug (comment 8 et seq) now.

Oops, I'm wrong. It doesn't matter that gnome-session doesn't clean up,
because he's killing the Xnest. The problem is that gnome-session is not
exiting, so it never reaches the kill command.

Thomas: can you try attaching a gdb to the gnome-session process on the remote
machine after you've told it to log out and getting a backtrace?

And/or, could you attach a strace to it before telling it to log out, and
getting the log of everything it does up to the point where it hangs?

(I'm assuming that if you're the sort of person who's using Xnest to run
remote x sessions as root that that means you know how to use gdb and strace,
but if not just write back and I'll give more detailed instructions.)

I certainly know how to do that stuff, but unfortunately one of my computers
died so now I have a single dual boot system, and I can't talk to both of
them at the same time in order to reproduce the original setup :-).

I'll see if running locally has the same problem, if so, I'll see if I
can find out what it is hanging on, but if you look at the ps command
listing  I attached to my original comment, you'll see that the
gnome-session command itself is gone, but there is a whole collection
of other junk laying around (and ssh has the annoying habit of refusing
to exit till all the processes that started under it finally exit).

Oops, you're right, I'd looked at that before and just forgotten.

OK, so we're back to what I said in comment 19. The problem is that
gnome-session doesn't even try to kill off its children, and ssh won't exit
until they all exit, so you get the hang.

I checked the Fedora openssh and xorg SRPMs too, and there don't seem to be any
relevant patches to ssh or Xnest either. So basically, AFAICT, Fedora is
suffering from a convenient bug, in that one of the packages seems to be
behaving other than how it is specified to behave. If you can figure out why,
we might be able to patch things here to work similarly.

Otherwise, I'd suggest tweaking your remote login script. You might to
be able to do something with the setsid(8) command to create a new process
group for gnome-session and its children, and then kill the process group
when gnome-session exits?

Actually, one thing I've done in the past is background things much more
intensely than just & can do. I once wrote a program to double fork the
child, run setsid(), and free every file descriptor, and I think it actually
managed to background stuff well enough that ssh didn't wait for it.
Maybe I just need to run gnome-session under a variation of that program
so all the children will be hidden from ssh :-).