Hide Forgot
Description of problem: MySQL server does not restart after reboot. Version-Release number of selected component (if applicable): mysql-5.1.71-1.el6 How reproducible: 100% Steps to Reproduce: 1. service mysqld start 2. reboot -fn Actual results: Another MySQL daemon already running with the same unix socket. Starting mysqld: [FAILED] Expected results: Starting mysqld: [ OK ] Additional info: * MySQL starts correctly with mysql-5.1.69-1.el6_4 * Suspect fix for bug 884651 - the block checking for socket existence should only matter if there's a PID attached to the other end of the socket. On unclean reboot, this socket will persist and thus cause the failure.
Perhaps the simplest thing to do is remove the socket check. I'm not sure what it gains in this particular case. If there's no mysqld pids, then the existence of the socket may not be a useful check.
Deleting this block: # and some users might prefer to configure logging to syslog.) # Note: set --basedir to prevent probes that might trigger SELinux # alarms, per bug #547485 > if [ -S "$socketfile" ] ; then > echo "Another MySQL daemon already running with the same unix socket." > action $"Starting $prog: " /bin/false > return 1 > fi $exec --datadir="$datadir" --socket="$socketfile" \ --pid-file="$mypidfile" \ --basedir=/usr --user=mysql >/dev/null 2>&1 & Allows the daemon to restart on hard reboot or after 'killall -9 mysqld'. If checking the socket is important, you can see if it is running using something like: netstat -lx | grep "$socketfile"
The netstat program is provided by net-tools, a dependency of initscripts, so using this command would work fine. [root@localhost ~]# rpm -qf `which netstat` net-tools-1.60-110.el6_2.x86_64 [root@localhost ~]# rpm -q --whatrequires net-tools initscripts-9.03.40-2.el6.x86_64 facter-1.6.6-1.el6_4.x86_64 [root@localhost ~]# rpm -q --whatrequires initscripts | grep mysql-server mysql-server-5.1.71-1.el6.x86_64 - if [ -S "$socketfile" ] ; then + if netstat -lx | grep -q "$socketfile"; then [root@localhost ~]# service mysqld start Starting mysqld: [ OK ] [root@localhost ~]# export socketfile="/var/lib/mysql.sock" [root@localhost ~]# if [ -S "$socketfile" ]; then echo Yup; else echo Nope; fi Yup [root@localhost ~]# service mysqld stop Stopping mysqld: [ OK ] [root@localhost ~]# if [ -S "$socketfile" ]; then echo Yup; else echo Nope; fi Nope [root@localhost ~]# if netstat -lx | grep -q "$socketfile"; then echo Yup; else echo Nope; fi Yup [root@localhost ~]# killall -9 mysqld mysqld_safe [root@localhost ~]# if [ -S "$socketfile" ]; then echo Yup; else echo Nope; fi Yup <-- BAD [root@localhost ~]# if netstat -lx | grep -q "$socketfile"; then echo Yup; else echo Nope; fi Nope One could also use 'fuser' instead: [root@localhost ~]# if [ -S "$socketfile" ]; then echo Yup; else echo Nope; fi Yup [root@localhost ~]# if fuser "$socketfile" &> /dev/null; then echo Yup; else echo Nope; fi Nope (fuser is required by initscripts as well)
Whoops, forgot to add positive unit test result for using fuser (above is negative test; e.g. after killing mysqld_safe & mysqld): [root@localhost ~]# service mysqld start Starting mysqld: [ OK ] [root@localhost ~]# if [ -S "$socketfile" ]; then echo Yup; else echo Nope; fi Yup [root@localhost ~]# if fuser "$socketfile" &> /dev/null; then echo Yup; else echo Nope; fi Yup
Lon, thank you for the elaboration. I'd like to use the fuser approach. I've tested it as well and it seems to work fine. Pure removing the check is not an option, since it is not only a fix for bug 884651, but it also prevents mysqld_safe to remove the socket file of different process: /usr/bin/mysqld_safe:598 rm -f $safe_mysql_unix_port "$pid_file" # Some extra safety Simple steps to reproduce this issue are: 1) root> service mysqld start 2) root> killall -9 mysqld_safe mysqld 3) root> service mysqld start Actual results: Another MySQL daemon already running with the same unix socket. Starting mysqld: [FAILED] Expected results: Starting mysqld: [ OK ]
Created attachment 832221 [details] proposed patch that uses fuser call
Tested and approved :]
Unit test with patch applied: [root@localhost init.d]# service mysqld start Starting mysqld: [ OK ] [root@localhost init.d]# echo $? 0 [root@localhost init.d]# netstat -lx | grep mysql unix 2 [ ACC ] STREAM LISTENING 882338 /var/lib/mysql/mysql.sock [root@localhost init.d]# killall -9 mysqld mysqld_safe [root@localhost init.d]# ls -l /var/lib/mysql/mysql.sock srwxrwxrwx. 1 mysql mysql 0 Dec 3 14:38 /var/lib/mysql/mysql.sock [root@localhost init.d]# service mysqld start Starting mysqld: [ OK ] [root@localhost init.d]# echo $? 0 All good.
*** Bug 1042644 has been marked as a duplicate of this bug. ***
Same problem still here. Please, make an update. Thank you.
Same problem happened here (after unexpected VM host reboot). guys, any ETA on that one? Work around: # service mysqld stop # mv /var/lib/mysql/mysql.sock /var/lib/mysql/mysql.sock.bak # service mysqld start
The fix works here.
Works here too, and needed. Please RH, can we have this fixed soon?
We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness. If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization to assure a timely resolution. For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto
@Ondrej Vasik, I am not requesting support, I am hoping to "guide your efforts at improving your products." :)
I know, but you are requesting "fixed soon" ... and we can't guarantee that without support escalation.
I fixed this 3 years, 11 months ago in Mandriva, please look here: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/mysql/current/SOURCES/mysql-initscript.diff?view=log
Parts from this one: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/mysql/current/SOURCES/mysql-initscript.diff?r1=506776&r2=510787&view=patch And maybe this one: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/mysql/current/SOURCES/mysql-initscript.diff?r1=541788&r2=542042&view=patch
Oh, I just realized you have to add the logic for the socket, well :)
I'm a bit confused now. It seems the only issue we have right now is handling the socket that nobody uses any more. The solutions we're going to use is to check if the socket file is being used by some process using "fuser" utility. Or do you have some other particular considerations? Because it seems to me you solved different issues with your patches.
(In reply to Honza Horak from comment #24) > I'm a bit confused now. It seems the only issue we have right now is > handling the socket that nobody uses any more. The solutions we're going to > use is to check if the socket file is being used by some process using > "fuser" utility. Or do you have some other particular considerations? > Because it seems to me you solved different issues with your patches. Yes, disregard that. The fixes are for stale pid files and other stuff.
So like. I get that redhat wants escalation through support and stuff but what the hell. Install a new version of 6.5 and freaking mysql does not work correctly? Pretty bad that they took the time to reply and say they will not do anything instead of using that time to just fix it. I just figured big company, mysql is used in enterprises, big issue. Nope. Sorry for the rant. I see that it is included in the next release... Can anyone tell me the proper way to apply this patch?
(In reply to webdawg from comment #26) > Can anyone tell me the proper way to apply this patch? No need to apply the patch manually, since the fixed package is already delivered. See more at https://bugzilla.redhat.com/show_bug.cgi?id=1058719#c9