Bug #68247 Changes to mysqld_safe script don't permit logging in datadir
Submitted: 1 Feb 2013 18:42 Modified: 5 Feb 2013 6:22
Reporter: William Rushlow Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Logging Severity:S3 (Non-critical)
Version:5.5.29 OS:Solaris (10 Sparc with ZFS system root)
Assigned to: CPU Architecture:Any
Tags: Community Server, solaris 10, ZFS

[1 Feb 2013 18:42] William Rushlow
Description:
After upgrading to 5.5.29 from 5.5.28 using the pkg, we were unable to start the MySQL server with either /etc/init.d/mysql or mysqld_safe. The MySQL server could not write to /var/lib/mysql for some reason, which made this difficult to troubleshoot. We were only able to start the MySQL server by using the --syslog option. We decided to try the mysqld_safe script from 5.5.28 to see if that made a difference, and MySQL started right up. We did a diff on the mysqld_safe from 5.5.28 and 5.5.29, and noticed several changes between the two dealing with UMASK (not umask), and logging.

# diff mysqld_safe.5.5.29 mysqld_safe
34,55c34
< # MySQL-specific environment variable. First off, it's not really a umask,
< # it's the desired mode. Second, it follows umask(2), not umask(3) in that
< # octal needs to be explicit. Our shell might be a proper sh without printf,
< # multiple-base arithmetic, and binary arithmetic, so this will get ugly.
< # We reject decimal values to keep things at least half-sane.
< umask 007                               # fallback
< UMASK="${UMASK-0640}"
< fmode=`echo "$UMASK" | sed -e 's/[^0246]//g'`
< octalp=`echo "$fmode"|cut -c1`
< fmlen=`echo "$fmode"|wc -c|sed -e 's/ //g'`
< if [ "x$octalp" != "x0" -o "x$UMASK" != "x$fmode" -o "x$fmlen" != "x5" ]
< then
<   fmode=0640
<   echo "UMASK must be a 3-digit mode with an additional leading 0 to indicate octal." >&2
<   echo "The first digit will be corrected to 6, the others may be 0, 2, 4, or 6." >&2
< fi
< fmode=`echo "$fmode"|cut -c3-4`
< fmode="6$fmode"
< if [ "x$UMASK" != "x0$fmode" ]
< then
<   echo "UMASK corrected from $UMASK to 0$fmode ..."
< fi
---
> umask 007
436a416,438
> #
> # Try to find the plugin directory
> #
> 
> # Use user-supplied argument
> if [ -n "${PLUGIN_DIR}" ]; then
>   plugin_dir="${PLUGIN_DIR}"
> else
>   # Try to find plugin dir relative to basedir
>   for dir in lib/mysql/plugin lib/plugin
>   do
>     if [ -d "${MY_BASEDIR_VERSION}/${dir}" ]; then
>       plugin_dir="${MY_BASEDIR_VERSION}/${dir}"
>       break
>     fi
>   done
>   # Give up and use compiled-in default
>   if [ -z "${plugin_dir}" ]; then
>     plugin_dir='/opt/mysql/mysql/lib/plugin'
>   fi
> fi
> plugin_dir="${plugin_dir}${PLUGIN_VARIANT}"
> 
497,521d498
< 
< #
< # Try to find the plugin directory
< #
< 
< # Use user-supplied argument
< if [ -n "${PLUGIN_DIR}" ]; then
<   plugin_dir="${PLUGIN_DIR}"
< else
<   # Try to find plugin dir relative to basedir
<   for dir in lib/mysql/plugin lib/plugin
<   do
<     if [ -d "${MY_BASEDIR_VERSION}/${dir}" ]; then
<       plugin_dir="${MY_BASEDIR_VERSION}/${dir}"
<       break
<     fi
<   done
<   # Give up and use compiled-in default
<   if [ -z "${plugin_dir}" ]; then
<     plugin_dir='/opt/mysql/mysql/lib/plugin'
<   fi
< fi
< plugin_dir="${plugin_dir}${PLUGIN_VARIANT}"
< 
< 
571,576d547
< 
<   if [ ! -e "$err_log" ]; then                  # if error log already exists,
<     touch "$err_log"                            # we just append. otherwise,
<     chmod "$fmode" "$err_log"                   # fix the permissions here!
<   fi
< 
788,793d758
<   if [ $want_syslog -eq 0 -a ! -e "$err_log" ]; then
<     touch "$err_log"                    # hypothetical: log was renamed but not
<     chown $user "$err_log"              # flushed yet. we'd recreate it with
<     chmod "$fmode" "$err_log"           # wrong owner next time we log, so set
<   fi                                    # it up correctly while we can!
< 

How to repeat:
The only known information is the differences in mysqld_safe from 5.5.29 and 5.5.28
[1 Feb 2013 20:04] Shane Bester
Thanks for the report - it looks like a duplicate of http://bugs.mysql.com/bug.php?id=67976
[1 Feb 2013 21:26] William Rushlow
It's almost the same issue. I was doing everything in bash already, so that was not the fix. Once I used the msqld_safe script from 5.5.28, it worked fine.
[2 Feb 2013 8:00] Erlend Dahl
I am attaching the latest version of mysqld_safe from the head of the 5.5 branch. 

Could you please give that a try and see if it solves your problem?
[2 Feb 2013 8:01] Erlend Dahl
mysqld_safe from 5.5 branch

Attachment: mysqld_safe (application/octet-stream, text), 24.14 KiB.

[4 Feb 2013 15:35] William Rushlow
Yes, that worked nicely. Thanks very much!
[5 Feb 2013 6:22] Erlend Dahl
Thanks for trying out! 

5.5.30 will be out shortly and it will contain the changes in mysqld_safe. 

This bug is then a duplicate, as Shane stated.
[5 Feb 2013 9:49] Erlend Dahl
5.5.30 has just been released, see http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-30.html