Hi,

From http://www.slackbasics.org/html/chap...it-initscripts

It seems that if I want to turn on a service on next boot, turning on its executable flag is all that I need to do. But, do I also need to make Sxxx & Kxxx symlinks into different run levels as well?

thanks

Further, if I want to do my own initialization, does Slackware take rc.local or similar? Or, can I just name my script anything I want?

thx

A service such as cups can be activated at boot by making the associated script in /etc/rc.d/ executable. There is nothing else that needs to be done.
Slackware does provide /etc/rc.d/rc.local and it is the appropriate place from which to launch local startup scripts.

1 members found this post helpful.

For built-in slackware rc scripts, yes, simply making sure they are executable will make them run automatically. This is not true for other non-slackware scripts, though. In those cases, if you are using a simple rc script then you need to make sure it is called appropriately. Usually this just means adding a call to /etc/rc.d/rc.local (and maybe /etc/rc.d/rc.local_shutdown if really needed), but sometimes it is better to have the script called at an earlier part in the boot process. In that case you would just modify one of the main init scripts (rc.M, rc.S, rc.K, rc.4).

If you install software that uses SysV init scripts or if you want to make your own (Sxxx & Kxxx symlinks), then you need to make sure the script under /etc/rc.d/init.d is executable with the appropriate symlinks in the runlevel folders. Keep in mind that some software does not by default install the symlinks to the correct runlevel folders. Vmware, for instance, by default install symlinks to /etc/rc.d/rcX.d, where X is 0,2,3,5, and 6. Slackware uses runlevel 4 for graphical login, so you would need to move the scripts from rc5.d to rc4.d or they won't be run when booting in graphical mode.

2 members found this post helpful.

Thanks a thousand shadowsnipes, for your swift and comprehensive answer.

So just to make it abs sure, for my own initialization, I can name my script anything I want, apart from using rc.local or the main init scripts (rc.M, rc.S, rc.K, rc.4), as long as I make proper symlinks in the runlevel folders, and make the script under /etc/rc.d/init.d executable. right?

thx

You shouldn't really need to use /etc/rc.d/init.d/ -- you can put your scripts in /etc/rc.d/ directly. The init.d folder is mainly for compatibility with apps designed for other systems. Read the README.functions file in /etc/rc.d/init.d for more information. Generally, you can just add the following lines to /etc/rc.d/rc.local to start an init script that you have either created yourself or that is created when you install an app (keeping in mind that if the app is designed for another system, which is quite rare in my experience but can happen, /etc/rc.d/init.d is a suitable place for init scripts if they're installed by the app itself):
(Note that "start" may not be required depending on the init script -- you'd have to check it out on a script-by-script basis.) This will check to see if /etc/rc.d/rc.scriptname is executable (and therefore you can disable/enable it on startup simply by changing the executable bit on the file), and if it is, is runs the script (in this case passing the argument "start"). You can add as many init scripts as you want this way and still be able to control them just by setting/unsetting their executable bit (though you really shouldn't need *too* many init scripts).

Also, if you need to start an init script early on during bootup instead of late (rc.local is run last), Pat suggests sneaking it into rc.netdevice (you'll have to create the file, but you won't have to add anything to rc.local, since it is checked for existence in rc.modules* in a default setup). Since rc.modules* is called fairly early during bootup in rc.S, rc.netdevice is a suitable place for init scripts that you want run early, and since rc.netdevice doesn't exist in a default Slackware setup, it won't be over-written if you upgrade anything (UNLIKE rc.S, which *would* be over-written and you'd lose your changes). If you want to use rc.netdevice, create an init script just like you would normally but add the above code into rc.netdevice instead of rc.modules*. See here, from CHANGES_AND_HINTS.TXT:
Note that rc.S checks for the first rc.modules* file it finds in the following order:
rc.modules.local
rc.modules-$(uname -r)
rc.modules

If you do you the rc.netdevice trick, make sure that
is present in the first rc.modules* file present on your system from the list above.

1 members found this post helpful.

In short, if you install an app that installs SysV style scripts, make sure the main script is under /etc/rc.d/init.d and that the symlinks are in the appropriate runlevel.

However, if you are making your own init script, I recommend doing it the natural Slackware way. If your potential init script basically just executes a command or two then you might as well just put that directly in rc.local (or rc.netdevice if needed earlier). If you need a full init script (or just want it seperate), then the ideal situation is to create an executable /etc/rc.d/rc.name and then call it from one of the slackware init scripts (rc.local, etc). You could really put your init script anywhere you want (even your home directory) and have it called from there; they are just scripts. It's better to be consistent, however, and so I would not recommend you put your init scripts other than the standard place.

T3Slider's advice on using rc.netdevice for calling your init script early on is good, because it does avoid messing with the main init scripts (rc.S, rc.K, rc.M, rc.4). It is safe to modify these main scripts if you need more control, however. They will not get overwritten during an upgrade unless you are careless. I know this from experience because I made a lot of changes to my rc.S and rc.K to change boot behavior depending upon the value of a boot time variable. This would not be possible to do from rc.netdevice. During my upgrade I simply carefully merged my changes.

1 members found this post helpful.