This article presents one of the troubleshooting steps for Zend DBi MySQL daemon start ups, found in this article:
Troubleshoot Zend DBi MySQL daemon start up failures (mysql.sock)
When the Zend DBi MySQL daemon job, ZENDDBID, will not start, the job log will often show something like this:
RNM OBJ('/tmp/mysql.sock') NEWOBJ('mysql.sock')
Object not found. Object is /tmp/mysql.sock.This is how the start up program checks for a successful start. File /tmp/mysql.sock is a socket file created by the MySQL daemon when it starts, and is removed when the daemon stops. The socket file should only exist when the daemon is running. The start up program performs the rename operation, using the same file name so the file will not actually be renamed. If the file is not found, the rename fails, and the start up program knows the daemon is not running.
While the missing socket file can be because of any issue that prevents the Zend DBi MySQL daemon from starting, one of those issues can be that the daemon cannot write the socket file. A related issue is one where the /tmp/mysql.sock already exists at start up, preventing the daemon from writing a new one. In these cases, the “Object not found” message does not appear.
To check for these issues, start by using Navigator, the wrklnk command, a mapped network drive, or the RSE perspective in Zend Studio to look at the /tmp directory to see if the mysql.sock file exists. Then, depending on whether it exists, go to the appropriate section below. My preference is to use Navigator for this task, because Navigator makes it easy to set permissions, if needed.
1. If the /tmp/mysql.sock file does not exist
In the picture above, file mysql.sock does not exist in the /tmp directory (the file list is sorted by name). If the file /tmp/mysql.sock does not exist, then there may be a permissions issue. (Or, some other problem is preventing the start up. Remember, a missing mysql.sock can indicate simply that the daemon did not start.) User MYSQL needs to have permissions to write to this directory. Permissions for the /tmp directory typically look something like this:
Notice that user (Public) has all of the permissions for this folder. Sometimes permissions for (Public) are set to Exclude, as some feel this is more secure. In that case, user MYSQL should be assigned all permissions for this folder:
This will allow the ZendDBi MySQL daemon to create the mysql.sock socket file.
If the permissions were OK but the file mysql.sock does not exist, this is probably not the problem. Please return to the troubleshooter to try another step.
2. If the /tmp/mysql.sock file does exist
In this example, file mysql.sock already exists in the /tmp directory. This is a problem. There are two possible reasons for this. One is that there is some other installation of MySQL on the IBM i that is currently running. The other is that the ZendDBi MySQL daemon had been started previously, but ended abnormally for some reason.
2.a. Some other MySQL daemon process is running
To determine if some other MySQL daemon is running, please sign on to a 5250 session as QSECOFR or a *SECOFR class user, and run this command:
call qp2term
This brings up the PASE shell. In the shell, enter this command:
ps ax
This will list all the active PASE processes. They will typically fill more than one screen. You need to page up to scroll back through them all. Look at them all, searching for any occurrence of the mysqld or mysqld_safe command. Here is an example showing the ZendDBi MySQL daemon running:
11242 - A 0:00 /usr/local/ZendSvr/bin/php-cgi.bin 11243 - A 0:00 /usr/local/ZendSvr/bin/php-cgi.bin 11281 - A 0:00 /usr/local/mysql/bin/mysqld --defaults-file=/usr/local 11284 - A 0:00 /QOpenSys/usr/bin/-sh -i
These are just a few of the lines displayed. Notice process number 11281 is running command /usr/local/mysql/bin/mysqld . This is the mysqld from ZendDBi.
If mysqld is running from /usr/local/mysql, but the ZENDDBID job is not running, it is possible someone ran mysqld directly from inside the PASE shell, rather than letting the job run it. They may have done this for diagnostic purposes. Or, an older version of MySQL distributed by Zend might be running in the ZMYSQL subsystem. It is less likely that some other version of MySQL is running out of this directory, since that would have given some trouble during the install. You can stop the process using the kill command in PASE to end the process by number. In this example the process number is 11281:
kill 11281
Run ps ax again to verify that the process is no longer present. If it is still there, wait a few minutes and check again. If it will not die in a reasonable amount of time, please try this:
kill -9 11281
The ‘-9’ sends the SIGKILL signal, “which usually cannot be ignored or overridden“. It is sort of like killing a job with the ENDJOBABN command.
If you kill the process, you may need to delete the mysql.sock socket file manually (see 2.b. below). This should allow the Zend DBi MySQL daemon to start.
If mysqld or mysqld_safe is running under some other directory (not /usr/local/mysql), there is another version of MySQL on your IBM i that was not distributed by Zend. It would need to be stopped before you can start up ZendDBi. If you got this far and are just now realizing there is another version of MySQL on your system (I’ve seen it happen), then it is time to stop and find out where it came from and whether anybody is using it for anything. You should probably not kill the process until you know more about how it got there.
2.b. No other MySQL daemon process is running
If there were no other mysqld or mysqld_safe processes running when you ran the ps ax command, then the /tmp/mysql.sock file was likely left behind when the daemon ended abnormally. If this is the case, it is safe to delete it. In Navigator, you can right click the file and select Delete from the context menu that appears. You will be prompted to confirm the deletion. This should allow the Zend DBi MySQL daemon to start.