sendsigs can kill upstart scripts' child processes prematurely on system shutdown

Bug #639940 reported by John Morrissey
44
This bug affects 8 people
Affects Status Importance Assigned to Milestone
sysvinit (Ubuntu)
Won't Fix
Medium
Unassigned

Bug Description

Binary package hint: sysvinit

sendsigs can kill child processes executed as part of upstart pre/post-stop scripts. It successfully omits upstart processes (daemons and the script processes themselves), but if you use anything other than shell builtins in an upstart job script, those shell-spawned processes don't wind up in OMITPIDS and killall5 kills them.

For example, 143 (15/SIGTERM) ends up in /tmp/foo with a script like this.

  pre-stop script
    sleep 30 || echo $? >/tmp/foo
  end script

Also, the post-SIGTERM loop ends prematurely because killall5 supports a maximum of 16 omitted processes (LP#634460). In my case, the ssh (LP#603363), portmap, statd, and (obviously) rc upstart jobs are still running. Each iteration of the post-SIGTERM loop duplicates these processes in OMITPIDS. On the fifth iteration, the list overflows and killall5 terminates with exitstatus 1. The loop terminates prematurely, since it interprets killall5 failure as an indicator that all SIGTERMed processes have terminated.

The attached sendsigs fixes both problems. It won't kill processes that are children of upstart processes. In doing so, it avoids the use of killall5(1), allowing SIGTERMed processes the full ten seconds to shut down gracefully before SIGKILL. If killall5 had parent process checking, using that would be faster, but the fixed omitpid list size would still be a problem. Doing it "by hand" in the shell is reasonably fast, since there shouldn't be many processes still running.

Tags: patch
Revision history for this message
John Morrissey (jwm) wrote :
Revision history for this message
Valentijn Sessink (valentijn) wrote :

I might have overlooked it, but I could not find the PID of the sendsigs-revised.sh script itself as an "omit" PID inside the script. I.e. isn't there a possibility the script kills itself now? Or did I miss something?

Revision history for this message
John Morrissey (jwm) wrote : Re: [Bug 639940] Re: sendsigs can kill upstart scripts' child processes

On Wed, Sep 22, 2010 at 09:23:51AM -0000, Valentijn Sessink wrote:
> I might have overlooked it, but I could not find the PID of the
> sendsigs-revised.sh script itself as an "omit" PID inside the script.
> I.e. isn't there a possibility the script kills itself now? Or did I
> miss something?

sendsigs is executed via the upstart 'rc' job, so it will be omitted because
of the exception for child processes of upstart jobs.

john
--
John Morrissey _o /\ ---- __o
<email address hidden> _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

Nick Barcet (nijaba)
Changed in sysvinit (Ubuntu):
status: New → Confirmed
Nick Barcet (nijaba)
Changed in sysvinit (Ubuntu):
milestone: none → ubuntu-10.04.2
Revision history for this message
Christian Reis (kiko) wrote : Re: sendsigs can kill upstart scripts' child processes

John, just to clarify, killall5 is usually only run upon system shutdown, right? If so, the bug title should probably clarify that this only applies to that situation, and not to routine start/stopping of daemons.

John Morrissey (jwm)
summary: - sendsigs can kill upstart scripts' child processes
+ sendsigs can kill upstart scripts' child processes prematurely on system
+ shutdown
Revision history for this message
Colin Watson (cjwatson) wrote :

FYI, I fixed killall5's restriction on the number of omitted pids in maverick.

Revision history for this message
Fabián Rodríguez (magicfab) wrote :

Milestone removed after confirming there is no fix for this in 11.04 (so, no SRU requested ATM).

Changed in sysvinit (Ubuntu):
milestone: ubuntu-10.04.2 → none
Changed in sysvinit (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Changed in sysvinit (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.