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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
