Problem with processes that just won't die...

einheitlix · 2009-03-31 14:15:24

Hi,

first off, hullo everybody
I'm new to Arch Linux, but I do already like it very much. I have just installed it on my workstation and it works fine, except for the following problem.

My home directory here is mounted via NFS from a central server. My username is malte (we're using YP/NIS for central authentication) and my home dir is /WW/home/malte/
The network file system that is mounted at boot time is /WW

malte@bombadil $ grep nfs /etc/fstab
quarterback:/WW /WW nfs defaults 0 0

Everything is setup at boot time automatically and all works fine so far. However, when I reboot my machine using sudo reboot, or even when cleanly logging out and using the Shutdown/Reboot button in GDM, what happens is that Arch tries to unmount the net file systems (that is, /WW in this case), but fails and outputs

/WW: device is busy

(or something to that effect); so it gives up, and goes on shutting down all the other services, like the network etc. At the very end, when "Unmounting all filesystems", it then again tries to unmount the net file system, which of course won't work since the network is already shut down. It tries for about a minute or so before timing out, giving up and just rebooting

This of course is quite annoying, as I have to wait more than a minute each time I want to reboot (or I would have to press the reset button on the computer, which I really don't want to).

So why doesn't Arch succeed in unmounting the net file system when it should? Using lsof, I have traced down the problem further:

When I do not login as user in GDM after booting up the system, but immediately reboot again after GDM has just been started, there is no problem: /WW is unmounted properly, and my system reboots flawlessly.

The problem is when I log in to my WM as user. Even if I log out cleanly to GDM again, there are two processes belonging to user malte that go on living and that access to /WW/home/malte, and I suppose that is why unmounting fails at reboot time, saying the device is busy.
I have found out that (and which these processes are) by closely observing the output of watch 'lsof | grep WW' run as root on vc/1, just after I log out from my WM as user:

root@bombadil $ lsof | grep WW # executed closely after logging out as user malte
menu-cach 3410 malte cwd DIR 0,16 1536 8785908 /WW/home/malte (quarterback:/WW)
gam_serve 5391 malte cwd DIR 0,16 1536 8785908 /WW/home/malte (quarterback:/WW)

More information on those two processes:

root@bombadil $ ps aux | grep -e gam_serv -e menu-cach
malte 3410 0.0 0.1 41540 2680 ? S 14:46 0:00 /usr/bin/menu-cached
malte 5391 0.0 0.0 17444 1476 ? S 15:38 0:00 /usr/lib/gamin/gam_server
root 5473 0.0 0.0 9324 740 tty1 R+ 15:38 0:00 grep -e gam-serv -e menu-cach

So! In short, even after logging out, menu-cached and gam_server keep on living, and access to /WW/home/malte, and that is why when I try to reboot, Arch does not succeed in unmounting /WW, and that is why it tries to unmount it again at a later time, after networking has already been shut down, and that is why it waits for a time-out for about a minute at the end of the reboot procedure.

In fact, gam_server only keeps on living for about 20 seconds after I logged out, then it is terminated. As for menu-cached, it goes on and on living, at least for 5 minutes, which is when I got tired of watching the output of watch 'lsof | grep WW' ;-)

Any ideas how this could be remedied? Ideally, I'd like to be able to reboot using sudo reboot rather than by logging out and using GDM to reboot, but I guess that then there will be even more processes alive and accessing the NFS file system when already Arch tries to unmount it.

Oh yes, maybe this is of some interest also:

malte@bombadil $ grep DAEMONS /etc/rc.conf
# DAEMONS
DAEMONS=(syslog-ng network portmap nfslock @netfs ypbind sshd crond)

Please help

Cheers,

Malte

Last edited by einheitlix (2009-03-31 14:20:35)

JF · 2009-04-03 13:22:40

Hi einheitlix,

I read somewhere that indeed gnome has some processes quite long to stop after logging out. I don't use gnome but maybe there's options related to session management, gnome services or something like that.

Also if it's safe to do so maybe you can use your /etc/rc.d/netfs "stop)" section to deal with those processes before umounting the NFS share ?

einheitlix · 2009-04-03 21:53:48

Hi, thanks for your answer.

I forgot to mention that though I use GDM as a login manager, I don't use Gnome as a window manager; instead I use LXDE.

Anyways, your idea of modifying the "stop)" section of the init script is indeed a possible solution, I think. I could probably have it call fuser -k /WW or something similar, to kill all processes accessing the NFS share before it tries to unmount the network file systems. But is this really safe? I cannot say. It seems to be somewhat of a hack, and I don't really like fiddling around with init scripts. On the other hand, all processes get a TERM signal anyway when I reboot; using this solution some of them would only receive the signal earlier... but would it really make a difference?

What do you think? It's not really urgent since I can't try it for the next 1 1/2 weeks anyway, as I won't be working on my workstation until then, but I'd very much like to hear a few opinions from experienced Arch users

haxit · 2009-04-03 22:44:13

They never DIE! No matter how much you try to kill them, stab them, shoot them. They just never die.

PingFloyd · 2009-04-04 02:05:46

I have the same problem. menu-caches doesn't die after user logs out of the session (don't have the gamin issue though). I too am running LXDE. When a different user logs in via gdm you'll still see the menu-cached processes for other users and I end up having to kill them as root. I do believe this is a bug with either menu-caches and/or LXDE (or perhaps, more specifically, its session manager). I've looked high and low through the system to figure out where menu-cached is invoked from and for any sort of associated configuration file to no avail. I'm left with the conclusion that the invocation of menu-cached is hard-coded into start-lxde.

As a ugly-hack workaround you might try making a shell script like the following in /etc/gdm/PostSession/ directory:

#!/bin/sh

killall menu-cached

This of course is only applicable for those running gdm as their display manager. Also don't forget to make it executable.

I would imagine that menu-cached not closing on user logout is very much a bug. Or perhaps, more precisely, something that hadn't gotten put in yet. Afterall, LXDE is still a relatively new desktop. A good one at that so far, if you don't mind some of the missing polish that its dev haven't had a chance to add yet.

If someone else knows a more elegant solution than that please let me, and the other LXDE users, know.

Last edited by PingFloyd (2009-04-04 02:08:29)

the_isz · 2009-04-14 11:24:10

Hey Malte,

just registered with archlinux.org to comment to your topic. Before I forget: Nice having seen
you twice in such a short time!

On topic:

If this problem really emerges from the use of lxsession, why not try plain OpenBox? You wouldn't
have to install anything, just manually start your favourite panel through openbox' autostart script
located at ~/.config/openbox/autostart.sh.

If the problem doesn't occur with plain openbox, you might consider switching for good as you
probably don't use lxsession for anything but startup scripts anyway, which can easily be handled
with the aforementioned (is that a correct word?) script.

Nice to see that I could convince you to try Arch and you're feeling comfortable with it!

greetz,

Timo

Arch Linux

#1 2009-03-31 14:15:24

Problem with processes that just won't die...

#2 2009-04-03 13:22:40

Re: Problem with processes that just won't die...

#3 2009-04-03 21:53:48

Re: Problem with processes that just won't die...

#4 2009-04-03 22:44:13

Re: Problem with processes that just won't die...

#5 2009-04-04 02:05:46

Re: Problem with processes that just won't die...

#6 2009-04-14 11:24:10

Re: Problem with processes that just won't die...

Board footer