Slackware initscripts: not so KISS?

Gullible Jones · 2010-08-04 00:48:37

I generally love Slackware for its stability and lack of breakage. Even the lack of dependency handling can be advantageous sometimes, IMO. However, I've noticed that boot and shutdown tend to be rather slow, so I was messing around with my Slack installation's initscripts to see what could be done... And I kept seeing stuff like this:

# Start D-Bus:
if [ -x /etc/rc.d/rc.messagebus ]; then
  sh /etc/rc.d/rc.messagebus start
fi

# Start HAL:
if [ -x /etc/rc.d/rc.hald ]; then
  sh /etc/rc.d/rc.hald start
fi

# Start Bluetooth:
if [ -x /etc/rc.d/rc.bluetooth ]; then
  sh /etc/rc.d/rc.bluetooth start
fi

It looks as though just about every script that would normally be in /etc/rc.d has an entry like that in /etc/rc.M. Likewise the shutdown entries in rc.6, and a few in rc.S.

Is it just me or is that not a very maintainable/scalable way of handling this stuff? It would seem to me that every "new" (i.e. not typical for a Slack install) file in /etc/rc.d would need a new entry like that in /etc/rc.M, etc. Unless this is just some hack to make sure things start in the right order?

On further thought, I might note that OpenBSD does something similar... Only OpenBSD IIRC doesn't use /etc/rc.d/rc.X scripts at all. You want to e.g. start dbus on boot, you put something like this

if [ -x /usr/local/sbin/avahi-daemon ]; then
        echo -n ' dbus daemon'; /usr/local/bin/dbus-daemon --system
fi

in /etc/rc.local. Harder on the user I guess, but no need for an rc.d script = simpler. Right?

Assuming all you needed for runlevels were single-user and multi-user, wouldn't it be better to just have an rc.S script with the core system stuff, and rc.M script containing stuff like the OpenBSD example and instructions on how to add daemons, and do away entirely with the other rc.d scripts? What's the rationale for Slackware's current method?

Misfit138 · 2010-08-04 01:32:20

I haven't used Slack in a couple years, but iirc, the /etc/rc.x entries are simply for compatibility reasons...in case a program is expecting the ever popular sysV init.

Gullible Jones · 2010-08-04 01:38:35

Hmm... In that case why would the initscripts invoke /etc/rc.d/rc.X instead of running the daemon directly?

Mind, it does work. But it strikes me as a kind of cumbersome setup.

Misfit138 · 2010-08-04 01:59:56

Again, iirc, services in Slackware are set up in the /etc/rc.d directory, and the recommended method of enabling/disabling them is to simply chmod the scripts..though I don't recall ever investigating the init scripts themselves.

brebs · 2010-08-04 04:44:45

Gullible Jones wrote:

why would the initscripts invoke /etc/rc.d/rc.X instead of running the daemon directly?

Because it's easy, standard behaviour.

Remember, initscripts are not always as simple as just running the daemon.

Arch Linux

#1 2010-08-04 00:48:37

Slackware initscripts: not so KISS?

#2 2010-08-04 01:32:20

Re: Slackware initscripts: not so KISS?

#3 2010-08-04 01:38:35

Re: Slackware initscripts: not so KISS?

#4 2010-08-04 01:59:56

Re: Slackware initscripts: not so KISS?

#5 2010-08-04 04:44:45

Re: Slackware initscripts: not so KISS?

Board footer