Some settings such as ulimit -n (open-files-limit) cannot be done from inside the daemon.
Most other daemons fork themselves so the same mechanism for restarting is built in anyway.
A signal 11 is always a bug, not normal or acceptable. So I trust you reported the backtraces from the errorlog?
Regards,
Arjen.
-------- Original message -------- From: Russell Coker <russell@coker.com.au> Date: 08/11/2013 17:07 (GMT+10:00) To: luv-main@luv.asn.au Subject: mysqld_safe seems unsafe
It's always a sign of low code quality when a daemon has a wrapper script to restart it when it crashes. Squid used to have such a script but for many years has been considered to be reliable enough not to need it.
MySQL seems to be the only commonly used daemon with such a script. I had been wondering if the script was even needed, I would have hoped that mysqld was reliable many years ago. But I checked the logs of a RHEL4 system I run and found 19 log messages about mysqld getting signal 11 since 2006 of which the last one was 4 days ago.
One problem with such scripts seems to be the issue of reliably shutting down the server. I have a ZFS system that doesn't always mount the filesystems on boot so I use /etc/rc.local to restart mysqld. That usually works apart from the time when I ended up with two copies of mysqld running at once. However mysqld uses file locking and it seems that you don't get data loss when you have two copies of it running at the same time (try not to test this theory on production networks).
While it was handy that mysqld was restarted 19 times, it wasn't good that I was unaware of the problems.
Is that script being used in the MySQL successors such as Drizzle?
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main