Arch Linux

http://repos.archlinux.org/viewvc.cgi/mysql/repos/extra-i686/mysqld?r1=23595&r2=25098
Version that works vs version that doesn't (the latest one doesn't work).
Other users are experiencing the same problem as reported on the forums: http://bbs.archlinux.org/post.php?tid=63694

I'm having trouble with this version too, yet 5.0.75-1 works fine. The problem I'm having is the init script fails on boot. After the system is up I can successfully start mysql according to the /etc/rc.d script yet I am unable to log in. Once I install the older version I have no problem logging in.

Did this get testing before we pushed it out there? Breaking daemon scripts is never a good thing, especially for server services...

Hi Dan,

Yes, it was tested - just running /etc/rc.d/mysqld start and stop. I did not tested with a reboot.

Anyway, with the new pidof tests, i was not using the hostname.pid file on startup.

Another thing, mysql WAS starting. Just reboot you system, you will see that it FAIL, but when you do "mysql" in the prompt it works.

Anyway, i just uploaded a new mysql package that hopefully fixes this problems.

Thanks

Hi,
it still shows that Mysqld fails on boot. The but ps -aux shows it is running.

$sudo pacman -Q mysql
mysql 5.0.75-3

$ ps -aux | grep mysql
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
root 2157 0.0 0.2 2824 1328 ? S 14:16 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql
mysql 2199 0.0 3.7 126892 19496 ? Sl 14:16 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/production-arch.pid --skip-external-locking --port=3306 --socket=/tmp/mysql.sock

Any ideas?
Bertil B

I'm just wondering. What was the objective behind the daemon script changes?
Anyways here's a daemon script that kind of incorporates some of the changes
and works for me.

After the latest update (5.0.75-3), mysql starts up successfully sometimes, but not others. I haven't identified any pattern to when it works and when it doesn't.

When system doesn't shut down properly, a [hostname].pid file is left in /var/lib/mysql that prevents mysql from starting again, until removed. See forum thread: http://bbs.archlinux.org/viewtopic.php?pid=510960#p510960

Mr. Douglas Soares de Andrade please revert your latest changes [1] on the mysqld
script. This is the same reason it broke last time. Please stop breaking it!

My previously posted daemon script from Thursday, 29 January 2009 should work fine.

Thanks.

[1] http://repos.archlinux.org/viewvc.cgi/mysql/repos/extra-i686/mysqld?r1=25814&r2=27681

Hi Loui,

Thanks for the kindness with this bug report. In fact, i really like to break mysql because i recommend SQL Server, so nothing better for make the users switch to Microsoft than break mysql...

Stop joking, i tested this latest version and is was starting MYSQL here, did you change your hostname ? Did you had some problem that your hostname changed ?

Just for your knowledge, this was the problem that is trigguering this one here:

http://bugs.archlinux.org/task/12798?string=mysql&project=1&search_name=&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

So, i was just trying to solve this problem and im reverting to the latest state until a new solution appers.

Thanks and dont take me serious, i just dont thing that you needed to use such words in a ticket, just point the problem and i will fix it asap.

Thanks for that explanation. Please put that in the commit message next time.

removing <hostname>.pid from /var/lib/mysql doesn't resolve this issue with the initscript using mysql 5.0.77-2

this is basically the output from the initscript:

:: Starting MySQL + printf '\033[s'
+ deltext
+ printf '\033[107G'
+ printf ' \033[1;34;40m[\033[0;36;40mBUSY\033[1;34;40m]\033[1;0m '
[BUSY] ++ getPID
++ '[' -f /var/lib/mysql/archie.pid ']'
+ '[' -z '' ']'
+ /usr/bin/mysqld_safe --datadir=/var/lib/mysql
+ '[' 0 -gt 0 ']'
+ sleep 1
++ getPID
++ '[' -f /var/lib/mysql/archie.pid ']'
+ '[' -z '' ']'
+ stat_fail
+ deltext
+ printf '\033[107G'
+ printf ' \033[1;34;40m[\033[1;31;40mFAIL\033[1;34;40m]\033[1;0m \n'
[FAIL]
+ exit 1

reading over fedora's init script they use the mysql config reader to set its defaults and define a pid:

get_mysql_option(){
result=`/usr/bin/my_print_defaults "$1" | sed -n "s/^--$2=//p" | tail -n 1`
if [ -z "$result" ]; then
# not found, use default
result="$3"
fi
}

get_mysql_option mysqld datadir "/var/lib/mysql"
datadir="$result"
get_mysql_option mysqld socket "$datadir/mysql.sock"
socketfile="$result"
get_mysql_option mysqld_safe log-error "/var/log/mysqld.log"
errlogfile="$result"
get_mysql_option mysqld_safe pid-file "/var/run/mysqld/mysqld.pid"
mypidfile="$result"

maybe this will help, i suggest looking at their initscript in detail as it doesn't make many assumptions and does not rely on pidof.

The problem on my machine is that the message DONE or FAIL message always says "FAIL" at boot even if mysql starts correctly.
After boot happened the script says "DONE" if I try to restart mysql. I've tracked down the problem to this code :

stat_busy "Starting MySQL"
if [ -z "$(getPID)" ]; then
/usr/bin/mysqld_safe --datadir=$MYSQLD_ROOT &>/dev/null &
if [ $? -gt 0 ]; then
stat_fail
exit 1
else
sleep 1 # wait on children <--- THIS IS THE PROBLEMATIC PART
if [ -z "$(getPID)" ]; then
stat_fail
exit 1
else

The problem for me resides in the "sleep 1" waiting for mysqld_safe children (that is mysqld) to be too short. Increasing it to "5" solves my problem and I get "DONE" correctly. Probably the system at boot is busy in other things and can't startup mysql that fast in every occasion. Maybe a safer sleep value (At least 2 or maybe 3, I tried 5 , but probably a lower one should do anyway) should be placed there.

Bye
Marcello

another thing i liked about the fedora init script which should address the previous poster's response is that it did a

mysqladmin -uUNKNWN_USER ping and grepped for a Access for user denied. Once that was the case it was aware of msyql being up and completed the initialization.

In arch if you just do a mysqladmin ping it'll respond with 'mysql is alive' so that is another avenue. The above was wrapped in a for loop with a timeout of 30 seconds so that should be more than enough time to verify that mysql is started.

This patch should help resolve the original issue reported both on boot, restart of the service and stop and start of the service

one line removed where we dont need to sleep 1 anymore since the timeo in the forloop handles this

Shouldn't the timeo assignment and the while loop be decremented one less level? It looks like the indentation is carried over from the previous patch, where it was inside the loop, rather than outside.

Could you show me some code? As far as I can tell it's correct.

This is it in its entirety, i dont see where there is an indentation error?

case "$1" in
start)
stat_busy "Starting MySQL"
if [ -z "$(getPID)" ]; then
/usr/bin/mysqld_safe --datadir=$MYSQLD_ROOT &>/dev/null &
if [ $? -gt 0 ]; then
stat_fail
exit 1
else
timeo=30
while [ $timeo -gt 0 ]; do
response=`/usr/bin/mysqladmin -uUNKNOWN_USER ping 2>&1` && break
echo "$response" | grep -q "mysqld is alive" && break
sleep 1
let timeo=${timeo}-1
done
if [ $timeo -eq 0 ]; then
stat_fail
exit 1
else
echo $(getPID) >/var/run/mysqld.pid
add_daemon mysqld
stat_done
fi
fi
else
stat_fail
exit 1
fi
;;

sorry attaching code in its entirety since this doesn't honor code format :(

The webversion of course has all of the indentation removed (oh so helpful), but it's still there in the email, and it looks correct to me. I was just going off of the last patch you posted, which clearly shows different indentation than that. You'll notice how the first two lines added ("timeo=30" and the while) are indented 4 spaces past the else that it falls under, just as the code inside the while is indented 4 spaces. The following if, however, is only indented 2 spaces, which is consistant with the code elsewhere, as well as the actual file. See how "if [ $timeo -eq 0 ]; then" isn't aligned with the "done" on the previous line? Weird, but what you emailed seems fine.

ah ok, yea the upstream init script seems to have a 2 space indentation rather than a 4 and uses spaces rather than tabulators. In anycase ill try to make sure the indentation is persistent across any version, were you able to test the init script out yet?

any word on this? has the maintainer had a chance to test this patch?

is working fine with mysql 5.0.77-3 ?

No 5.0.77-3 does not work, the script is the same as the previous release so not sure why this result would be any different. The attachment i've made march 13th 2009 works as expected.

this has been open for like 4 months now, this is an initialization script issue with a fix, could the maintainer please give an eta of when it will be fixed?

for me is fixed fomr 5.0.77.3. you could try mysql from testing 5.1.33-1

the init script in mysql 5.1.33-1 has not changed so why would it work? Biru you are the only one who says 5.0.77-3 actually works for you but there are several other people on this bug that state the previous releases are not working.

http://repos.archlinux.org/viewvc.cgi/mysql/repos/testing-x86_64/mysqld?r1=29569&r2=30280
that are the differences between 5.0.77-2 and 5.0.77-3

Ok but the problem is with the sleep 1 area, sleep 1 is not long enough to detect whether mysqld is up and running or not. This is the reason for the timeout loop I added into my patch to help with this. Giving mysqld at most 30 seconds to become active and detected by the initscript. The changes made in -3 do not address this problem but simply change the way it detects the PID of mysqld.

Thanks

The only thing that stands out in this patch is the "-uUNKOWN_USER" part seems weird.

Also, perhaps we should move the TIMEOUT value to a conf.d file to make this configurable

yea the '-uUNKNOWN_USER' is awkward but it was the only way to get mysqladmin to send a ping to the daemon. Is there any documentation on interfacing with conf.d and initscripts?

ah i see the conf.d stuff, looks like mysqld_root is also defined twice, should i file a separate bug for that or just fix that in an updated patch?

Any more work on this bug? 5.1.33 initialization script is still failing but again mine works. Kinda ridiculous now since this bug has been opened 4 months with a fix for awhile and nothing done with it.