Bug 185540 - mysql user removed and not recreated during upgrade
mysql user removed and not recreated during upgrade
Product: Fedora
Classification: Fedora
Component: mysql (Show other bugs)
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Tom Lane
David Lawrence
Depends On: 185168
  Show dependency treegraph
Reported: 2006-03-15 12:25 EST by Jason Vas Dias
Modified: 2013-07-02 23:09 EDT (History)
5 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Jason Vas Dias 2006-03-15 12:25:08 EST
+++ This bug was initially created as a clone of Bug #185168 +++

Description of problem:

Somehow, during an upgrade, the mysql user was removed, and not restored.
This prevented logrotate from being able to rotate ANY log files.

-- Additional comment from dtimms@bigpond.net.au on 2006-03-14 21:24 EST --
Hi Jason,
*** note: user and group gui tool won't start (error): shows no groups nor users.
*** I didn't manually remove the mysql user
# grep sql /etc/passwd
/\ missing mysql user.
# grep sql /etc/shadow
/\ mysql is present.
# grep sql /etc/group
# grep sql /etc/gshadow
# rpm -qa|grep mysql|sort
[root@davidthome ~]# service mysqld status
mysqld is stopped
[root@davidthome ~]# service mysqld start
chown: `mysql:mysql': invalid user
chown: `mysql:mysql': invalid user
*** as you have found!
[root@davidthome ~]# grep mysql /var/log/yum.log*
/var/log/yum.log:Feb 20 00:47:22 Updated: mysql.i386 5.0.18-2.1
/var/log/yum.log:Feb 20 00:52:39 Updated: mysql-server.i386 5.0.18-2.1
/var/log/yum.log:Feb 20 00:52:47 Updated: mysql-connector-odbc.i386 3.51.12-1.2.1
/var/log/yum.log:Feb 20 00:52:47 Updated: libdbi-dbd-mysql.i386 0.8.1a-1.2.1
/var/log/yum.log:Mar 05 13:47:41 Erased: mysql-server
/var/log/yum.log:Mar 05 13:49:24 Installed: mysql-server.i386 5.0.18-2.1

*** I did notice the mysql start user error during startup, and uninstalled /
reinstalled to try to fix it. As you say that process didn't actually fix a
login / user problem.

# useradd -u 27 -g mysql -n -r -M -s /sbin/nologin -d /var/lib/mysql mysql
# grep sql /etc/passwd
# grep sql /etc/shadow 
[root@davidthome ~]# service mysqld status
mysqld is stopped
[root@davidthome ~]# service mysqld start

** after 15 seconds, prompt not returned.
# service mysqld status
mysqld is stopped
#sy-co-se mysql start waits 30 seconds then says:
  service mysqld started, but updates the status to mysqld dead but subsys locked.
# ls -l /var/lock/subsys/mysqld
-rw-r--r-- 1 root root 0 Mar 15 12:17 /var/lock/subsys/mysqld
[root@davidthome ~]# rm /var/lock/subsys/mysqld
rm: remove regular empty file `/var/lock/subsys/mysqld'? y

* retry the service start fails identically.
* pirut remove / install mysql-server (with the fixed mysql user)
* mysql now start OK.
* # /usr/sbin/logrotate /etc/logrotate.conf
error: Ignoring yum.rpmorig, because of .rpmorig ending
[root@davidthome anacron]# ls -l /var/log/me*
-rw------- 1 root root     594 Mar 15 13:28 /var/log/messages
-rw------- 1 root root  371462 Mar 15 13:28 /var/log/messages.1
-rw------- 1 root root  143817 Feb 12 10:08 /var/log/messages.2
-rw------- 1 root root 2932210 Mar 11 13:02 /var/log/messages.2006-03
-rw------- 1 root root   42661 Mar 11 13:13
-rw------- 1 root root  741484 Mar 13 00:36
-rw------- 1 root root  182387 Mar 13 11:38 /var/log/messages.2006-03-13.txt

So, after fixing the username for mysql, reinstalling mysqld, I can now
successfully run Logrotate manually, and it does it's thing.


We need to figure out how the mysql userid got removed during the upgrade -
this should not have happened.
Comment 1 Tom Lane 2006-03-15 12:53:07 EST
I'm inclined to think that this is not the fault of the mysql package, but
somewhere else.  How could his system have gotten into a state where the mysql
user is listed in /etc/shadow but not /etc/passwd?  The mysql RPM certainly
doesn't muck with those files directly.  It just does

%postun server
if [ $1 -ge 1 ]; then
    /sbin/service mysqld condrestart >/dev/null 2>&1 || :
if [ $1 = 0 ] ; then
	userdel mysql >/dev/null 2>&1 || :

which certainly looks like it should not cause such a problem during an upgrade.
Comment 2 David Timms 2006-03-15 20:09:18 EST
Tom/Jason, sorry to lead you on a bum steer.

It hit me last night that early in February, when I installed FC5T2 + updated,
that I connected to another of my machines on FC4 and meant to sftp in my
favourite /etc/hosts (with add blocking, internal addresses etc).

But a brain slip had me copy in /etc/passwd. Since I didn't have a backup on the
new machine, I retrieved /etc/passwd from another FC5T2 machine (with same
root/users) that I was tesing on, and this got me going again ie could log in as
user davidt. I though I had solved my problem.

But thanks to Jason's help, I've remembered overnite that I had done this: I
think the recovery passwd machine did not have mysql installed at that stage !
So that is the likely cause of the mismatch between passwd and shadow that was
causing service mysqld start to fail, and may have been causing the rpm scripts
to bomb out (and other pup upgrades).

I guess more robustness in such a situation could be programmed in, or at least
logged to messages / root mail so that an admin could know there is something
going wrong. E.g. at boot, the p/shadown and g/gshadow could be tested for
correctness and linking. Probably not needed for a Fedora user machine, but
could be nice on Redhat commercial machine and hence be value added to Fedora.
Comment 3 Jason Vas Dias 2006-03-17 11:48:12 EST
OK, sorry for the confusion - it appears the missing mysql user was NOT caused
by the mysql upgrade - closing this bug.

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