initscript: Do I have to wait for a service to stop?

[Richard W.M. Jones]

I'm trying to fix a bug:
https://bugzilla.redhat.com/523391
initscript collected problems LSB-compilant watchdog

It's all fairly straightforward except for the 'watchdog stop'
operation.

Now when you send a signal to the watchdog daemon, it can take several
seconds to shut down.  The usual 'killproc' function would handle this
by sending a SIGTERM, waiting a few seconds, then sending a SIGKILL.

However for the Linux watchdog API, this is a very bad idea: if you
kill the daemon before it has properly cleaned up, then it might not
have "disarmed" the watchdog, with the result that your machine could
suddenly hard reboot some seconds later.  Oops.

We don't want that so we use 'killproc -TERM' which disables the
waiting bit and the final SIGKILL.  The watchdog daemon is pretty
well-behaved and does eventually terminate[1].

Because the watchdog hasn't shut down when the init script returns,
the LSB script test for this fails.

So I don't know how to fix that one.  Any suggestions?

Rich.

[1] Note: After an arbitrarily long time .. it could be in the middle
of running an external user-supplied test script at the time.  The
upper bound on these is the watchdog timeout, which is configurable
and determined by a combination of the conf file, the device driver,
and the hardware itself.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

[Petr Pisar]

On 2011-01-17, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  Now when you send a signal to the watchdog daemon, it can take several
>  seconds to shut down. 
I hope systemd and similar inits running daemons on foreground solve
this problem simply by waiting for the child's PID.

>  So I don't know how to fix that one.  Any suggestions?
>  
I met this problem in `dibbler' code (http://klub.com.pl/dhcpv6/). I solved
it by ptracing the daemon, sending signal, and waiting for the daemond
exit using ptrace.

-- Petr

[Lennart Poettering]

On Mon, 17.01.11 14:31, Petr Pisar (ppisar(a)redhat.com) wrote:

>  
>  On 2011-01-17, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  >
>  > Now when you send a signal to the watchdog daemon, it can take several
>  > seconds to shut down.
>  
>  I hope systemd and similar inits running daemons on foreground solve
>  this problem simply by waiting for the child's PID. 
Yes, that's what happens in systemd. However we currently use SIGKILL
after a timeout, if the normal kill signal (SIGTERM usually) didn't
work. I have now added to my TODO list to make this SIGKILL step
optional.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Simo Sorce]

On Mon, 17 Jan 2011 21:54:18 +0100
Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:

>  On Mon, 17.01.11 14:31, Petr Pisar (ppisar(a)redhat.com) wrote:
>  
>  > 
>  > On 2011-01-17, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  > >
>  > > Now when you send a signal to the watchdog daemon, it can take
>  > > several seconds to shut down.
>  > 
>  > I hope systemd and similar inits running daemons on foreground solve
>  > this problem simply by waiting for the child's PID.
>  
>  Yes, that's what happens in systemd. However we currently use SIGKILL
>  after a timeout, if the normal kill signal (SIGTERM usually) didn't
>  work. I have now added to my TODO list to make this SIGKILL step
>  optional. 
SIGKILLing databases and similar stuff is not a good idea indeed, they
may be committing data to disk, and you don't want to corrupt data if
it can be helped.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Tom Lane]

"Richard W.M. Jones" <rjones(a)redhat.com&gt; writes:
>  Because the watchdog hasn't shut down when the init script
> returns,
>  the LSB script test for this fails. 
>  So I don't know how to fix that one.  Any suggestions? 
The traditional approach is to wait till you see the daemon has removed
its pidfile, which it ought to do only as the last externally visible
step in its shutdown.

			regards, tom lane