init: disable spawning for shutdown

[James Hunt]

It would be very useful to be able to request that Upstart not spawn any new jobs or job instances and also not respawn any existing processes (respawn stanza).

The main use-case scenario for this is shutdown. On Ubuntu, the shutdown is delicate since both Upstart and SystemV jobs have to be handled.

Currently, the script /etc/init.d/sendsigs handles killing of processes at shutdown. It runs "initctl list" (to determine which jobs to kill, storing the list in $OMITPIDS). But between the time it runs this command and the time it actually kills those PIDS, Upstart may spawn some other jobs. Thus, we end up with PIDS that should be killed but aren't. Two checks are performed, but there is still a window of opportunity for Upstart to spawn other processes here.

A solution would appear to be some way to stop Upstart respawning any more processes. A new initctl command such as "initctl disable-spawn" could be introduced to allow existing jobs to finish, but disallow any new jobs or respawns to occur.

Thus,

  initctl disable-spawn # stop any new processes from being created by Upstart

Note that if we make this change, we should expose this setting to allow admins to query it. A better interface might therefore be something like this:

  initctl set disable-spawn 1 # disable new processes

  initctl get # get all variables
  initctl get disable-spawn # get value of disable-spawn variable

If we do *this*, maybe we should allow such syntax in /etc/init.conf?

Note that we should probably *not* allow disabling of spawning for individual jobs since:

1) That can already be handled by changing the .conf / .override file
2) If we allowed "initctl disable-spawn <job>" the .conf/.override file would be out-of-date wrt Upstarts internal state for the job.

[Scott James Remnant (scott)]

I think I'm going to do something slightly different here; the only reason to ever disable respawn is in the shutdown procedure, right now that consists of:

 * shutdown/telinit sends an event
 * user/system upstart jobs process that event
 * user/system upstart job finally calls poweroff, halt or reboot

We should turn that on its head to:

 * shutdown/telinit sends shutdown command to init
 * init sends an event
 * user/system upstart jobs process that event
 * init kills all remaining jobs
 * init sends a second event
 * user/system upstart jobs process that event
 * init calls the reboot() syscall itself

This will be ultimately much more in pattern with the Upstart way; and that shutdown command would be what disables respawning.

Does this make sense?

[James Hunt (jamesodhunt)]

Hi Scott - makes perfect sense. We'll have to be careful with respect to sessions (particularly chroots). I think the minimum would be to change bullet 2 in your proposal to:

        * init sends an event to all sessions

That way, even if the root user runs shutdown from within a chroot, all chroot environments and the "outer" (null session) environment will react correctly.