Rob made the following comment during the verification stage of the MySQL update.

https://bugzilla.fedora.us/show_bug.cgi?id=2129#c20
"runs ok, BUT startup script says FAILED even tho it starts fine.  this may
only be something wonky about my setup..."

Marc Deslauriers responded with:

https://bugzilla.fedora.us/show_bug.cgi?id=2129#c21
"If you set a mysql admin password, than it's normal for the init script to say
"failed"."

I also saw the FAILED startup, but attributed it to my setup of an admin
password, as Marc indicated.

The details of the update this bug refers to is now available in this Bugzilla
as bug 152797

- this is not new, it also happened on the previous mysql update, I even think
that on the one before that as well.
- it also isn't necessarily true that mysqld dies. On one system the old mysql
copy kept running, but "service mysqld stop" wasn't able to kill it. After
killing the pids manually it helped.

IMHO it should work roughly as following:
- remember if mysqld is running before updating
- if it is, do service mysqld stop in preinstall or what it's called
- if it was, after update do service mysqld start

Honestly my opinion is that this is the job of the system admin, not the
packaging system.  A system admin is responsible for the status of his DB
server.  One shouldn't rely upon the package to handle all the tasks.  Service
should be manually stopped (after agreeing upon an outage time w/ the users),
data should be backed up, package should be upgraded, service should be started,
and update should be verified before going back into production.

A package management system can't do this, it is the admins responsibility.

Can you reproduce the old mysql daemon dying after upgrading the package?  No
services are supposed to be restarted (with the exception of sshd on a glibc
update I do believe) when the package is updated.  The old daemon is supposed to
continue on like clockwork until an admin manueally restarts.  If the old mysql
dies then there is another bug we must work on, but if this is just 'it doesn't
restart itself' than it is NOTABUG.

As per comment #5 -- can someone reproduce mysql actually dying (not just not
restarting) after upgrade? NEEDINFO.

The new packages in bug 152925 may or may not fix the restart problems. Once
they're built for updates-testing, please post comments.

The new packages restarted just fine.  All the deamons are typically configured
to restart (service foo condrestart at %postun) automatically when being upgraded.

I'll mark this resolved in errata, #152925.  Re-open if it exists after
upgrading to #152925.

Hi,

today night I experienced the problem with an automated update to
Mysql-server-4.1.12 on two machines:

On both an "service mysqld status" said:

"mysqld is dead, but subsys locked".

A quick service mysql restart resolved it. Can someone add that simple
additional restart-command? I guess that would solve it.

This doesn't seem to be important enough to fix just on its own, so mark it DEFER.

I suggest we CLOSE NOTABUG.  The reopening of this bug on July 22nd, 2005, was
for a version of MySQL-server that Fedora-Legacy does not support:

  Reported problem by Thomas Schwanhäuser:  
             mysql-server-4.1.12.

Versions of mysql-server Fedora Legacy supports:

  * RH 7.3:  mysql-server-3.23.58-1.73.6.legacy.i386.rpm
  * RH 9  :  mysql-server-3.23.58-1.90.6.legacy.i386.rpm
  * FC1   :  mysql-server-3.23.58-4.4.legacy.i386.rpm
  * FC2   :  mysql-server-3.23.58-16.FC2.1.i386.rpm

AFAICT, we've never published any packages for mysql-server-4.1.12.

Sorry for having been inprecise: The platform where this occured was actually 
Fedora Core 4, but the same problem than described here (MySQL died after a 
yum update).

Assigning it to Core 4.

Perhaps this bug should also be shared with Tom Lane of RedHat (apparently the 
Fedora Core mysql maintainer) so he can be made aware of it.  

Tom, I am adding you to the to the CC: list for this bug so it will appear
on your radar.  Hope you don't mind.

I tried to duplicate this on FC4 by "yum upgrade"-ing from 4.1.12-3 to
4.1.14-1.  Worked fine for me.  However, I could believe that some people might
see the daemon stop and fail to restart, because there is a timing dependency in
the service restart script --- see bug #172426.  I'm not sure whether this
report is a duplicate of that bug, because there seems to be more than one
pathology being complained of here ...

In any case, feel free to backport the 4.1.15 initscript into FC3 and earlier if
you like.

(BTW, FC4 is not on legacy status yet is it?  I sure thought I was still on the
hook to maintain that branch.)

[Tom, no:  FC4 is not on legacy status.  I think you're still on the hook.]

This bug originated to report a problem with upgraded MySQL package(s) that
Fedora Legacy maintains.  My understanding is that the Fedora Legacy folks
felt we had resolved the problem for the versions we support and closed it
ERRATA in May, however with an invitation for our users to re-open the bug
if it still didn't work for them.  If this problem is the result of a race
condition (as Bug 172426 seems to allude to), then the WORKSFORME kind of
solution proposed when closing this bug may not have truly fixed the
underlying problem.

Thomas Schwanhäuser re-opened this bug report in July to report that he
was having the same problem with a FC4 version of MySQL (probably not 
realizing that Fedora Legacy was not responsible for the version of MySQL 
he was having trouble with), so once we noticed that the latest problem 
reported on this bug report (comment #9) was for FC4, Jesse Keating re-
assigned it from
  Product=Fedora Legacy, Version=Core1
     to
  Product=Fedora Core,   Version=fc4.
then, Tom, I added you to the cc: list so you'd have a better chance of 
seeing it.

As far as I can tell, Bug #172426 seems to indicate that whatever fix there
is for the problem has not been applied to the FC4 release of MySQL.  (Isn't
that what "CLOSED RAHIDE" means?)

If the problem potentially still exists in FC4's mysql-4.1.14-1.FC1.1 as a
race condition or an improper shutdown problem, as alluded to in Bug 172426,
are there any plans to fix the scripts for the FC4 version that Thomas
Schwanhäuser is concerned with?  I think we in Legacy would be interested 
to know that, and what the proper solution to this problem is -- so we could
also, once and for all, fix this problem for our Legacy users as well.

Is the proper solution to this problem given in Bug 172426 comment #0?  If
that's not quite the solution you'd recommend, do you have any pointers to
where we could find a good solution to this problem?

Thanks for your time, Tom.

--David Eisenstein

Hi David.  I've applied a patch for bug #172426 in mysql 4.1.15-1, which is
currently out as a test release and will be pushed to FC4 general release if I
don't hear any trouble reports in the next day or two.  I didn't like the script
patch proposed in that bug report because it would put the initscript into an
infinite loop if there was something broken; the patch as applied has a timeout.
But the basic point is good: it might take more than 2 seconds for mysql to shut
down.  I think it'd make sense to make the same patch in the Legacy releases.

What's bothering me is that it's not clear whether that issue explains all of
the entries in this bug report. The insufficient-delay problem would explain
mysql sometimes shutting down and failing to restart (because the restart
attempt would occur before the old copy finished shutting down, and would fail).
It wouldn't explain any other pathologies such as not attempting a restart at
all. It might be that those are due to other old bugs in the package spec file.
So something else I'd suggest doing is looking at the postinstall scripts in the
older spec files and seeing if they match the current spec file.

Here's the stop action as I patched it in 4.1.15:

stop(){
        MYSQLPID=`cat "$mypidfile"  2>/dev/null `
        if [ -n "$MYSQLPID" ]; then
            /bin/kill "$MYSQLPID" >/dev/null 2>&1
            ret=$?
            if [ $ret -eq 0 ]; then
                STOPTIMEOUT=60
                while [ $STOPTIMEOUT -gt 0 ]; do
                    /bin/kill -0 "$MYSQLPID" >/dev/null 2>&1 || break
                    sleep 1
                    let STOPTIMEOUT=${STOPTIMEOUT}-1
                done
                if [ $STOPTIMEOUT -eq 0 ]; then
                    echo "Timeout error occurred trying to stop MySQL Daemon."
                    ret=1
                    action $"Stopping $prog: " /bin/false
                else
                    rm -f /var/lock/subsys/mysqld
                    rm -f "$socketfile"
                    action $"Stopping $prog: " /bin/true
                fi
            else
                action $"Stopping $prog: " /bin/false
            fi
        else
            ret=1
            action $"Stopping $prog: " /bin/false
        fi
        return $ret
}
 

Thank you very much, Tom!

For Fedora Legacy, packages incorporating these changes have been submitted for
QA in bug 167803.

Thanks for incorporating these, Marc!  Excellent!

Since bug 167803 incorporated the changes that ought to fix this issue for all
four distros that Fedora Legacy works with, and Tom Lane fixed this for FC4, I'd
say we can close this bug CURRENTRELEASE or ERRATA.

  Updated Fedora Legacy packages that address this issue have been released:
<http://www.redhat.com/archives/fedora-legacy-announce/2006-January/msg00005.html>

  Updated Fedora Core packages that address this issue (for FC4) have also been 
released:
<http://www.redhat.com/archives/fedora-announce-list/2005-December/msg00082.html>