iprint-listener will not terminate upon gdm logout

My setup: student’s lab PC running SLED11 SP3 with iPrint and home
directories on an NFSv3 server with automount configured. For energy
saving, patching, and cleaning up temporary file the system shut down at
night and start via WOL in the morning.

My problem: From time to time on one or the other system a
iprint-listener or iprint-listener-gui process keeps running even with
no user logged in. This effectively prevents umounting the home
directory as the process keeps an open file handle on /home/$USER. As a
result the shutdown process will hang.

An example:
First the system goes from init 5 to 3 in order to force a logout in
case a user is still logged in.
$ init 3
$ w
root 22065 22063 0 18:10 ? 00:00:00
$ mount | grep home
192.168.32.139:/homes/2/alice on /home/alice type nfs
(rw,noexec,nosuid,nodev,sloppy,addr=192.168.32.139)
automount 3402 root 10u FIFO 253,3 0t0
41044 /var/run/autofs.fifo-home
automount 3402 root 11r DIR 0,22 0
13243 /home
iprint-li 12470 alice cwd DIR 0,24 16384
2358947 /home/alice (192.168.32.139:/homes/2/alice)

So with alice already logged out her iprint-listener-gui process is
still active.

I tried to kill it prior to the shutdown command but with no good success:
$ /usr/bin/killall iprint-listener; /usr/bin/killall iprint-listener-gui
iprint-listener: no process found

My NFS mount options:
-fstype=nfs,noexec,nosuid,nodev,rw,auto,nouser,async

I could switch to soft NFS mounts instead of hard ones, but this is not
considered to be really safe. Any other suggestions? How is the
iprint-listener started upon a gdm login? It should not survive a logout
or gdm shutdown in the first place.

Günther

You say ‘not good success’ but what you post seems to show that a process was successfully killed.

That shows you trying to kill to processes, iprint-listener and iprint-listener-gui. The output indicates that no processes for iprint-listener were found, but there is no mention of iprint-listener-gui, which implies that a iprint-listener-gui was killed.

E.g. I launch evince then I run

me@mine:~> killall evince me@mine:~> killall evince evince: no process found me@mine:~>
Note that lack of output from the first command. That command killed the running instance of evince.

I don’t use iPrint myself so I’ve never had cause to look at how it works.

In my experience of using NFS3 home directories a left over process owned by a user doesn’t prevent shutdown.

mikewillis wrote:[color=blue]

=?ISO-8859-15?Q?G=FCnther_Schwarz?=;22747 Wrote:[color=green]

I tried to kill it prior to the shutdown command but with no good
success:
$ /usr/bin/killall iprint-listener; /usr/bin/killall
iprint-listener-gui
iprint-listener: no process found
[/color]
You say ‘not good success’ but what you post seems to show that a
process was successfully killed.

That shows you trying to kill to processes, iprint-listener and
iprint-listener-gui. The output indicates that no processes for
iprint-listener were found, but there is no mention of
iprint-listener-gui, which implies that a iprint-listener-gui was
killed.[/color]

Yes, indeed. Still the file handle is there, and the system will not
shut down. I can try to add more time delay prior to the shutdown
command. Maybe it is just a timing issue.
[color=blue]

In my experience of using NFS3 home directories a left over process
owned by a user doesn’t prevent shutdown.[/color]

With my server (GPFS on AIX) and my mount options any open file will
prevent a shutdown. But then there should be no such file as all user
processes are supposed to terminate upon logout. iprint-listener-gui
does not behave properly.

Günther

Hi Günther,

it might be interesting to see in what state the iprint-listener-gui is, after killing it. Another thing you might want to try is to send it a different signal, like “SEGV” or even “9” after a short delay, since the process most likely already received the “original” INT, then blocked during handling that one, and now would need to be forced to terminate (which another “INT”, the default signal, obviously doesn’t do to this process).

Does that process provide some mechanism to log details/debug? My guess is that the GUI process is waiting for iprint-listener to reappear, under the condition that sometimes the GUI is killed after* the listener. On the other occasions, the GUI is killed first and everything goes well… but it’s just that, a guess :wink:

Regards,
Jens

jmozdzen wrote:
[color=blue]

it might be interesting to see in what state the iprint-listener-gui is,
after killing it. Another thing you might want to try is to send it a
different signal, like “SEGV” or even “9” after a short delay, since the
process most likely already received the “original” INT, then blocked
during handling that one, and now would need to be forced to terminate
(which another “INT”, the default signal, obviously doesn’t do to this
process).

Does that process provide some mechanism to log details/debug? My guess
is that the GUI process is waiting for iprint-listener to reappear,
under the condition that sometimes the GUI is killed after* the
listener. On the other occasions, the GUI is killed first and everything
goes well… but it’s just that, a guess ;)[/color]

Actually I have no idea what this process does. I need it, because we
are using iPrint. I put this thread into the iPrint group as well hoping
to interest some expert there.
For the time being I’m sending a second “killall” and increased the
waiting time for the shutdown. For some days all installation where
fine. I will have to wait some more time in order to see if the problem
shows up again. I was not able to reproduce it in the lab.
I am well aware that this is nothing specific to iprint. Any user
initiated process that will not terminate properly upon logout and that
keeps files open in $HOME will result in the same problem.

Günther