Re: Killing processes on system shutdow

[Thomas Bushnell, BSG]

Roland McGrath <roland@gnu.org> writes:

> At the moment, I think most every filesystem getting SIGHUP or SIGTERM will
> just die (the default action for those signals).  Probably the most useful
> thing is for filesystems to canonically handle these signals and respond to
> them by starting a syncfs and then dying as soon as they have no live users.
> Filesystems could just ignore the signals and wait for shutdown
> notification, but it seems appropriate for going to single-user to kill any
> random filesystem processes not still in use.

Originally /hurd/init was responsible for the BSD init signal handling
*and* the reboot-halt syscall.  That made it easy to arrange that a
program which registered a shutdown didn't get killed going to single
user (as you note below).

It seems quite rational that SIGTERM should cleanly shutdown any
filesystem though; we should make that a TODO item.  Then the Right
Thing happens, regardless what /hurd/init does.

> I'm really not sure whether we want to have any kind of general feature to
> try to make a process immune to SIGKILL (if chosen by root); I tend to think
> not.  We could instead add some sort of flag that could be set on a process
> and passed as required in a proc_getallpids variant call, that kill(-1,)
> would use to intentionally overlook certain processes.

I don't think we really need this at all.  

> I think that if we have a delay of a few seconds between SIGTERM and SIGKILL
> (as the others all do), then it is fairly reasonable to leave no way to
> avoid the SIGKILL for all but the essential system servers.  

I believe this is what we should do.

> In the case of a nonessential filesystem, at the initial SIGTERM it
> will go into "dying mode", and all its users will have gotten a
> SIGTERM too and should be going away shortly; when they've all gone
> away, the server syncs and dies (hopefully all that doesn't take 5
> seconds).  So they should be gone by the time the SIGKILL comes.

The point of the SIGKILL is to fix things that SIGTERM don't kill.
That means its reasonable to say that if SIGTERM didn't work, things
are already broken.  (Well, SIGTERM + SIGHUP, since shells are
supposed to ignore the former and only respond to the latter.)

> Now, if some user program is wedged so it doesn't die on SIGTERM and
> keeps a file open, then the filesystem will stay around and won't
> have been able to finish unmounting by the time it and its user both
> get SIGKILL.  But I'm not sure of a good way to avoid that problem.

I don't think it's a problem.  The filesystem can't unmount, but it
*can* sync the disk to a sane state, and that's all that's required.