MySQL Bugs: #29595: error in service mysql restart

Bug #29595	error in service mysql restart
Submitted:	6 Jul 2007 10:52	Modified:	5 Jul 2010 15:01
Reporter:	Thinakaran Chelliah	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	5.0.41, 5.0.45	OS:	Linux (suse 10)
Assigned to:	Georgi Kodinov	CPU Architecture:	Any

Description:
while starting mysql service i got this error message.
#service mysql restart
MySQL manager or server PID file could not be found!                  failed
Starting MySQL/etc/init.d/mysql: line 159: kill: (6198) - No such process
                                                                      failed

How to repeat:
service mysql restart
MySQL manager or server PID file could not be found!                  failed
Starting MySQL/etc/init.d/mysql: line 159: kill: (6198) - No such process
                                                                      failed

Thank you for the report.

Please described step-by-step your actions for performing MySQL server installation. I mean: which package (file name) you downloaded and evry you action you did after download.

Same problem on CentOS. Here is more information.

# uname -a
Linux testserver.theplanet.host 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686 i686 i386 GNU/Linux

# rpm -qa | grep -i MySQL
MySQL-shared-compat-5.0.41-0
MySQL-devel-5.0.41-0
MySQL-server-5.0.41-0
MySQL-client-5.0.41-0

# cat /etc/my.cnf
[mysqld]
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=0
socket=/var/lib/mysql/mysql.sock
pid_file=/var/lib/mysql/mysql.pid
datadir=/var/lib/mysql
log-error=/var/lib/mysql/mysqld.err

# INNODB specific settings
# set the innodb_buffer_pool_size
innodb_buffer_pool_size =128M
innodb_additional_mem_pool_size = 16M
innodb_flush_method = O_DIRECT

# Enable binary logs.
#log-bin=/var/log/mysql_preintdb
#log-bin=0
innodb_file_per_table
#innodb_force_recovery = 1

# If the binary log exceeds 100M, rotate the logs
innodb_data_file_path=innodbdata:100M:autoextend

innodb_file_io_threads = 4
innodb_thread_concurrency = 4
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 8M
innodb_log_file_size = 32M
innodb_log_files_in_group = 6
innodb_max_dirty_pages_pct = 90
#innodb_flush_method=O_DSYNC
innodb_lock_wait_timeout = 120

# utf-8 changes
init_connect='SET collation_connection = utf8_general_ci'
init_connect='SET NAMES utf8'
default-character-set=utf8
character-set-server = utf8
collation-server = utf8_general_ci

     
[mysql.server]
user=mysql
#basedir=/var/lib

[mysqld_safe]
err-log=/var/lib/mysql/mysqld.log
pid-file=/var/lib/mysql/mysqld.pid

[safe_mysqld]
err-log=/var/lib/mysql/mysqld.log
pid-file=/var/lib/mysql/mysqld.pid 

# /etc/rc.d/init.d/mysql start
Starting MySQL../etc/rc.d/init.d/mysql: line 159: kill: (28196) - No such process
[FAILED]

# cat /var/lib/mysql/mysqld.err 
070708 00:30:19  mysqld started
070708 00:31:19  mysqld ended

070708 00:33:31  mysqld started
070708 00:33:40  mysqld ended

070708 00:48:41  mysqld started
070708 00:48:44  mysqld ended

Please, send also te results of:

uname -a
getconf GNU_LIBPTHREAD_VERSION

from your system. What exact binary you had used? Sveta already asked about that, but there is no answer.

i get a similar error for 5.0.42 on mandriva linux.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Installed the following on RHEL5 server:
MySQL-server-community-5.0.45-0.rhel5.i386.rpm
MySQL-client-community-5.0.45-0.rhel5.i386.rpm

When attempting to start MySQL the following error is generated:
Starting MySQL/etc/init.d/mysql: line 159: kill: (2855) - No such process
[FAILED]

uname -a:
2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 i686 athlon i386 GNU/Linux

getconf GNU_LIBPTHREAD_VERSION:
NPTL 2.5

Same problem on MacOS X

# uname -a
Darwin ibm-23264ec0ffa 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386

I installed the mysql-5.0.45-osx10.4-i686.dmg package.

I cannot restart the server, but the automatic start at boot works.

Thanks

Please, try to repeat with a newer version, 5.0.51a, and inform about the results.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I am having the same issue as well.

Starting MySQL/etc/init.d/mysql: line 159: kill: (24684) - No such process

I am using the below:
Linux server1 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux

MySQL-server-community-maria-5.1.23a-0.rhel4

Any ideas how to resolved it?

Steven,

thank you for the feedback. Which shell do you use? (`echo $SHELL` will show it)

I am using bash shell.

I have disable the SELinux and able to start with mysql start.

However it is with /etc/my.conf only.
If I change it to my.cnf, it will failed. The file /etc/my.cnf must not
exist.

I then tried to use the MySQL Administrator GUI to see the startup
parameter.
Some of the parameter is still grey off.
All basedir, datadir, tempdir, default storage engine and etc is
specify in the my.conf however they are grey off. Other parameters are
able to modify.

I wonder why mysql start my.cnf with error whereis my.conf is fine.
Also some my.conf parameter is grey off in MySQL Administrator GUI no
doubt the value is specify in the my.conf file.

Kindly advice.

All reporters,

how did you install MySQL? Did you download the packages from our webside and install them or did you just use the packages from your operating system?

Bug #29727 is a duplicate of this bug here.

same problem with line 159

downloaded the binary version (mysql-5.0.51a-linux-i686.tar.gz) from the mysql website. running on fresh RHEL4 installation ( 2.6.9-67.0.4.ELsmp NPTL 2.3.4 )

thanks

Verified as described.

I'm experiencing this bug also, with MySQL-server-community-5.1.23-0.rhel5.i386.rpm on RHEL 5.1. At first I get this:

Starting MySQLCouldn't find MySQL manager (/var/lib/bin/mysqlmanager) or server (/var/lib/bin/mysqld_safe)

I googled around and found a suggestion to comment out the basedir in /etc/my.cnf so I tried that and now I get:

Starting MySQL/etc/init.d/mysql: line 159: kill: (2874) - No such process

Also confirmed using mysql-5.0.51a-solaris10-i386 on Solaris 10 Update 4 (presume the same on SPARC).

Using the Bash shell and installed MySQL as a Solaris package.

Running /bin/sh -x /opt/mysql/mysql/support-files/mysql.server start yields this:

<output>
+ test -r /opt/mysql/mysql/my.cnf 
+ test -r /var/lib/mysql/my.cnf 
+ ./bin/my_print_defaults mysqld server mysql_server mysql.server 
+ parse_server_arguments --port=3306 --socket=/tmp/mysql.sock --set-variable=key_buffer_size=16M --set-variable=max_allowed_packet=10M --basedir=/opt/mysql/mysql --pid-file=/opt/mysql/mysql/data/yellowjacket.pid --skip-locking --key_buffer=16M --max_allowed_packet=10M --table_cache=64 --sort_buffer_size=512K --net_buffer_length=8K --myisam_sort_buffer_size=8M 
+ sed -e s/^[^=]*=// 
+ echo --basedir=/opt/mysql/mysql 
basedir=/opt/mysql/mysql
bindir=/opt/mysql/mysql/bin
+ test -z  
datadir=/opt/mysql/mysql/data
sbindir=/opt/mysql/mysql/sbin
libexecdir=/opt/mysql/mysql/libexec
+ sed -e s/^[^=]*=// 
+ echo --pid-file=/opt/mysql/mysql/data/yellowjacket.pid 
server_pid_file=/opt/mysql/mysql/data/yellowjacket.pid
+ ./bin/my_print_defaults manager 
+ parse_manager_arguments 
+ test -z  
+ /usr/bin/hostname 
pid_file=/opt/mysql/mysql/data/mysqlmanager-yellowjacket.pid
+ test -z /opt/mysql/mysql/data/yellowjacket.pid 
+ cd /opt/mysql/mysql 
manager=/opt/mysql/mysql/bin/mysqlmanager
+ test -x /opt/mysql/mysql/libexec/mysqlmanager 
+ test -x /opt/mysql/mysql/sbin/mysqlmanager 
+ echo Starting MySQL 
Starting MySQL
+ test -x /opt/mysql/mysql/bin/mysqlmanager -a 1 = 0 
+ test -x /opt/mysql/mysql/bin/mysqld_safe 
pid_file=/opt/mysql/mysql/data/yellowjacket.pid
+ wait_for_pid created 13219 
i=0
+ test 0 -ne 900 
+ sleep 1 
+ /opt/mysql/mysql/bin/mysqld_safe --datadir=/opt/mysql/mysql/data --pid-file=/opt/mysql/mysql/data/yellowjacket.pid 
+ test -s /opt/mysql/mysql/data/yellowjacket.pid 
+ kill -0 13219 
/opt/mysql/mysql/support-files/mysql.server: kill: no such process
+ break 
+ test -z 0 
+ log_failure_msg 
+ echo  ERROR!  
 ERROR! 
+ return 1 
return_value=1
+ test -w /var/lock/subsys 
+ exit 1 
</output>

The fix was to rename /etc/my.cnf to something else (/etc/my.dist for example) and then restart MySQL successfully.

Placing the same my.cnf file in /opt/mysql/mysql also allows the server to function as one would expect.

According to the docs below /etc/my.cnf is still a valid location for the my.cnf file:

http://dev.mysql.com/doc/refman/5.0/en/option-files.html

After getting MySQL to start successfully the first time via the work around above I was able to move my.cnf back to /etc and restart MySQL with no problems

I have the same problem with RedHat 4 Enterprise update 5.

I have installed the next rpm packages 

MySQL-devel-community-5.0.51a-0.rhel4.i386.rpm
MySQL-client-community-5.0.51a-0.rhel4.i386.rpm
MySQL-shared-compat-5.0.51a-0.rhel4.i386.rpm
MySQL-server-community-5.0.51a-0.rhel4.i386.rpm

The server start OK with the default datadir, but when I create the file my.conf the server don't start.

The content of /etc/my.cnf file is

[mysqld]
datadir=/datos/trac

I had this issue on a RHEL3/Plesk 7.5 upgrade from Mysql4.1.22-0 to the latest Mysql-5.1.51a

MySQL-client-community-5.0.51a-0.rhel3.i386.rpm
MySQL-devel-community-5.0.51a-0.rhel3.i386.rpm
MySQL-server-community-5.0.51a-0.rhel3.i386.rpm
MySQL-shared-community-5.0.51a-0.rhel3.i386.rpm

The RPM packages were download mysql.com. (The 4.1.22 packages were from mysql.com about a year ago.) The procedure used was:

service mysql stop
rpm -Uhv Mysql-*
service mysql start

The server did not start originally because of Bug #23524. This was corrected by editing the my.cnf.

Then the "Starting MySQL/etc/init.d/mysql: line 159: kill: (764) - No such process" error was caused because somehow the mysql user was removed. The /var/lib/mysql directory was owned by user 111:111. I recreated the mysql user and all appears to be well.

Hope this helps.

Hi,

I have same issue as Alurndra Perez

My Linux is RHEL 5, selinux = disabled
This is what is installed:
MySQL-devel-community-5.0.51a-0.rhel5
MySQL-client-community-5.0.51a-0.rhel5
MySQL-shared-compat-5.0.51a-0.rhel5
MySQL-server-community-5.0.51a-0.rhel5

Kernel: Linux sqldata 2.6.18-53.1.19.el5 #1 SMP Tue Apr 22 03:01:13 EDT 2008 i686 i686 i386 GNU/Linux

By default install service mysql start works perfect.
When i use /etc/my.cnf mysql fails to start with this error:
 service mysql start
Starting MySQL/etc/init.d/mysql: line 159: kill: (8058) - No such process
                                                           [FAILED]
This is what /etc/my.cnf contains:
my_print_defaults --defaults-file=/etc/my.cnf client mysqld
--datadir=/sql/mysql/data

I really need to move the datadir to a new location as our databases is too big for the default location.

Can anyone assist please?

it was a permission problem on hosts.frm file in mysql directory .. 

it works now ..

thanks anyway.

I had this problem on my source installation (debian distro), and a customized datadir.

How i made i work :

- created a /etc/mysql/conf.d dir (empty)
- copied my.cnf from sources to /etc/
- edited my.cnf to modify datadir and language files path, then commented basedir
- created /var/log/mysql dir (+chmodded to the mysql user)
- executed /usr/local/bin/mysql_intall_db

Hope this helps.

Hi everyone,

I have had the same problem with upgrading RHEL5.1 from MySQL 5.0.22 to 5.0.51a. The problem occurs as the my.cnf gets (over)written which specifies /var/lib as the basedir. Then /etc/init.d/mysql uses /var/lib/bin instead of /usr/bin as the location of mysqld_safe. If you change the following line:

...
[mysql.server]
...
basedir=/var/lib

to :

basedir=/usr

it then worked fine. Now the documentation on basedir seems to suggest that this has something to do with the data file locations, but since they are specified further up the my.cnf (see datadir in my.cnf) this is not the case.

Paul.

In my preceeding comment I stated that:

"The problem occurs as the my.cnf gets (over)written which specifies /var/lib as the basedir."

This is not correct. What actually happened was this:

1) MySQL 5.0.22 wrote the my.cnf file to /etc
2) in the /etc/init.d/mysqld of 5.0.22 the executable directory is hardcoded (not taken out of my.cnf) so it does not fail due to the incorrect basedir of /var/lib
3) The MySQL 5.0.51a rpm does not write or overwrite my.cnf (several examples are provided and it is up to you do decide which to use if any). The rpm process does not delete your existing my.cnf
4) The 5.0.51a /etc/init.d/mysql uses basedir of my.cnf with /bin appended to get the bin directory. As the my.cnf is still the default shipped with 5.0.22, this singularly fails due to it having the wrong path.

To fix, provide a valid my.cnf (minimally the default with the correct path).

In some ways this failure was good. I didn't know that we were using the default my.cnf. Now I know, I can actually provide a my.cnf optimised to our needs.

Anyway, I hope this ramble helps.

Paul.

Solved this error by doing 

chown -R mysql /yourdatabasedir
chgrp -R mysql /yourdatabasedir

chown -R mysql /var/lib/mysql
chgrp -R mysql /var/lib/mysql

and commenting out 

[mysql.server]
#basedir=/var/lib

in /etc/my.cnf

I am having the same problem.  It looks like SELinux is causing the problem.

# uname -a
Linux myhost 2.6.18-92.1.1.el5 #1 SMP Thu May 22 09:01:47 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

# rpm -i MySQL-server-community-5.0.51a-0.rhel5.x86_64.rpm
# rpm -i MySQL-client-community-5.0.51a-0.rhel5.x86_64.rpm

After installing a fresh database, I get:
# /etc/init.d/mysql start
Starting MySQL/etc/init.d/mysql: line 159: kill: (11882) - No such process

# tail /var/log/messages

Jul  5 01:13:45 myhost setroubleshoot: SELinux is preventing mysqld (mysqld_t) "read write" to ./ibdata1 (var_lib_t). For complete SELinux messages. run sealert -l 336657f9-93f9-48dd-b8bc-12a34330d478
Jul  5 01:13:58 myhost setroubleshoot: SELinux is preventing mysqld (mysqld_t) "append" to /var/lib/mysql/myhost.err (var_lib_t). For complete SELinux messages. run sealert -l 04ac7190-45a2-400e-9c7a-e9bca9656f93
Jul  5 01:13:58 myhost setroubleshoot: SELinux is preventing mysqld (mysqld_t) "append" to ./myhost-slow.log (var_lib_t). For complete SELinux messages. run sealert -l b986ae17-a6c4-4662-9636-71409cd3f105
Jul  5 01:13:58 myhost setroubleshoot: SELinux is preventing mysqld (mysqld_t) "read write" to ./mysql-bin.index (var_lib_t). For complete SELinux messages. run sealert -l fe077f59-cee5-4925-8c48-5796769ab2e8
Jul  5 01:17:18 myhost setroubleshoot: SELinux is preventing mysqld (mysqld_t) "append" to /var/lib/mysql/myhost.err (var_lib_t). For complete SELinux messages. run sealert -l 04ac7190-45a2-400e-9c7a-e9bca9656f93
Jul  5 01:17:18 myhost setroubleshoot: SELinux is preventing mysqld (mysqld_t) "read write" to ./mysql-bin.index (var_lib_t). For complete SELinux messages. run sealert -l fe077f59-cee5-4925-8c48-5796769ab2e8
Jul  5 01:17:18 myhost setroubleshoot: SELinux is preventing mysqld (mysqld_t) "append" to ./myhost.log (var_lib_t). For complete SELinux messages. run sealert -l b986ae17-a6c4-4662-9636-71409cd3f105
Jul  5 01:18:53 myhost setroubleshoot: SELinux is preventing mysqld (mysqld_t) "append" to /var/lib/mysql/myhost.err (var_lib_t). For complete SELinux messages. run sealert -l 04ac7190-45a2-400e-9c7a-e9bca9656f93
Jul  5 01:18:53 myhost setroubleshoot: SELinux is preventing mysqld (mysqld_t) "read write" to ./mysql-bin.index (var_lib_t). For complete SELinux messages. run sealert -l fe077f59-cee5-4925-8c48-5796769ab2e8
Jul  5 01:18:53 myhost setroubleshoot: SELinux is preventing mysqld (mysqld_t) "append" to ./myhost-slow.log (var_lib_t). For complete SELinux messages. run sealert -l b986ae17-a6c4-4662-9636-71409cd3f105

Had the same problem on a Debian 4 with a source distribution. Found that the problem was mysqld_safe didn't start due to a garbled line in my.cnf. After fixing that line everything was ok.

I can't repeat this anymore with actual 5.1 bzr tree.

But it seems that my.cnf search priority didn't change.

So I will let this in verify status as feature request or minor help text error.

./libexec/mysqld --verbose --help | less
...
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /home/miracee/mysql51bzr/etc/my.cnf ~/.my.cnf
...

This order made lots of problems.

Order should be vise versa: first look in user home, then in installion path, then in /etc

My test from today seems that just the help text still is wrong.

Let me explain what happened in the past:
By accident you have had a my.cnf in /etc or /etc/mysql with a given basedir. Unfortunately some linux software is installing/configure it by automatism. Openoffice and KDE are candidates for it. Ugly is these installation overwrite already existing my.cnf.

But you installed mysql with own my.cnf and other datadir.
You could start mysqld --defaults-file=... It has had non effect. As long as there was a my.cnf with basedir in /etc or /etc/mysql all others got ignored.

I just tested it again and created a my.cnf in /etc/mysql with given basedir and used my own my.cnf for starting the deamon. All worked fine.

So it really looks like this has been fixed.

The order in mysql --help still is wrong:

/etc/my.cnf /etc/mysql/my.cnf /home/miracee/mysql51bzr/etc/my.cnf ~/.my.cnf

Just think to bashrc or other configurations ... it first look in home directory and then in /etc.

Suzanne,

The help text is imho correct : the way mysql works with the option files is to : 
1. set all options to their respective compile time default values 
2. Iterate through the config files in the order that is shown in --help and apply all the options in these files to the common list of variables. 

This means that :
1. Mysql will end up using an union of all the unique options across all the config files
2. For options repeating in several files it will take the value from the config file that's applied last. This is why your example works.

So as a result I think that the --help message is correct. Feel free to re-open as a docs bug if you think that the above procedure is not sufficiently documented.