/etc/rc.d/ startup scripts question

To answer your specific question, no, I don't believe that arbitrary scripts in the /etc/rc.d directory are executed automatically at startup. The simplest thing to do is probably to add a few lines to /etc/rc.local that will execute your script.

Traditionally Slackware didn't support the SYSV-style individual /etc/rc#.d scripts, and just had scripts in /etc/rc.d controlled from inittab. It was a little more BSD-like, although it did have the concept of runlevels. A typical process for customization was using rc.local, which always runs at the end of multi-user startup. If you're interested in fully tracing startup, start with init (man init) and /etc/inittab and then view each of the referenced scripts that execute based on the inittab configuration.

But there's been compatibility with the SYSV scripts for a while through an rc.d/rc.sysvinit script that runs during multiuser runlevels and will automatically execute the /etc/rc#.d scripts. It's mostly to support third party package installation that expected the SYSV startup script approach.

So you could also place links to your script in the appropriate /etc/rc#.d directories (prefixing them with S## to run a startup for that runlevel, or K## to shutdown when leaving that runlevel, where ## is a numeric sequence to order all scripts at that runlevel).

Note that there's nothing wrong with using the rc.local approach - it's probably more typical for Slackware. The references you found to just putting an executable script in /etc/rc.d should probably have included information on adding something to rc.local to then run your script, as that's a way to keep the pieces from all having to be part of the single rc.local file.

Startup processing is definitely one of the places where Linux distributions will vary a bit.

If you choose to experiment with other distributions, you'll probably find that the SYSV approach is more common, and with many current distributions you'll find the master service scripts in /etc/init.d, which are then symbolically linked into the appropriate /etc/rc#.d directories. Slackware does have an /etc/init.d directory for compatibility though all of the system scripts are in /etc/rc.d. And if you look closely, even the compatibility /etc/{init.d,rc#.d} directories are symbolic links to the master location which is all beneath /etc.rc.d. There are other variations too, such as Gentoo's approach that uses symbolic names for runlevels, via directories beneath /etc/runlevels that control what scripts run for a given runlevel (/etc/init.d scripts link to that directory rather than /etc/rc#.d).

Some distributions have even replaced the venerable init (and its /etc/inittab), such as Ubuntu's "upstart" which is controlled from configuration files in /etc/event.d instead.

– David

Thank you very much for your clear explanations!

> The references you found to just putting an executable script in /etc/rc.d should probably have included information on adding something to rc.local to then run your script, as that's a way to keep the pieces from all having to be part of the single rc.local file
Well, I found helps and tutorials that were mostly dealing with very special rc.* scripts such as rc.firewall, rc.httpd etc. Now I understand why theses scripts "just work" when they are located in /etc/rc.d. Reference to rc.httpd for example is already "hard coded" in rc.M despite the fact I don't want nor have an apache daemon running around!

As you suggested, I studied /etc/inittab. Everything makes sens now, thank you very much. Slackware is a super cool distrib :D