cannot send QUIT signal on 'stop'

Bug #605007 reported by Scott Moser
This bug report is a duplicate of:  Bug #94873: init: support custom actions. Edit Remove
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
upstart (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: upstart

I'm attempting to wirte an upstart job for xinetd under bug 43574.

In the init.d script, 'stop' action sends signal QUIT to the process. I can't find any way to do this in an upstart job. From the xinetd man page, the difference between QUIT and TERM is:
- SIGQUIT causes program termination.
- SIGTERM terminates all running servers before terminating xinetd.

The first attempt at a solution was a pre-stop section like:

pre-stop script
  kill -QUIT $(status | awk '/stop\/pre-stop/ { print $NF }')
  exit 0
end script

That works, unless 'respawn' is also used. If respawn is enabled, then the job will continually be respawned when it is 'stop'ped because it received the 'QUIT' signal from the pre-stop script. For example:
$ sudo start xinetd
xinetd start/running, process 17650
$ sudo stop xinetd
xinetd start/running, process 17697

I can think of 2 options here:
a.) as with 'task' jobs, if the service exits zero (which this one does), upstart could not re-start the job.
b.) add explicit support for "send specific kill signal on stop".

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: upstart 0.6.5-6
ProcVersionSignature: User Name 2.6.32-305.9-ec2 2.6.32.11+drm33.2
Uname: Linux 2.6.32-305-ec2 i686
Architecture: i386
Date: Tue Jul 13 12:55:47 2010
Ec2AMI: ami-82b65deb
Ec2AMIManifest: ubuntu-images-testing-us/ubuntu-maverick-daily-i386-server-20100710.manifest.xml
Ec2AvailabilityZone: us-east-1b
Ec2InstanceType: m1.small
Ec2Kernel: aki-078e676e
Ec2Ramdisk: unavailable
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: upstart

Revision history for this message
Scott Moser (smoser) wrote :
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Scott, I would agree, there needs to be a way to redefine the signals sent, since some daemons like apache also respond violently to SIGHUP versus say SIGUSR1, on reload.

This appears to be a known concern upstream, so is basically a duplicate of bug #94873

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.