[debian-mysql] Bug#527623: mysql-server-5.0: 38_scripts__mysqld_safe.sh__signals.dpatch is inherently

[Stephane Chazelas]

2009-06-09 12:17:04 +0100, Stephane Chazelas:
> 2009-06-09 11:13:25 +0100, Stephane Chazelas:
> [...]
> > that patch is still wrong.
> > 
> > The first time a HUP is received, we run the code in the trap
> > and call wait which will wait for both the refresh command and
> > the mysqld one.
> > 
> > But we won't return from that trap until mysqld dies, and in the
> > trap the HUP signal is blocked, which means any subsequent
> > HUP will not be handled.
> [...]
> 
> That's only true with bash though. With 5 sh implementations, 4
> different behaviors:
[...]

Other interesting findings:

mysqld installs its own handler on SIGHUP, so using nohup in
mysqld_safe is not useful. (note that some implementations of
nohup also ignore SIGTERM, though I beleive they would not be
POSIX).

When you do an install or update with aptitude, aptitude messes
up the signal handlers, and in every occorrence I observed, it
ignores SIGHUP.

Most implementations of sh (the only exception I found being
zsh) will ignore a "trap" command for a signal that was already
defined to be ignored at the time the shell was started, so
in effect, if mysql has been updated via aptitude and not
restarted since then, mysqld_safe will ignore SIGHUPs.

I spent a long time trying to figure out why my mysqld_safe was
ignoring SIGHUPs and that was the reason. In other instances
(when aptitude installs a few more packages beside
mysql-server), there are more alterations to the signal
handlers. You can have a look at /proc/$(pidof mysqd_safe)/status

Now, what I would really be interested in knowing is what sends
that SIGHUP to mysqld_safe. I can't see any good reason why
anything would do that.

Best regards,
Stephane