When using baselayout-2 on Gentoo/FreeBSD, mysql fails to start with the following error: # /etc/init.d/mysql start * Caching service dependencies ... /etc/init.d/mysql: 9: Syntax error: "(" unexpected /etc/init.d/mysqlmanager: 14: Syntax error: "(" unexpected [ ok ] /etc/init.d/mysql: 9: Syntax error: "(" unexpected * ERROR: mysql failed to start
Created attachment 120196 [details] mysql init script Then then. The current scripts try to re-invent too many wheels. baselayout has supported the concept of multiplexing for some time. link the scripts to mysql to do this like so ln -s mysql /etc/init.d/mysql.foo Then MY_CNF will default to /etc/mysql.foo/my.cnf. This new script is very simple and should work just fine. Any special args should be placed in /etc/conf.d/mysql like so MY_CNF="/etc/myfoo/my.cnf" (defaults to /etc/mysql/my.cnf) MY_ARGS="--optionone=1--optiontwo=2"
Oh yes - what's the mysqlmanager script for? I've not touched that as it seems pointless?
*** Bug 166606 has been marked as a duplicate of this bug. ***
I for one won't let this hold up baselayout-2
Is someone going to fix this one?
Please commit the script!
Well seriously WTH is up with this?
roy: you wrote this, and there's one critical problem with it. MySQL should NOT be considered up until the socket comes into existence at /var/run/mysqld/mysqld.sock. Depending on the size of your databases, this can be anywhere from 0 to ~60 seconds after the process has been backgrounded by s-s-d. If the init script returns success right away, and the next thing that tries to start wants to use the socket, then it's going to fail. In the previous edition of the scripts, we looped checking for that socket - should that logic come back, or can you suggest a better way?
Fix mysql to create the socket before daemonising? But aside from the proper fix, no I don't have any other ideas at this time. If other daemons have the same flaw, then maybe a function could be created ewaitfile /var/run/mysqld/mysqld.sock 60 Give it 60 seconds to create the socket.
roy: mysql doesn't daemonize. ssd does the work itself via --background. I'd be up for an ewaitfile being provided by baselayout, I certainly do see other cases where it would be a good solution.
OK, maybe adding it to ssd would be the better solution then. However, that won't easily fly for baselayout-1.
How about a fallback in the mysql script, that if a ewaitfile function is not already available, it defines one of it's own?
No, I was thinking about adding it to ssd start-stop-daemon --waitfile /foo
here's a trick that should work, but it's a bit unclean. BTW, is there something better than existence of librc that init.d scripts can check to see if they are running under baselayout2? ===== [ -e /lib/librc.so ] && opts="${opts} --waitfile foo" start-stop-daemon ${opts} ... [ -e /lib/librc.so ] || ewaitfile /foo =====
Not really no... I suppose we could export a function openrcpreq so you could do this if openrcpreq 1 2; then funk new feature elif openrcpreq 1 0; then inital release feature else sol :P fi
that's pretty ugly as well we can just add things to baselayout-1.x to ease transition as needed ... ive already been doing this for some time
Created attachment 155247 [details, diff] Add ewaitfile to openrc This adds the ewaitfile function to OpenRC. ewaitfile timeout file1 [file2 ...] If timeout <1, then we wait forever. Comments?
uberlord: looks good, and just in time for final upcoming pass at putting this in the tree. Tell me what version of openrc it goes into, so I can have a suitable RDEPEND entry.
It will go into openrc-0.2.6 which will be cut once bug #224171 is solved - if I can work out wtf is going wrong there :) In the mean time, feel free to patch 0.2.5 with it if you like as it could be out today or a week or so.
ewaitfile now exists in 0.3.0.
*** Bug 173057 has been marked as a duplicate of this bug. ***
Mysql has always started up fine for me until just recently, I presume with the upgrade to openrc 0.4.x (since I run ~amd64). Does that make sense, or is it meant to be working now?
Ping! What's holding this back?
It looks as though a different fix to the one that was suggested was applied at some point since this is already in the init script. Not sure when this happened. while ! [[ -S "${socket}" || "${STARTUPTIMEOUT}" -lt 1 || "${retstatus}" -ne 0 ]] ; do STARTUPTIMEOUT=$(( STARTUPTIMEOUT - 1 )) [[ ${DEBUG} -ge 1 ]] && echo -n "${STARTUPTIMEOUT}," sleep ${TIMEUNIT} done Something's still not right though. I set the timeout to 15 seconds, which was long enough for MySQL to start without the script reporting a failure but mythbackend seems to give up waiting before its ready. I always have to run "rc" after my system has booted to give it another shot at starting. Maybe this isn't the exact cause but I'm pretty sure MySQL is to blame.
Created attachment 191550 [details, diff] Use ewaitfile I've been running Roy's script with the addition of ewaitfile (see attached patch) for quite some time now. No problems so far. I don't have large databases though, so testing from people with some large DBs is appreciated. The timeout parameter for ewaitfile can be made configurable via conf.d if needed, for now it's hardcoded at 60 seconds.
If this is still an issue, it is a blocker for openrc stabilization. Marking as so.
My issue has gone, at least. Sorry, forgot about this bug.
It looks like openrc now includes ewaitfile, so I am closing this bug. Please re-open if there is still an issue.
(In reply to comment #28) > It looks like openrc now includes ewaitfile, so I am closing this bug. Please > re-open if there is still an issue. > Have you fixed the init script to use ewaitfile? Btw, a revision or version bump would be a good idea IMHO.
(In reply to comment #29)n> (In reply to comment #28), I> > It looks like openrc now includes ewaitfile, so I am closing this bug. Please > > re-open if there is still an issue. > > > > Have you fixed the init script to use ewaitfile? Btw, a revision or version > bump would be a good idea IMHO. > It doesn't appear so: marcec marcec # grep ewaitfile /etc/init.d/mysql* marcec marcec # The init-script is provided by dev-db/mysql-init-scripts, which hasn't been updated since 2007: marcec marcec # head /usr/portage/dev-db/mysql-init-scripts/ChangeLog # ChangeLog for dev-db/mysql-init-scripts # Copyright 1999-2007 Gentoo Foundation; Distributed under the GPL v2 # $Header: /var/cvsroot/gentoo-x86/dev-db/mysql-init-scripts/ChangeLog,v 1.3 2007/04/28 16:58:36 swegener Exp $ 28 Apr 2007; Sven Wegener <swegener@gentoo.org> mysql-init-scripts-1.2.ebuild: Fix *initd, *confd and *envd calls (#17388, #174266) Since I still get the error as originally reported by Bjarke Istrup Pedersen, I think this bug should be reopened (I would myself, but I don't appear to have the necessary rights). marcec marcec # /etc/init.d/mysql status /etc/init.d/mysql: 9: Syntax error: "(" unexpected marcec marcec # /etc/init.d/mysqlmanager status /etc/init.d/mysqlmanager: 14: Syntax error: "(" unexpected
Bug reopened.
OK, I just wanted to note that the original error (the syntax error) is due to my using dash as /bin/sh. With the symlink pointing to bash instead it works (I just remembered this morning), so sorry about that. This doesn't affect the other issue - the fact that ewaitfile isn't used in the init scripts - in any way, though.
(In reply to comment #32) > OK, I just wanted to note that the original error (the syntax error) is due to > my using dash as /bin/sh. With the symlink pointing to bash instead it works (I > just remembered this morning), so sorry about that. Which shell you're using is irrelevant. Init scripts must be POSIX-compliant, i.e. every POSIX-compatible shell should be able to execute them (and dash is POSIX-compatible). If the script uses bashisms, then it must be fixed.
(In reply to comment #33) > Which shell you're using is irrelevant. Init scripts must be POSIX-compliant, > i.e. every POSIX-compatible shell should be able to execute them (and dash is > POSIX-compatible). If the script uses bashisms, then it must be fixed. There is in fact already a bug regarding this: 289970 (and perhaps also 299130).
*** Bug 289970 has been marked as a duplicate of this bug. ***
*** Bug 299130 has been marked as a duplicate of this bug. ***
Any news regarding this topic? Has maybe someone made a script that is actually POSIX sh compatible? If yes please attach it here.
Created attachment 235857 [details] POSIX-compatible init script Works for me.
I just tested this with the original mysql init, and the attachment in Comment #38. Both scripts work for me. I was not able to hit the original bug. This is an old bug and I'm not sure what might have changed. I'm using: sys-apps/baselayout-2.0.1 sys-apps/openrc-0.6.1-r1 dev-db/mysql-5.0.90-r2
I guess /bin/sh is pointing to bash on your system... that's why you can't reproduce the original problem.
(In reply to comment #40) > I guess /bin/sh is pointing to bash on your system... that's why you can't > reproduce the original problem. > What shell(s) would you recommend testing with? dash?
(In reply to comment #41) > (In reply to comment #40) > > I guess /bin/sh is pointing to bash on your system... that's why you can't > > reproduce the original problem. > > > > What shell(s) would you recommend testing with? dash? > Yes, dash.
Since this is a blocker for openrc stabilization, is there any way that someone can take a look at it soon? Thanks much, William
Well I does not understand why init scripts aren't written for pure posix SH but for bash. OpenRC for a reason uses /bin/sh not a /bin/bash. I wonder when this bug will be fixed.
POSIX compatibility in init.d scripts is not a blocker for openrc/baselayout-2. if people have the default of /bin/sh pointing to bash, does current mysql work with openrc ?
Quite sure it does work.
(In reply to comment #45) > POSIX compatibility in init.d scripts is not a blocker for openrc/baselayout-2. > if people have the default of /bin/sh pointing to bash, does current mysql > work with openrc ? > It works perfectly fine with sh -> bash. I was thinking of fixing the minor syntax errors to get it to work with dash, but I really don't see the point. Close invalid?
thanks, we'll just roll with that assumption. people have to manually opt into /bin/sh -> dash in the first place by creating the link by hand ... there is nothing like a USE flag combo to trigger this.
there is no hard requirement anywhere that init.d scripts must be POSIX. it is however generally preferred that packages support it as it does enable people to use a smaller/faster shell, as well as work with embedded systems like busybox. that is why we treat these bugs as enhancements for when people get around to it, and to encourage users to help out.
> there is no hard requirement anywhere that init.d scripts must be POSIX. Well openrc uses /bin/sh, not /bin/bash so it could be good reason to make all init scripts working on bourne shell. There is already working init with 'real' /bin/sh, POSIX compatibility, maybe someone can review it and push into mysql-init-scripts?
As the original coder of the script may I add some history? I was the mantainer of MySQL at the time, with overengineered intents to slot dev-db/mysql in 4.0, 4.1 and 5.0. To make this possible an init script able to start multiple version of mysql was necessary. At the time I was rather ignorant on init.d/* world and seeked help w/o success from persons which knowed better, no response arrived in circa one month. Obviously at that point I did started to code and hacked it whith some things in mind: 1) possibility to start different (slot) version of mysql 2) possibility to start different mysql of the same version 3) possibility to override /etc/mysql/my.cnf options in /etc/conf.d/mysql 4) don't mark the service started until it's started for good today: 1) is vastly unneded nowadays 2) useful, some people start one mysql server per cpu or per disk 3) useful but less that in the past, mysql is now good at my.cnf location and parsing (it was not) 4) still needed but `ewait` can be used to wait for the socket instead of some hacked bash To be honest after some time I did the script there was a suggestion to convert it into the net.* way, it should have been done, but I had already worked a lot on that, and also a cold feeling that if that suggestion was arrived some month before much work coulda been avoided make me (wrongly) decide not to change what already in production. Suggestion: bash -> dash mayor incompatibility are arrays, it would seem easy to change the init.d script but the really challenge is the __conf.d__ script by default it's empty but if someone had used it those variables are all arrays and not of the easy ones to convert into delimited string (as it was for /etc/conf.d/net). So please dont'change the status quo, maybe a "posix" use flag may be added to dev-db/mysql-init-scripts, triggering much simpler script which work similarly to those net.*, w/o the complex conf.d file parsing (except for maybe NICE values). Remember to check for the socket mysql create in any case. P.S. mysqlmanager -> http://bugs.gentoo.org/114667 don't know if anybody ever used it tough. P.P.S. I'm avaiable to fix the scripts or to create new ones and to test them, just before to do so I really, really want to know what Gentoo users need, what are the requirements of compatibility and whatever else jump in at the moment.
(In reply to comment #51) > P.P.S. I'm avaiable to fix the scripts or to create new ones and to test them, > just before to do so I really, really want to know what Gentoo users need, what > are the requirements of compatibility and whatever else jump in at the moment. Hi there. About compatibility - if your script will work with dash, it will work with each bourne shell compatible shell. Busybox's ash have some bashines (for example you can use [[ with ash where dash understand only [ like bourne shell). If you need help or someone to test it, please mail me.
(In reply to comment #52) > (In reply to comment #51) > > P.P.S. I'm avaiable to fix the scripts or to create new ones and to test them, > > just before to do so I really, really want to know what Gentoo users need, what > > are the requirements of compatibility and whatever else jump in at the moment. > > Hi there. About compatibility - if your script will work with dash, it will > work with each bourne shell compatible shell. Busybox's ash have some bashines > (for example you can use [[ with ash where dash understand only [ like bourne > shell). > > If you need help or someone to test it, please mail me. > the other way, see it from the users point of view: If the script need to work with posix sh there is no way to keep compatibility with the init script which are in portage since 2005 on the other hand possibly very few people use conf.d/mysql (I do not anymore)
I do use multiple-instance MySQL on the other hand, as they are presently written. Also, that get_config change w/ needs to take into account any options passed in MY_ARGS (datadir, basedir, pid-file, socket).
(In reply to comment #49) > there is no hard requirement anywhere that init.d scripts must be POSIX. That is only true for when Gentoo/Linux is the host platform. http://www.gentoo.org/proj/en/gentoo-alt/prefix/ Plenty of items listed there where /bin/sh does not default to bash. I would argue that if projects like Gentoo Prefix have any chance of being successful then POSIX compliance of init scripts should be a hard requirement and maybe enforced by portage before commits.
But still it's no regression for Gentoo Linux which happens to be the only project that needs this STABLE. I'm quite sure the Alt team hasn't changed the policy that they have not to block the Linux side of the development with anything at all. So once again, this is enhancement and not blocking.
how are prefix platforms relevant if they arent using baselayout init.d scripts besides, as Diego points out, this is a stable issue and that only applies to Gentoo running Linux
(In reply to comment #57) > how are prefix platforms relevant if they arent using baselayout init.d scripts For example launching any daemons installed by portage. When OpenRC is compiled for /some/path instead of /, then the automatic running of the majority of the installed init.d scripts is disabled by the -prefix keyword. So, if mysql is installed in a prefix environment via portage then it could still be configured and launched if the standard mysql Gentoo instructions where followed.
unless i missed something, the openrc ebuild doesnt expose that functionality, and it lacks prefix keywords, so it's a moot point
When is the bashism syntax [[...]] etc going to be fixed? MySQL won't start when using dash as default-sh with baselayout-2.
please refrain from useless comments. read the bug to figure out the status yourself. after that, feel free to *contribute* the fixes required to move the bug along, otherwise wait patiently/quietly.
(In reply to comment #60) > When is the bashism syntax [[...]] etc going to be fixed? MySQL won't start > when using dash as default-sh with baselayout-2. Please help out. Here are the bash-ism that I found: 1. [[ ... ]] needs to be replaced by [ ... ]. Trivial 2. Bash arrays like srv=( ${srv_slot} ${srv_num} ) need to be replaced everywhere so wdebug 3 "srv ${srv[@]}" becomes wdebug 3 "srv ${srv_slot} ${srv_num}" 3. At least one redirection variable needs to be replaced: local tmp_eval="mysql_slot_${srv_slot}${srv_num:+"_"}${srv_num}[@]" local conf_d_parameters="${!tmp_eval}" The way this works is (for example) A="hi" B="A" echo ${!B} gives "hi" with !B being replaced by its value A and then A being treated as a bash variable. There may be more bashisms, but that's what I've got. I've done part 1, I've 1/2 done part 2, and part 3 is a mess.
again, trying to say it with different words: to remove bashism from init.d/mysql make NO SENSE, because you have users with bashism in CONF.D/mysql. If /etc/conf.d/mysql is of no worry THEN init.d/mysql should BE REWITTEN in 10 lines of pure posix sh or 20 of i386 assembler whatever you want.
(In reply to comment #63) > to remove bashism from init.d/mysql make NO SENSE, because you have users with > bashism in CONF.D/mysql. This is probably because the current script tries to handle multi-instance itself while baselayout-2 already supports that out-of-the-box (afaik). So in a baselayout-2 world we could probably completely remove that feature and stick with a more easy and maintainable init.d script? This would probably what Davide already provided with the attachment dated 2010-06-18.
(In reply to comment #64) > (In reply to comment #63) > > to remove bashism from init.d/mysql make NO SENSE, because you have users with > > bashism in CONF.D/mysql. > > This is probably because the current script tries to handle multi-instance > itself while baselayout-2 already supports that out-of-the-box (afaik). > > So in a baselayout-2 world we could probably completely remove that feature and > stick with a more easy and maintainable init.d script? This would probably what > Davide already provided with the attachment dated 2010-06-18. a) gentoo still is not a pure baselayout-2 world b) to change the scripts is trivial, to make sure the change will NOT suddently break working installation is not. reassuming: the change should be pubblicized and documented to avoid broke running systems. rewrite the script is easy migration is difficult. Your efforts, if you want to help, need to be directed into avoiding breakage, possibly writing guide or studing a new dev-db/mysql-init-scripts ebuild that die() if a modified conf.d/mysql is in place.
(In reply to comment #65) > a) gentoo still is not a pure baselayout-2 world This will hopefully be the case soon though. There seems to be a new push towards making OpenRC stable. With that in mind, it's probably better to wait than to try and target both now.
> rewrite the script is easy > migration is difficult. Yes and no. I was looking at the script from the point of view of rewriting it so that it *does not* break backwards compat. In that case, rewrite is hard and migration is easy. If we abandon conf.d/mysql, then yes, rewrite is easy, migration hard.
(In reply to comment #67) > If we abandon conf.d/mysql, then yes, rewrite is easy, migration hard. Migration of conf.d to baselayout-2 is no easy task anyway. At least for me it was never straight forward. So I think it would be feasible to take this step for mysql once baselayout-2 goes stable - or even install different init.d scripts based on which baselayout version is detected. One the other hand having two scripts to maintain may sound like a stupid idea but in comment #30 I read it wasn't updated since 2007 anyway - so what about maintenance efforts?
I have worked on this now, and have it in the MySQL overlay, along with a news item about the required migration. Please test, I hope to move it to the main tree in a week (p.masked) if all is well. http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=commitdiff;h=161bb79950395ab6e0d59187e4fd14053505c50d http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=commitdiff;h=6beff5532a04274b0d619242fa6dd6a3872c3381
I'm on the way to replace bash by dash to speed up the boot process. But mysql still fails to start. How's the current state of that init-script? Is there a chance to expect it to be merged into the mainline portage tree somewhere in the future?
musv@gmx.de: Go and use the mysql-init-scripts-2.0_pre1-r2 version. If you still have a problem with that and dash, open a new bug. It's also considered good form to CC yourself to a bug when you make a comment expecting a response.
Version 2.0_pre1-r2 still yields the following with dash: $ sudo /etc/init.d/mysql start mysql | * Caching service dependencies ... [ ok ] mysql |/lib64/rc/sh/runscript.sh: 282: Bad substitution So, not resolved...
dev-db/mysql-init-scripts-2.0_pre1-r2 * QA Notice: shell script appears to use non-POSIX feature(s): * possible bashism in /etc/init.d/mysql line 28 (${!prefix[*|@]): * local varlist="${!mysql_slot_*} ${!MYSQL_BLOG_PID_FILE*} ${!STOPTIMEOUT*}" * possible bashism in /etc/init.d/mysql line 29 (${parm/?/pat[/str]}): * varlist="${varlist// /}" * possible bashism in /etc/init.d/mysql line 91 (${parm/?/pat[/str]}): * start-stop-daemon \ * ${DEBUG/*/"--verbose"} \ * --start \ * --exec "${basedir}"/sbin/mysqld \ * --pidfile "${pidfile}" \ * --background \ * --wait ${startup_early_timeout} \ * ${tmpnice} \ * ${tmpionice} \ * -- --defaults-file="${MY_CNF}" ${MY_ARGS} * possible bashism in /etc/init.d/mysql line 117 (${parm/?/pat[/str]}): * start-stop-daemon \ * ${DEBUG/*/"--verbose"} \ * --stop \ * --exec "${basedir}"/sbin/mysqld \ * --pidfile "${pidfile}" \ * --retry ${stop_timeout}
InCVS