Bugzilla – Bug 103817
GNOME stuff doesnt stop after logout.
Last modified: 2006-03-07 19:04:41 UTC
Freshly installed Beta1, added "GNOME" to my KDE selection. After i logged out testuser from KDE, still some gnome-stuff is running: f71:~ # ps xau|tail -20 root 11809 0.0 0.3 3192 1704 ? S 16:05 0:00 /usr/sbin/powersaved -d -f /var/run/acpid.socket -v 3 root 11810 0.0 0.1 1788 604 ? S 16:05 0:00 hald-addon-acpi --acpid_only root 11846 0.0 0.2 2796 1236 ? Ss 16:05 0:00 login -- root root 11847 0.0 0.1 1928 612 tty2 Ss+ 16:05 0:00 /sbin/mingetty tty2 root 11848 0.0 0.1 1932 616 tty3 Ss+ 16:05 0:00 /sbin/mingetty tty3 root 11849 0.0 0.1 1928 612 tty4 Ss+ 16:05 0:00 /sbin/mingetty tty4 root 11850 0.0 0.1 1932 616 tty5 Ss+ 16:05 0:00 /sbin/mingetty tty5 root 11851 0.0 0.1 1928 608 tty6 Ss+ 16:05 0:00 /sbin/mingetty tty6 root 11928 0.0 0.1 1796 624 ? S 16:05 0:00 hald-addon-storage testuser 12103 0.0 0.6 6476 2916 ? Ss 16:06 0:00 /opt/gnome/lib/bonobo/bonobo-activation-server --ac-activate --ior-output-fd=44 testuser 12105 0.0 1.2 19772 5572 ? Sl 16:06 0:00 /opt/gnome/lib/evolution-data-server-1.2/evolution-data-server-1.4 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_BookFactory:1.4 --oaf-ior-fd=48 root 12380 0.1 0.3 3992 1764 tty1 Ss+ 16:09 0:00 -bash root 12443 0.4 4.8 23924 21720 tty7 Ss+ 16:10 0:00 /usr/X11R6/bin/X -br -nolisten tcp :0 vt7 -auth /var/lib/xdm/authdir/authfiles/A:0-QizzAA root 12444 0.0 0.2 2868 1124 ? S 16:10 0:00 -:0 root 12454 1.2 2.7 22032 12244 ? S 16:10 0:02 /opt/kde3/bin/kdm_greet root 12575 0.0 0.1 1736 544 ? Ss 16:12 0:00 /sbin/dhcpcd -C -H -D -K -N -t 999999 -h linux -c /etc/sysconfig/network/scripts/dhcpcd-hook eth0 root 12682 0.1 0.5 8384 2424 ? Ss 16:12 0:00 sshd: root@pts/0 root 12685 0.2 0.4 3988 1816 pts/0 Ss 16:12 0:00 -bash root 12712 0.0 0.1 2752 816 pts/0 R+ 16:13 0:00 ps xau root 12713 0.0 0.1 2928 696 pts/0 R+ 16:13 0:00 tail -20
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 :-).