Description of problem: When upgrading to mysql-3.23.56-1.73, the RPM appears to neither 'service mysqld stop', nor does it condrestart after the upgrade. It's a bit nit-picky, but it could prevent surprise if the %pre/post made the attempt to shut down and then restart the db as required. Version-Release number of selected component (if applicable): mysql-3.23.56-1.73 How reproducible: Every time I tried 8-) Okay, just the once. I'll accept a resolved/norepro result. Steps to Reproduce: 1. run your mysqld on your RHL 73 system. 2. rpm -Fvh mysql-3.23.56-1.73.i386.rpm 3. try a query on your db. go on. just try. Actual results: No server's around. PHP whines terribly about database connections. People drift into my office and wonder what the heck happened with (X Random service). 'service mysqld status' reports that the lockfile's there but the daemon's gone away Expected results: Happy queries, office staff blissfully ignorant of my existence so I can read userfriendly.net and work on more (gently overdue) stuff, and cron jobs obediently rpm-Fvh'ing on my content servers. Additional info: on reflection, I don't think a shutdown is required; maybe just a condrestart in %post would do it all, if it handles all cases for $1.
I updated from mysql 3.23.54 to 3.23.56 but updated 3 mysql packages (even though you only stated the mysql package). Did you freshen all packages or just mysql-3.23-56? Anyway, it worked fine for me on 7.3. The msqld service was restarted and I was able to connect. Here's the output of my run: .live.[root@i386-73 mysql]# service mysqld start Starting MySQL: [ OK ] .live.[root@i386-73 mysql]# mysql Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 to server version: 3.23.54 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> \s -------------- mysql Ver 11.18 Distrib 3.23.54, for pc-linux (i686) [snipped output] .live.[root@i386-73 i386]# rpm -Fvh mysql-3.23.56-1.73.i386.rpm mysql-server-3.2 3.56-1.73.i386.rpm mysql-devel-3.23.56-1.73.i386.rpm Preparing... ########################################### [100%] 1:mysql ########################################### [ 33%] 2:mysql-server ########################################### [ 66%] 3:mysql-devel ########################################### [100%] .live.[root@i386-73 i386]# mysql Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 to server version: 3.23.56 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> \s -------------- mysql Ver 11.18 Distrib 3.23.56, for pc-linux (i686) Connection id: 1 Current database: Current user: root@localhost Current pager: stdout Using outfile: '' Server version: 3.23.56 Protocol version: 10 Connection: Localhost via UNIX socket Client characterset: latin1 Server characterset: latin1 UNIX socket: /var/lib/mysql/mysql.sock Uptime: 44 sec However, I'm keeping this bug open as I'm going to play around with the scenario a bit more. This will also give us a chance to see if others are experiencing the same behaviour now that the errata for mysql-3.23-56 has been pushed live.
That's the *exact* scenario under which mine became lightly hosed, and I'm sorry for not providing the content that I should have; I know better. I just forced an upgrade on a RHL72 system, and it performed as your test box did, which is to say that everything just worked. I've currently got no theory that can adequately explain why my mysqld just wandered off after that upgrade, and I was only up for 26 hours at that point - the hallucinations don't show up until the third day. I recommend this one be closed, and that you don't waste any more of your vast spare time (ha ha ha) on it.
Closing.