rc.httpd and rc.mysqld break startup scripts
Hello fellow slackers,
On my SW12.1 box I am trying to get both httpd and mysqld to startup on boot. However, they are mutually destructive with respect to their startup routines. And it does not matter whether I have them listed in rc.inet2 or rc.M or rc.local - either way the first guy will kill the rest of the startup chain. Both scripts have Code:
exit 1 Code:
exit 0 My initial thought was to comment out the various exit statements in both scripts. This proves to be fishy business because rather than exiting prematurely on an error (or success), the script continues to chew through its remaining lines, which screws things up. The thought just occurred to me (writing this during a MIPS assembly language class talking about jumps and such) that I should probably create a label at the end of the file and rather than exit, just "jump to the end." I'll try this later, but hopefully this is the end of the line for me. I haven't had this problem before on my LAMP setups, so I wonder a bit if it should be this much work... any thoughts appreciated. |
Is MySQL initialized?
Rather than being 'mutually destructive' it sounds more like MySQL has not been initialized yet. Did you run mysql_install_db or otherwise set up the initial database?
See the comments at top of /etc/rc.d/rc.mysqld. If you have already done this how about a little more info on your setup. |
Nether rc.httpd or rc.mysqld have any exit in them and both of them are already sourced from rc.M.
All you have to do is make the rc.* files executable and they will be ran. As far as the exit making the parent script end it depends on if it was sourced into the calling script or if it was "ran" and how the shell has been configured. |
3 Attachment(s)
the last lines of /etc/rc.d/rc.M:
Code:
# Start the MySQL database: XGizzmo, you were suggesting that if I replaced the line that said Code:
. /etc/rc.d/rc.httpd start Code:
/bin/sh /etc/rc.d/rc.httpd start |
What do you get if you try to start mysql after you boot?
As root, (assuming /etc/rc.d/rc.mysqld is executable) Code:
/etc/rc.d/rc.mysqld start |
Each script starts its respective server on its own with no errors - works beautifully, it's just that anything I try to start after them (including the other one) is screwed.
For your amusement, this is what I get (just now): Code:
xxx@xxx:xxx$ sudo /etc/rc.d/rc.mysqld start Code:
Starting MySQL. SUCCESS! I moved the two server startup blocks to rc.local for testing just now, and changed the ". " invocation to a full "/bin/sh" invocation, hoping for a forked shell that can absorb the extra "exit" and return to hit the next one the same way: Code:
# Start the MySQL database: Code:
xxx@xxx:/etc/rc.d$ sudo ./rc.local |
Quote:
Anyway, glad you got it going. |
Quote:
Is there a reason why you are not using Slackware's scripts? Eric |
A quick perusal of rc.M seems to show some of the called subsystem rc scripts are sourced in and some are called with their own shell process..
Wouldn't it just be better to spawn new shells for all of the subsystem scripts and reduce the chance of possible cross contamination or other errors from customised subsystem scripts? Though sourcing as much as possible may provide some small performance gain during startup, wouldn't the consistency and resilience of spawning a new shell for each of them be worth any additional cost in overhead? |
Quote:
|
AlienBob:
rc.mysqld is a symlink to /usr/local/share/mysql/mysql.server, which is the provided shell script for starting the mysql server, and is init-script-compliant (rc.mysqld start works) except for the fact that it exits. Thus it is not an official Slackware script. rc.httpd I believe I wrote myself, following the example of other basic init scripts using the simple Bash case...esac structure. This calls apachectl, as you have seen, and that is where the exit occurs. GazL: I did not write the remainder of rc.M - the default behavior was to source all subsequent rc scripts as they were - I see now that this may be the safest procedure... |
Quote:
|
Quote:
|
Quote:
|
Quote:
Code:
sed -e 's:\. /etc/rc.d/rc.:/bin/sh /etc/rc.d/rc.:g' /etc/rc.d/rc.M |
Quote:
|
Quote:
|
Quote:
Is that so difficult e.g. to type "grep rc.httpd /etc/rc.d/*" and check the output ? |
Would you not have to replace all the /path/to/binary portions of the rc scripts with `exec /path/to/binary` to stop having a bajillion spawned shell processes?
Also spawning a new shell for everything would affect 'global' variables like PS1, PATH, etc, to the extent that they would never appear in any scope other than the one that was spawned (and has maybe since been exec'd away). I sympathise with the OP that his rc.M broke, but it broke because of poor understanding of the startup mechanisms. Knowing that (by default) startup scripts are all sourced and modifying your custom scripts to match the default is surely a better method than rewriting the entire init procedure to match some generic scripts that have been written as an example. Likewise, knowing that you can change rc.M where you prefer your own scripts to the 'official' ones is also a valid approach, which has been applied successfully I think to solve the OP's original problem. For discussions on source vs shell, maybe a new thread would be a plan get the best exposure? - Piete |
Quote:
2. More friendly to non-sh scripts. For example, "rc.udev" is a bash-only script. I myself would also like to use python, in which case "source" is nonsense. If everything is run directly, the calling command need not be changed even if the interpreter changed, or even if the script is replaced by an ELF program. I have both cases in my /etc/rc.d/ I usually write a new script with sh; then when it grows, if I find difficulty, I change to python; in the end, if I think the script needs no more change, I sometimes re-write it in C. Because I don't use "source", the "rc.*" scripts themselves need not be changed. |
I think if you decide to mess with the Slackware default scripts, you should be prepared to change anything that prevents total disaster. If you change scripts and add "exit" statements, you are responsible for changing the source-ing to spawning an external shell for the script's execution. Using python during early bootup is certainly not recommended because of the library files it needs in /usr/ ... you can not be certain (when you write scripts to be used on many different computers) that the /usr directory is available that early. It may be on a separate partition which is only mounted later.
Slackware's rc scripts will likely remain as they are, since I have not heard a good reason why they should change. Spawning a subshell will make the boot stage's shell environment unavailable to the script. Variables set of changed inside the script would vanish once the script ends. Eric |
Quote:
I think it will be even better to omit the sh. "/etc/rc.d/SCRIPT_NAME" is enough because some scripts, e.g. "rc.udev", is not sh-compatible (rc.udev is bash-only). Quote:
Quote:
Quote:
If you must export variables, I think it's better to do it this way: Code:
# ******* This is /etc/rc.d/rc.M ******** Code:
#! /usr/bin/env python |
Guanx, my guess is you won't convince Slackware team to make the changes you propose.
But nobody prevents you to fork Slackware -- you would not be the first, anyway. Meanwhile I will stick to the original ;) Cheers, |
Quote:
Actually, Slackware has already changed many "source SCRIPT_NAME" commands in "rc.M" and alikes to "sh SCRIPT_NAME". This means there are not so may environment variables to export as Eric thought. Preventing namespace pollution is more important. Now because the scripts are not source-ed generally, if I want to use python instead sh, I can write the script this way: Code:
#! /bin/sh |
Quote:
Then you have the issue of fault tolerance. Expecting someone making customisations in sub scripts to get it right is reasonable enough, but what's so wrong with making rc.M able to cope with errors regardless. It's just sound design and good programming practice. Actually, on reflection, I like guanx idea of not even prefixing them with the shell at all and letting the interpreter string identified within the script file determine what executable is used to run it. Quote:
Quote:
If you want to take the line that: it's 'good enough' as it is and doesn't need changing, then that's fair enough, but that doesn't mean that these suggestions are without merit. I can see that guanx is on the same wavelength as I am here, I guess I'll have to settle for that. |
I Have Slackware 12.1 running really fast and flawlessly on my new Dell laptop, I used the command above: mysql_install_db , and it got my mysql server working pretty much instantly. What script can I use to get the mysql server to boot when I boot the laptop up ?
Does Slackware have a command to run a process manager? |
I haven't checked the init scripts in question, but I suspect that the fact that some are simply sourced while others are run in a separate proces (using sh)has to do with whether the called process runs as a backgrounded daemon or not. If you source a script which starts a process which does not background itelf, then the init process would hang right there. Such a process would have to be run with a separate process to allow the normal bott process to continue.
|
Quote:
To make MySQL start at boot simply make /etc/rc.d/rc.mysqld executable. As root... Code:
chmod 755 /etc/rc.d/rc.mysqld Code:
chmod 644 /etc/rc.d/rc.script_name |
All times are GMT -5. The time now is 08:47 AM. |