Score:0

MySQL log filling up with unwanted "Status information" on server reboot due to SIGHUP

dj flag

This has been plaguing me for a while, so it's time to ask.

The MySQL error_log fills up with "Status information" when the server reboots due to SIGHUP. Here is a link describing the behavior: MySQL Server response to SIGHUP signals

I understand what's going on, but don't know how to fix it.

I have one script that controls the starting/stopping of mysqld: /etc/init.d/mysql

And here is the sourced mysql-helpers file referenced by the init.d script.

I can't find where the SIGHUP is coming from? Or maybe it's coming from the OS? Debian 10.

Edit

Doing service mysql restart or stop never produces the extra log entry, so maybe it has something to do with the shutdown process during server reboot|halt? I don't understand SIGHUP enough to determine if I'm on the right track or not.

us flag
Please add details about your operating system. Is your init.d-script being called during an orderly shutdown of the system?
Jeff avatar
dj flag
OS is Debian 10 Buster with default kernel. The init.d script is called during `shutdown -r now` or `shutdown -h now`. I'm not sure if it's an "orderly" shutdown or not.
Cameron Kerr avatar
id flag
Is this a VM or a physical machine? I only ask because (many) years ago I had encountered an issue where a lot of SIGHUP was due to failing memory, so doing a memory test may be useful.... but this if definately clutching at straws. I'd first start with seeing what else is running on the box. Any monitoring / metrics / configuration management?
Cameron Kerr avatar
id flag
SIGHUP is sent to MySQL when you do a things like flush grant tables or logs... is the behaviour you are seeing due to tools such as logrotate? Is there anything odd going on the the mysql.users table etc.? What can you determine based on when the activity happens?
Jeff avatar
dj flag
@CameronKerr The machine is a VM. No monitoring software running. The only thing I can think of is possibly the replacement of `killall` with `mysqladmin shutdown` in the /etc/init.d/mysql script. Not sure though. Knowing *when* SIGHUP is sent to mysqld is helpful, though. In the meantime, any other suggestions are more than welcome.
us flag
if during shutdown your init.d-script is not run, all remaining processes (including mysql) will get a SIGHUP followed bei SIGKILL it smells like this is what is happening there.
Jeff avatar
dj flag
@Nils Your comment turned out to be the correct answer. If you'd like to post an answer, I'll mark it as correct. The final solution turned out to be changing the start/stop script from sysvinit to systemd.
Score:0
us flag

If during shutdown your init.d-script is not run, all remaining processes (including mysql) will get a SIGHUP followed bei SIGKILL it smells like this is what is happening there.

Jeff avatar
dj flag
That's exactly what was happening. Switched from init.d to systemd and everything is peachy now.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.