do I really need to insert links into rc?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I recently installed SuSE 9.3 on x86, and it seems to contain scripts
"apache2" and "mysql" in the /etc/init.d folder. However, these two (Apache
or MySQL) are not running when I fresh reboot the machine. I am having to
execute a "./apache2 start" and "./mysql start" every time I reboot.

I am a newbie when it comes to unix admin, and I am trying to read up about
the rc scripts and how they link into the scripts under the /etc/init.d
folder. Before I rush and do what appears "natural" to me (create a S?? and
K?? links in the rc?.d), I'd like to find out some basic questions it

1. Why would the install place the apache2 and mysql scripts under the
/etc/init.d but not have any entries in any of the rc scripts?
2. What do I need to do (anything specific to SuSE) to make the apache and
mysql launch on reboot? Which rcN gets it?


Re: do I really need to insert links into rc?

Spare Brain wrote:
Quoted text here. Click to load it

That effectively installs the products, but does not configure them to
start automatically at boot time at any runlevel.  This might be
considered equivalent to a Windows Service being set to "Manual" startup.

Quoted text here. Click to load it

The `chkconfig' command can help.  It looks in the script for a line
describing a recommended runlevel at which to install links, and what
number to use for the startup order.  Chkconfig is not specific to SuSE,
it's common on Linux and similar systems.

Bill K.

Re: do I really need to insert links into rc?

Quoted text here. Click to load it

After wading through many (many) different sites, I'd need to do this, even
though apache2 and mysql came packaged:

chkconfig --add apache2
chkconfig --add mysql

And then reboot for it to take effect (or do a /etc/init.d/<program> start
if you don't want a reboot right away).

This answers #2 above, but #1 is still open.


Re: do I really need to insert links into rc?

Spare Brain wrote:
Quoted text here. Click to load it

Angus has done a good job with #2.  I'd add that you should follow up
the chkconfig add with

chkconfig --level 2345 apache2 on
chkconfig --level 2345 mysql on

This will have the effect of apache2 and mysql starting at each run
level, 2, 3, 4, 5.

As for #1, I have only a guess.  These are packages usually run on
servers, not desktops.  Did you configure for a desktop?  Also, I'd
argue that SuSE leaving it to you to decide and figure out how to turn
these on results in a less vulnerable Internet, on average.

Any service you run may be subvertible.  Therefore, the fewer you run,
the more secure, in general.  A good exercise for you, since you're new,
is to run

chkconfig --list |grep on

For every line that comes back, prove to yourself that you know what the
service is and why you need it.  If you don't recognise it, you may not
need it.  Read the man page for it.  If you're not sure, turn it off and
see what breaks.  If nothing breaks, leave it off.  To turn a service
off with chkconfig

chkconfig --level 2345 the_name_of_the_service off

Once you've done that, the service will not be started anymore for the
run levels you've turned if off for.  You still will have to kill the
running instance of the process with

service the_name_of_the_service stop

Good luck.

Re: do I really need to insert links into rc?

Spare Brain wrote:
Quoted text here. Click to load it

As others have already answered #2, I'll try to answer #1 for you as
best as I can.

Different installations require different things.  There are quite a few
ways to have your /sbin/init (or even /etc/init on older systems!)
configured to allow new packages to run.  Mostly, there is the BSD way
of doing things, and the AT&T way of doing things.  However, I never
remember which is which, because many Linux distributions emulate one or
the other, or both.

In one version, you can use /etc/rc.d/script_name_here and those scripts
are directly run at startup and shutdown, with varying parameters, and
some scripts take more then just the default "start" and "stop".  For
example, for Apache and MySQL on my system, the following is run by my
startup scripts when I boot up:

    /etc/rc.d/rc.mysql start
    /etc/rc.d/rc.httpd start

In the other one, however, you have the complex structure of symlinks
that begin with S* and K*, located in different directories which
signify the runlevel (e.g., /etc/rc.2 for runlevel two).  This yields a
slightly more flexible configuration, however, it also can lead to
disaster if you forget to add something to more then one runlevel if
needed, or if you put things in that you should... essentially it adds
more points of failure to the init system.  It depends on shell globbing
features for it to work, for starters, and it also depends on the
administrator wanting to spend the time to really tweak the system.
This is good if you use actually use different runlevels for something
useful; for example, Runlevel 2 is multi-user, and Runlevel 3 is more of
a high-load multi-user, or, in the case of a testing box, you can use
runlevels to switch from a set of production/stable servers, to a set of
testing/unstable/development servers that you're trying to work on,
debug, whatever.  Largely enough, though, it's a PITA.

Slackware Linux, FWIW, provides the former behavior by default, and
impelements the latter using a shell script to emulate the full
functionality.  This should be used with caution, however, as it's not
perfect.  I am not sure how SuSE does things, but I'm sure that it can
probably be configured to do either/or, since you can have one script
that is linked to, managing a /etc/rc.d/rc.* configuration similar to
what is native (and, simpler) in many systems.  For the most part, in
systems that are "live," and use the former configuration that I
mentioned, they will run those scripts for all runlevels except for 0,
1, and 6, assuming that on your system you're not using a terribly
heavily customized configuration:  These runlevels typically represent
halt, single-user mode, and reboot, respectively.


Site Timeline