e.g., BSD style (Slackware) vs. SystemV style startup scripts
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
e.g., BSD style (Slackware) vs. SystemV style startup scripts
Longtime Linux/Unix user here who is most used to SystemV style init scripts. Fairly new to Slackware and BSD style init scripts. No problem understanding how they work and the "more than one way to skin a cat" aspects of setup.
I'm looking for hints on "the standard way of doing things in Slackware". Is there good FAQ on this topic somewhere? Not just for my init scripts example here, but in general.
e.g., If I don't want sendmail, I could turn off execute permission on /etc/rc.d/rc.sendmail (this is the way Slackware installed by default). This would turn it off for all runlevels. Or, I could leave /etc/rc.sendmail executable and comment out sections of /etc/rd.M, /etc/rc.S, etc. to control it's startup between single user and multiuser runlevels. Or, for even more finer grained control (say between runlevel 3 and runlevel 4 - both being multiuser), I could create SystemV style init scripts under the /etc/rc3.d and /etc/rc4.d subdirectories.
Is there anything more to the choice ("the Slackware way") than I've mentioned above? It appears to be sysadm choice, based on the desired level of control.
I understand there are many ways to accomplish what I propose in this hypothetical example. But I'm trying to learn the "standard" Slackware way (if there is such a thing) rather than trying to bend Slackware into my preconceived notion of things. Init scripts are only one example of different ways to do things. I like to learn each distro on it's own merits rather than try to force one to act like another (I realize they're all the same down at the command line level - where I personally prefer to work). However, it's still nice to be able to "speak" in each distros language when talking to users of that distro. i.e., the "answer" on how to control sendmail from a Ubuntu forum would probably be totally different than the "answer" from a Slackware forum (although at the low level the actual implementation is probably very similar - it's the user interface that's different). The universal language is command line, but unfortunately not all users speak that, and if you need to help them it's easier to learn their language than to force yours on them.
I'm looking for hints on "the standard way of doing things in Slackware". Is there good FAQ on this topic somewhere? Not just for my init scripts example here, but in general.
Login as root, read your mail (using "mail" or "alpine" commands). There will be a letter labeled "Welcome to Slackware Linux". It would be a good start. For me it (in conjuction google) was enough to get started, at least.
Hi haertig, welcome to our forum. I addition to the Slackbook there are excellent posts pinned at the top of this forum that will give you good insights into our favourite OS. On the install CDs/DVD are readme texts that you can also study to prepare you for installation.
Thanks for the replies. I will check out my "welcome" email and that Slackbook. I already have Slackware installed and running fine. No problems encountered to speak of. I recently installed a bunch of different distros to learn each of their specifics (just for a brain exercise mostly), having been using Debian for years. Slackware was the most straightforward. Slackware's reputation (deserved or not) is more one of "you have know what you're doing to use it". No problem since I've been administering Solaris, SunOS, HPUX, SystemV, and Linux for years (from the command line). So Slackware felt "natural". On the other hand, something like Ubuntu has a beginner-friendly hand-holding reputation. Guess which of the distros gave the most problems at install? Ubuntu. And the easiest? Slackware. Go figure. Debian also installs easily, as does Fedora (mostly), but OpenSuse was a ridiculously molasses-slow install. Ubuntu was in a class of it's own, with failing keyboard, mouse, video problems, etc.
For me, Slackware looks the best, with Debian right there close to it. For my 80 year old parents - well, I gave them Ubuntu. Which works fine after initial struggles to install, and better fits their GUI click-here, click-there mindset. My parents computer was why I was trying out all those "other" distros. I gave them a demo of the various distros and also Windows Vista (yeuch!) and their pick was Ubuntu (probably because of the warm colors and cool sounds more than anything!) My 80 year old mom said "I can't believe we've been using Windows all this time. Linux is so much easier. Vista sucks." It's pretty hard not to laugh out loud when an 80 year old grandma says "sucks"!
Nice to meet you:-) Cool. You're an old hand as a Unix sysadmin! Yes. I also like Debian as it has the beauty of apt-get without the pedestrian, annoying qualities of Ubuntu. I like the net install iso that Debian uses.
Agreed. Slackware has a wonderful, straight forward install routine that I feel comfortable with (very similar to sysinstall in FreeBSD).
e.g., If I don't want sendmail, I could turn off execute permission on /etc/rc.d/rc.sendmail (this is the way Slackware installed by default). This would turn it off for all runlevels. Or, I could leave /etc/rc.sendmail executable and comment out sections of /etc/rd.M, /etc/rc.S, etc. to control it's startup between single user and multiuser runlevels. Or, for even more finer grained control (say between runlevel 3 and runlevel 4 - both being multiuser), I could create SystemV style init scripts under the /etc/rc3.d and /etc/rc4.d subdirectories.
While Slackware allows you pretty much full control, the recommended way to take thing in/out of the boot process is to remove the executable permission on things you want out, and to add the things you want in to rc.local and rc.local_shutdown.
The main reason for not editing rc.M/rc.S etc yourself is that it quickly gets you out of sync with the original packages so upgrading to new versions becomes much more of a hassle. If you have a look in for instance rc.M, it checks for -x on all sub-parts, so taking away execute permission from for instance rc.sendmail ensures that it doesn't start.
if [ -x /etc/rc.d/rc.clamav ]; then
/etc/rc.d/rc.clamav start
fi
if [ -x /etc/rc.d/rc.amavisd ]; then
/etc/rc.d/rc.amavisd start
fi
if [ -x /etc/rc.d/rc.dovecot ]; then
. /etc/rc.d/rc.dovecot start
fi
if [ -x /etc/rc.d/rc.postfix ]; then
. /etc/rc.d/rc.postfix start
fi
and similarly for rc.local:
Code:
if [ -x /etc/rc.d/rc.postfix ]; then
. /etc/rc.d/rc.postfix stop
fi
if [ -x /etc/rc.d/rc.dovecot ]; then
. /etc/rc.d/rc.dovecot stop
fi
if [ -x /etc/rc.d/rc.amavisd ]; then
/etc/rc.d/rc.amavisd stop
fi
if [ -x /etc/rc.d/rc.clamav ]; then
/etc/rc.d/rc.clamav stop
fi
It takes a bit getting used to when coming from the svr4 side of things, but it's very manageable and allows you to leave everything that tends to get changed in an upgradepkg at default, that is - unless you have very special needs...
By following this path you also have a unified approach which I personally find easier to maintain than having some things in BSD-style scripts as per Slackware's default, and others in rc.<runlevel> directories...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.