Bug 185955
| Summary: | mysql new socket location causes init script to report FAILED start-up | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Hans Kramer <hans.kramer> |
| Component: | mysql | Assignee: | Tom Lane <tgl> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | David Lawrence <dkl> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4 | CC: | byte, hhorak |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-03-10 04:14:41 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Seems like the issue here is whether the socket option is in the right section of /etc/my.cnf. It's in [mysqld] at the moment so it's not that surprising if only mysqld pays attention. I wonder if there is another section name we should put it under? This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks. Fedora Core 4 is no longer maintained. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release, please reopen this bug and assign it to the corresponding Fedora version. |
Description of problem: After change of socket location in /etc/my.conf the init script /etc/init.d/mysqld is unable to establish whether the mysql server has started Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. edit /etc/mysql and change socket option 2. restart mysqld : service mysqld restart 3. Actual results: mysql is started however the init reported FAILED after a 30 seconds timeout Expected results: report OK Additional info: Straightforward work around in init script: specify --socket in mysqladmin call in start() function. I have "hacked" this in the following way: 75 # Spin for a maximum of N seconds waiting for the server to come up. 76 # Rather than assuming we know a valid username, accept an "access 77 # denied" response as meaning the server is functioning. >>> 78 eval $(grep ^socket /etc/my.cnf) 79 if [ $ret -eq 0 ]; then 80 STARTTIMEOUT=30 81 while [ $STARTTIMEOUT -gt 0 ]; do >>> 82 RESPONSE=`/usr/bin/mysqladmin -uUNKNOWN_MYSQL_USER --socket=$socket ping 2>&1` && brea k 83 echo "$RESPONSE" | grep -q "Access denied for user" && break 84 sleep 1 85 let STARTTIMEOUT=${STARTTIMEOUT}-1 86 done 87 if [ $STARTTIMEOUT -eq 0 ]; then 88 echo "Timeout error occurred trying to start MySQL Daemon." 89 action $"Starting $prog: " /bin/false 90 else 91 action $"Starting $prog: " /bin/true 92 fi 93 else 94 action $"Starting $prog: " /bin/false 95 fi A better solution would be if mysql would read in the /etc/my.conf file like /usr/bin/mysqld_safe does!!!! Couldn't find that option for mysqladmin though... grrrrr mysql....