| Bug #37165 | MySQL-*-5.1.25-0.glibc23.x86_64.rpm fail to install on Fedora 9 x86_64 | ||
|---|---|---|---|
| Submitted: | 3 Jun 2008 16:29 | Modified: | 29 Aug 2011 17:11 |
| Reporter: | Georgi Kodinov | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Packaging | Severity: | S2 (Serious) |
| Version: | 5.1.25-rc, 5.1.35 | OS: | Linux (Fedora 9 x86_64) |
| Assigned to: | Joerg Bruehe | CPU Architecture: | Any |
[3 Jun 2008 16:29]
Georgi Kodinov
[4 Jun 2008 9:22]
Tonci Grgin
Joro. Using FC5 x64 AMD I can not repeat your problem: [root@FC5X64 Joro]# rpm -i MySQL-client-5.1.25-0.glibc23.x86_64.rpm MySQL-server-5.1.25-0.glibc23.x86_64.rpm PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! To do so, start the server, then issue the following commands: /usr/bin/mysqladmin -u root password 'new-password' /usr/bin/mysqladmin -u root -h FC5X64 password 'new-password' Alternatively you can run: /usr/bin/mysql_secure_installation which will also give you the option of removing the test databases and anonymous user created by default. This is strongly recommended for production servers. See the manual for more instructions. Please report any problems with the /usr/bin/mysqlbug script! The latest information about MySQL is available at http://www.mysql.com/ Support MySQL by buying support/licenses from http://shop.mysql.com/ Starting MySQL.[ OK ] [root@FC5X64 Joro]# mysql -uroot Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 Server version: 5.1.25-rc MySQL Community Server (GPL) Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> show databases; +---------------------+ | Database | +---------------------+ | information_schema | | bin | | cluster | | include | | info | | lib | | libexec | | man | | mysql | | #mysql50#mysql-test | | share | | #mysql50#sql-bench | | test | | var | +---------------------+ 14 rows in set (0.02 sec) mysql> quit Bye [root@FC5X64 Joro]# uname -a Linux FC5X64 2.6.16-1.2111_FC5 #1 SMP Thu May 4 21:16:04 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux I had some stuff in /var/lib/mysql remaining from standard FC5 MySQL installation although I removed it and all programs with dependencies on MySQL libs prior to installation. If this affects your test please reopen the report.
[4 Jun 2008 9:30]
Tonci Grgin
o) Uninstalled 5.1.25-rc o) Removed /var/lib/mysql o) Reinstalled 5.1.25-rc all works as expected.
[4 Jun 2008 9:50]
Tonci Grgin
Rechecked and removed everything connected to MySQL from the box, reinstalled, no error: o) Removed everything o) Reinstall: [root@FC5X64 Joro]# rpm -i MySQL-client-5.1.25-0.glibc23.x86_64.rpm MySQL-server-5.1.25-0.glibc23.x86_64.rpm PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! To do so, start the server, then issue the following commands: /usr/bin/mysqladmin -u root password 'new-password' /usr/bin/mysqladmin -u root -h FC5X64 password 'new-password' Alternatively you can run: /usr/bin/mysql_secure_installation which will also give you the option of removing the test databases and anonymous user created by default. This is strongly recommended for production servers. See the manual for more instructions. Please report any problems with the /usr/bin/mysqlbug script! The latest information about MySQL is available at http://www.mysql.com/ Support MySQL by buying support/licenses from http://shop.mysql.com/ Starting MySQL.[ OK ] [root@FC5X64 Joro]# mysql -uroot Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 Server version: 5.1.25-rc MySQL Community Server (GPL) Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | test | +--------------------+ 3 rows in set (0.00 sec) mysql>
[4 Jun 2008 17:20]
Timothy Smith
I seem to be able to reproduce this on a centos4 box. This fails: sudo /etc/init.d/mysql start This succeeds: sudo /bin/sh /etc/init.d/mysql start I changed the top of /etc/init.d/mysql to: #! /bin/sh -x It appears that the script is working correctly. But mysqld_safe doesn't create the pid file in the first case, and doesn't write anything to the error log. I am now looking into the mysqld_safe behavior.
[5 Jun 2008 5:56]
Tonci Grgin
Good Tim, I worked from root account, as is my habit. Probably that prevented error from showing up?
[5 Jun 2008 11:52]
Georgi Kodinov
Tim "sudo /bin/sh /etc/init.d/mysql start" indeed is allowing the MySQL to start correctly, whereas "sudo /etc/rc.d/init.d/mysql start" will not start it on my Fedora 9. I have the F9 box back now. ping me if you need access to it.
[13 Jun 2008 18:27]
Mustafa Lakdawala
After intalling rpms for MySQL client/server version 5.1.25 on Centos 5.1 I cannot start the cluster. Error reported is the same as mentioned in this bug . Starting MySQL...Manager of pid-file quit without updating file.[FAILED] I have tried the 'sudo /bin/sh /etc/init.d/mysql start but error continues. In the error file, I get 080613 18:01:44 [ERROR] /usr/sbin/mysqld: unknown option '--ndbcluster' I can't figure out where the server is picking up the ndbcluster option from ? Mustafa
[16 Jun 2008 14:52]
Mustafa Lakdawala
Did I say cluster? I meant server. I haven't even got past the server installation. Cluster is still a long way to go. By the way before installing the 5.1.25 version I had a 5.1.22 (server,client and cluster) running perfectly on these boxes. Mustafa
[4 Jul 2008 1:49]
Jay Borenstein
I got this error message when the permissions where not properly set for the mysql/data directory. Once I changed those to be owned by the user running mysql, all was well.
[13 Aug 2008 1:58]
N Bernhardt
The error message might be misleading. I just faced the same problem creating the default database mysql with user root. Once the database folder is chown'ed to the MySQL user, it worked fine. It had nothing to do with mysql.sock.
[26 Aug 2008 22:01]
Rob Ristroph
I have a "clean" install of RHEL 5. I installed: MySQL-client-community-5.1.26-0.rhel5.i386.rpm MySQL-server-community-5.1.26-0.rhel5.i386.rpm MySQL-shared-community-5.1.26-0.rhel5.i386.rpm The first time I installed it, the server started automatically. When I later rebooted, the server did not start automatically, and now I can't start it: [root@box mysql]# /sbin/service mysql start Starting MySQL.Manager of pid-file quit without updating fi[FAILED] [root@box mysql]# There is another server I maintain, that is a heavily used production server, that had mysql 5.1.26 installed on it -- it is a RHEL 4 server however. The 5.1 was installed and started just once, and then got used in production -- now I am scared that if the box ever reboots MySQL won't come back up (and I'll be fired). Does anyone have any information about to solve or just work around this bug ?
[29 Aug 2008 18:27]
Loren Sorensen
Does anyone have a fix or a work-around for this? Allegedly 5.1.26 is ready for primetime, but I can't put something into production that won't restart along with the system in the usual fashion.
[4 Sep 2008 13:03]
tiong heng ong
Dell 2950 with RHEL5.2 Sad to say, I also encountered this problem. IMHO [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid it is the PID path that caused the issue. For my case DIRECTORY /var/run/mysqld/ is missing
[10 Sep 2008 15:37]
Georgi Kodinov
Still present with the 5.1.28-rc generic 64 bit RPMs. Did some investigation to find out that /etc/rc,d/init.d/mysql restart doesn't work. However if you do '/etc/rc.d/init.d/mysql stop' and '/etc/rc.d/init.d/mysql start' this will work.
[16 Oct 2008 8:05]
Jay Paroline
Ran into this recently on 5.0.66a after running mysqld restart. When trying to start, I got this message: Starting MySQL.............Manager of pid-file quit without[FAILED]g file. Finally fixed it by running: touch /var/run/mysqld.pid after noticing that the pid was missing.
[24 Oct 2008 13:58]
Elena Stepanova
Experienced the problem while smoke-testing 5.1.29-rc (generic RPM). In my case the reason was as follows (quoting SE troubleshooter): SELinux is preventing mysqld (mysqld_t) "append" to /var/lib/mysql/localhost.localdomain.err (var_lib_t). The SELinux type var_lib_t, is a generic type for all files in the directory and very few processes (SELinux Domains) are allowed to write to this SELinux type. This type of denial usual indicates a mislabeled file. By default a file created in a directory has the gets the context of the parent directory, but SELinux policy has rules about the creation of directories, that say if a process running in one SELinux Domain (D1) creates a file in a directory with a particular SELinux File Context (F1) the file gets a different File Context (F2). The policy usually allows the SELinux Domain (D1) the ability to write, unlink, and append on (F2). But if for some reason a file (/var/lib/mysql/localhost.localdomain.err) was created with the wrong context, this domain will be denied. The usual solution to this problem is to reset the file context on the target file, restorecon -v '/var/lib/mysql/localhost.localdomain.err'. (end of quote) It complained about some other files as well, e.g. plugin.*. Fixed it by executing restorecon recursively upon /var/lib/mysql folder. Below is the console output starting from checking that no pieces of MySQL left in the system and up to starting the server successfully. Standard startup output and restorecon output are contracted. [root@localhost root]# uname -a Linux localhost.localdomain 2.6.26.5-45.fc9.i686 #1 SMP Sat Sep 20 03:45:00 EDT 2008 i686 i686 i386 GNU/Linux [root@localhost root]# ls -l /var/lib/mysql ls: cannot access /var/lib/mysql: No such file or directory [root@localhost root]# ls -l /var/lock/subsys/mysql ls: cannot access /var/lock/subsys/mysql: No such file or directory [root@localhost root]# rpm -qa | grep MySQL [root@localhost root]# rpm -i MySQL-server-5.1.29-0.glibc23.i386.rpm PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! <....> The latest information about MySQL is available at http://www.mysql.com/ Support MySQL by buying support/licenses from http://shop.mysql.com/ Starting MySQL...Manager of pid-file quit without updating file.[FAILED] [root@localhost root]# /etc/init.d/mysql start Starting MySQL...Manager of pid-file quit without updating [FAILED] [root@localhost root]# restorecon -v -R /var/lib/mysql/ restorecon reset /var/lib/mysql context unconfined_u:object_r:var_lib_t:s0->system_u:object_r:mysqld_db_t:s0 restorecon reset /var/lib/mysql/localhost.localdomain.err context unconfined_u:object_r:var_lib_t:s0->system_u:object_r:mysqld_db_t:s0 <...> restorecon reset /var/lib/mysql/mysql/help_relation.MYI context unconfined_u:object_r:var_lib_t:s0->system_u:object_r:mysqld_db_t:s0 restorecon reset /var/lib/mysql/test context unconfined_u:object_r:var_lib_t:s0->system_u:object_r:mysqld_db_t:s0 [root@localhost root]# /etc/init.d/mysql start Starting MySQL. [ OK ]
[5 Nov 2008 23:29]
Timothy Smith
Nearly every report on this bug has described a different symptom. If someone has a clear demonstration of what does not work, and it's an error in the way the RPM is working, please open a new explicit bug report. Sorry, otherwise I can not make sense of this bug.
[6 Nov 2008 15:13]
Loren Sorensen
This mystery was unraveled for me, at least, (see my frustrated post, above) by my esteemed colleague in Germany, Geoff Galitz, starting with a clue found elsewhere on the net (attribution lost, unfortunately) and a hunch. From Geoff: Installations of MySQL on a high security system (typically with SELinux set to enforcing mode) may prevent MySQL from interacting with OS layer files such as the pid files (needed to track running instances). To fix it, first determine if this is the case: [root@france ~]# sestatus |grep -i mode Current mode: enforcing Mode from config file: enforcing [root@france ~]# getsebool -a | grep -i mysq allow_user_mysql_connect --> off mysqld_disable_trans --> off If your case resmebles what you see here, you can do this: [root@france ~]# togglesebool allow_user_mysql_connect allow_user_mysql_connect: active [root@france ~]# togglesebool mysqld_disable_trans mysqld_disable_trans: active
[6 Nov 2008 16:06]
Loren Sorensen
Oh, and one more thing... You will need this, as well, to make the change permanent. setsebool -P mysqld_disable_trans=1 ntpd_disable_trans=1
[10 Nov 2008 18:35]
Andrew Martin
RHEL 5 64 upgrading 5.0.45 -> 5.1.29 (non production server!) Moved old /var/lib/mysql to /var/lib/mysql.old as the data was not required. Removed previous installation. [root@191624 src]# rpm -e mysql-server-5.0.45-7.el5.x86_64 warning: /var/log/mysqld.log saved as /var/log/mysqld.log.rpmsave [root@191624 src]# rpm -Uvf MySQL-server-community-5.1.29-0.rhel5.x86_64.rpm Preparing packages for installation... MySQL-server-community-5.1.29-0.rhel5 <cut> Starting MySQL.. ERROR! Manager of pid-file quit without updating file. Giving mysqld 2 seconds to start And no response. However: [root@191624 src]# ps auxw | grep mysql root 24116 0.0 0.0 65884 1284 ? S 17:37 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid mysql 24170 0.0 0.8 290892 35012 ? Sl 17:37 0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --socket=/var/lib/mysql/mysql.sock root 25239 0.0 0.0 61108 728 pts/0 S+ 18:03 0:00 grep mysql Running processes. So: [root@191624 lib]# killall mysqld [root@191624 lib]# /etc/init.d/mysql start Starting MySQL. SUCCESS! HTH somebody searching this bug tracker for answers (and the most excellent dev team).
[12 Mar 2009 4:33]
Patrick S
Hi, I was pulling my hair out with the same symptoms as described here and the SELinux suggestions did not cure it for me. What I did find to be causing the issue was that I had this in my my.cnf: max_allowed_packet = 3.125M Apparently you can not have decimal values there. Maybe this is documented somewhere, I wasn't aware. Setting it to 3M fixed the issue. I had set it this way as the bugzilla 3.2.2 checksetup.pl script gave a warning: WARNING: You need to set the max_allowed_packet parameter in your MySQL configuration to at least 3276750. Currently it is set to 1048576. You can set this parameter in the [mysqld] section of your MySQL configuration file. Those values are in bytes, the first is the default my.cnf value of 1M, the second translates to 3.125M so that is what I was trying. btw, I've confirmed this to be true using MySQL community 5.1.31-0.rhel4 on RHEL4.6_64 and MySQL community 5.1.32-0.rhel4 on RHEL4.4_32. Hope this helps someone.
[28 Jun 2009 2:13]
Kirk Brown
I just had this exact issue on FC9 using the MySQL-server-5.1.35-0.glibc23.x86_64.rpm. '/bin/sh /etc/init.d/mysql start' worked (I was the root user already), otherwise I got: Starting MySQL..Manager of pid-file quit without updating file.[FAILED] Clean install, no /var/lib/mysql directory at all. The logfile showed the following error: 090628 04:02:17 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 090628 04:02:18 mysqld_safe mysqld from pid file /var/lib/mysql/bugs-b.mysql.com.pid ended
[8 Jul 2009 10:59]
Gordon Mackay
I hope this isn't unrelated. As far as I can see, the "Starting MySQL.Manager of pid-file quit without updating file.[FAILED]" seems to be caused by several things and is a bit misleading. My initial install worked, but stopped workking when I tried to change some settings in my.cnf The errors I had to fix, in the my.cnf file to enable me to cleanly start/stop mysql were to make sure all referenced directories existed and had chown mysql.msql xx/xx/xx set on them AND, I had to remove properies that were no longer user/needed/understood in this version. It seems that MySQL doesn't simply ignore them. For instance, the setting innodb_log_arch_dir = /usr/local/mysql/data/ which was copied from a previous my.cnf file, was causing the error too. Might be of use to someone :)
[31 Jul 2009 16:38]
Paul Canavan
If you made it this far then this may help..... My problem was also unrelated to the error message from the init script but a setting in the my.cnf file. I ran mysqld_safe from the command line and it told me where it was logging errors to (/var/lib/mysql/<hostname>.err), waited for the process to fail, then checked the errors file. This pointed me to an issue in the my.cnf file (attempting to allocate too much memory).
[12 May 2010 9:46]
Joerg Bruehe
Let me try to summarize this a bit.
It seems that several different problems all lead to the same symptom, the error message
Starting MySQL..Manager of pid-file quit without updating file.[Failure]
Grouping the various entries, I can identify two areas:
1) The startup script is not executed by the proper shell.
This seems to be the root cause for the original report
(see the entries of June 4 and 5, 2008; June 28, 2008.
2) SElinux does prevent some actions.
(October 24 and November 6, 2008)
I don't yet have an opinion about the entries dated
- August 13, 2008 (was that a RPM installation at all?)
- August 27, 2008 (let's hope it is one of the categories above)
- September 4, 2008 (will need to check about "/var/run/mysqld"),
- September 10, 2008 (insufficient information,
I will deal with that when "start" is solved),
- November 10, 2008 (worked from shell)
Totally unrelated to such startup problems I consider the entries of
- June 13 and 16, 2008 (cluster is not contained in 5.1),
- July 4, 2008 (privileges should be handled by RPM on install/upgrade),
- March 12 and July 8 + 31, 2009 (config file)
Now, about solutions:
Re 1) The script starts with a proper "she-bang" since ages:
#!/bin/sh
So it seems RedHat's "sudo" does not honor that line,
but an explicit "sudo /bin/sh ..." helps.
I will try asking Google about that.
Re 2) There may be cases where the platform sets up SElinux
with a configuration which does not fit the server and its tools.
Other than try with all versions of all platforms in a default
setup without any local modifications, there is little we can do.
I am tempted to use Loren's hints of November 6, 2008,
but I don't have an environment available in which I could verify that.
[19 Aug 2011 18:19]
Joerg Bruehe
Patch is approved via chat, pushed into the sources of 5.1.60. This patch handles only item 2) in my classification of May 12, 2010. That problem is specific to 5.1 (the 5.5 spec file already deals with that), the upmerge to 5.5 and 5.6 is done but is (in fuction) a null-merge. If other aspects of that installation problem show up again, please let us have separate bugs for them.
[29 Aug 2011 17:11]
Paul DuBois
Noted in 5.1.60 changelog. On Fedora, certain accesses to /var/lib/mysql/HOSTNAME.err were blocked by SELinux policy, which made the server fail at startup with the message: Manager of pid-file quit without updating file
