Bug 152531 - mysql doesn't restart after update
mysql doesn't restart after update
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mysql (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Fedora Legacy Bugs
LEGACY, 1, rh73, rh90, 2, DEFER
:
Depends On: 167803
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-29 20:56 EST by Marc Deslauriers
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-11 00:00:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marc Deslauriers 2005-03-29 20:56:15 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
Latest FL update didn't restart the mysql daemon after upgrading.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Start mysqld
2.run a yum update
3.notice that mysqld is not running
  

Actual Results:  mysql is not restarted

Expected Results:  mysql should be restarted by the update

Additional info:
Comment 1 Mark Scott 2005-03-30 02:41:33 EST
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.
Comment 2 Mark Scott 2005-03-31 03:15:47 EST
The details of the update this bug refers to is now available in this Bugzilla
as bug 152797
Comment 3 Peter Surda 2005-04-01 12:15:58 EST
- 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
Comment 4 Jesse Keating 2005-04-01 12:18:50 EST
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.
Comment 5 Jesse Keating 2005-04-01 14:50:28 EST
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.
Comment 6 Matthew Miller 2005-04-12 13:55:11 EDT
As per comment #5 -- can someone reproduce mysql actually dying (not just not
restarting) after upgrade? NEEDINFO.
Comment 7 Marc Deslauriers 2005-04-14 08:24:50 EDT
The new packages in bug 152925 may or may not fix the restart problems. Once
they're built for updates-testing, please post comments.
Comment 8 Pekka Savola 2005-05-06 01:37:54 EDT
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.
Comment 9 Thomas Schwanhäuser 2005-07-22 18:04:02 EDT
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.
Comment 10 Pekka Savola 2005-11-16 08:17:12 EST
This doesn't seem to be important enough to fix just on its own, so mark it DEFER.
Comment 11 David Eisenstein 2005-11-17 18:14:37 EST
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.
Comment 12 Thomas Schwanhäuser 2005-11-17 18:29:52 EST
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).
Comment 13 Jesse Keating 2005-11-17 18:34:32 EST
Assigning it to Core 4.
Comment 14 David Eisenstein 2005-11-18 03:41:00 EST
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.
Comment 15 Tom Lane 2005-11-21 12:29:56 EST
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.)
Comment 16 David Eisenstein 2005-11-22 02:30:37 EST
[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
Comment 17 Tom Lane 2005-11-22 10:13:11 EST
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
}
 
Comment 18 David Eisenstein 2005-11-23 03:41:52 EST
Thank you very much, Tom!
Comment 19 Marc Deslauriers 2005-11-27 09:32:15 EST
For Fedora Legacy, packages incorporating these changes have been submitted for
QA in bug 167803.
Comment 20 David Eisenstein 2005-11-28 17:43:28 EST
Thanks for incorporating these, Marc!  Excellent!
Comment 21 David Eisenstein 2006-01-10 22:10:44 EST
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>

Note You need to log in before you can comment on or make changes to this bug.