+++ 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.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 hsqldb:x:100:101::/var/lib/hsqldb:/sbin/nologin /\ missing mysql user. # grep sql /etc/shadow hsqldb:!!:13190:0:99999:7::: mysql:!!:13190:::::: /\ mysql is present. # grep sql /etc/group hsqldb:x:101: mysql:x:27: # grep sql /etc/gshadow hsqldb:x:: mysql:!:: # rpm -qa|grep mysql|sort libdbi-dbd-mysql-0.8.1a-1.2.1 mysql-5.0.18-2.1 mysql-connector-odbc-3.51.12-1.2.1 mysql-server-5.0.18-2.1 [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 hsqldb:x:100:101::/var/lib/hsqldb:/sbin/nologin mysql:x:27:27::/var/lib/mysql:/sbin/nologin # grep sql /etc/shadow hsqldb:!!:13190:0:99999:7::: mysql:!!:13222:::::: [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 /var/log/messages.2006-03-11.bad-iso.mount.txt -rw------- 1 root root 741484 Mar 13 00:36 /var/log/messages.2006-03-12.before-suspend.tt -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.
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 || : fi if [ $1 = 0 ] ; then userdel mysql >/dev/null 2>&1 || : fi which certainly looks like it should not cause such a problem during an upgrade.
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.
OK, sorry for the confusion - it appears the missing mysql user was NOT caused by the mysql upgrade - closing this bug.