[Interest] Triggering Actions on Application Close

[Konrad Rosenbaum]

Hi,

On Tuesday 09 July 2013 09:00:55 Till Oliver Knoll wrote:
> A) is by design: it is there to really *really* kill a process in the most
> brutal manner (*) a sysadmin could think of and a process being able to
> catch (and possibly ignore!) that signal would defeat its purpose.

> (*) which can *still* fail, depending on the state the process is in - we
> all know the "reboot your OS" song ;)

To clarify "can still fail":

You cannot kill the processes of other users, unless you are root. Otherwise:

In 99% of all cases the process dies and is gone. The process does not have 
time to delete files, correct entries, send anything over the net (for TCP the 
OS sends a RST packet that breaks the connection), etc. It's (grieving) parent 
is informed of the tragedy and the OS throws away all resources allocated 
directly to it (file handles, locks, memory, sockets). As soon as the parent 
has been informed the OS also throws away the "process structure" - i.e. those 
few bytes that hold the PID and its status (running, waiting, exited, killed, 
return code).

SIGKILL may leave behind some shared memory segments or other IPC resources if 
they were opened in shared mode (don't worry: Qt does not allocate them this 
way, so pure Qt programs are fine).

If the parent of that process is not interested in its "death" then it will 
leave behind a "Zombie process". There is no need to worry: Zombie processes 
just show up with "ps", but do not bite other processes and their resources 
are freed before they turn into zombies. Zombies only contain the "process 
structure" - everything else is gone.

If the reason for killing the process is a runaway kernel driver then the 
kernel may refuse to properly kill the process. Kill is blocked and queued for 
later if the process is inside a system call (this is called uninterruptible 
sleep) - when the process returns it is killed immediately. If the process 
does not return from such a system call then it will be hung somewhere between 
life and death: it does not do anything, but cannot die either. In this case 
you will probably need to reboot soon anyway. Boot into a more stable kernel.

I haven't worked with NFS in a long time. According to my aunt Google old NFS 
implementations were prone to hanging processes in uninterruptible sleep if 
the NFS server or the network went down. Unless you mount the NFS share with 
the "intr" option. Newer Linux kernels (after 2.6.25) allow SIGKILL to 
terminate a process hung on NFS, no matter whether you mount with "intr". This 
can still happen with FUSE file systems, also according to auntie Google you 
can save the day by killing the user space file system process (e.g. sshfs).

You cannot kill the init process (PID 1). That'd be like demolishing the house 
while you are still in it. Linux/Unix does not let you commit this kind of 
suicide.

You may not be able to kill some kernel tasks. This would be the software 
equivalent of aiming a 9mm gun at your hard disk. Ricochet kills too.



	Konrad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130709/381c6820/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130709/381c6820/attachment.sig>