Re: Bug#370471: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts
On Wed, Jun 21, 2006 at 09:36:37AM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Jun 2006, Gerrit Pape wrote:
> > On Mon, Jun 05, 2006 at 03:36:30PM +0300, Lars Wirzenius wrote:
> > > The policy manual says (9.3.2 Writing the scripts):
> > >
> > > The init.d scripts should ensure that they will behave sensibly
> > > if invoked with start when the service is already running, or
> > > with stop when it isn't, and that they don't kill
> > > unfortunately-named user processes.
> > >
> > > Would it be acceptable to change this to say "must ensure"?
> > You might call this nitpicking, but with the current Debian init scripts
> > using start-stop-daemon, this isn't really achievable. See the
> > start-stop-daemon(8) man page:
> You should use start-stop-daemon with both --name AND --pidfile together
> (never use --exec unless you REALLY know you will always stop the daemon
> before it changes on disk) in an initscript. That changes start-stop-daemon
> into a homing killall.
> > And relying on a pidfile also doesn't guarantee that ``they don't kill
> > unfortunately-named user processes'', but actually can cause exactly
> > that, AFAICT.
> Nothing is 100% foolproof, of course. --exec is damn good at homing exactly
Well, with a different software design such ``don't kill
unfortunately-named user processes'' problem can be eliminated
completely. There's much better design of IPC than writing a pid to a
text file, and have other processes read that file and send signals to
Instead of writing their pid to a file, daemons could maintain a fifo
and read (one-byte) commands from there; if there's no reader on the
fifo, the daemon isn't running and nothing bad happens.
Or better yet, instead of duplicating such code in each and every
daemon, as already done for fork/exec, detach from terminal, cleanup
filedescriptors, setsid(), write pid file, remove all that duplicated
code, and have the service daemon run under a parent supervisor process
which maintains such a fifo. The parent process always already knows
the pid to send signals to, and knows about a service daemon terminating