Slashdot Mirror
Which Style Init Scripts Do You Prefer?
An anonymous reader asks: "I started using Linux years ago, with a Red Hat distribution. When Red Hat's custom configurations started getting in my way, I jumped ship to Slackware. I have never looked back except that I cannot stand the BSD style init scripts. I like having a full compliment of run-levels and control on the fly over which scripts will be running, and which ones will not. That is hard to achieve, when you put multiple configurations in the same file. I also liked having the scripts around to start, stop, and restart services. While I was rewriting my own startup scripts [based on Debian's scripts], I discovered that there is a third style, based on dependencies. AFAIK this is the style adopted by Gentoo. I don't want to start a distro war; but, I am curious about what kind of init scripts Slashdot readers prefer, and what they think are the benefits of each."
Init scripts can serve more purposes than just restarting. You can stop and start services with some init scripts. They are an important part of System Administration no matter how often you reboot.
/^([Ss]ame [Bb]at (time, |channel.)){2}$/
Anyway on to the init. I do sorta like the init system except the use of the stop-start-daemon. Works fine if everything has well but is as a dumb piece of shit when it doesn't. Will happily insist that something is running when it isn't or that it isn't when it is. Have for some services now changed the scripts to stop using that crap anyway.
Have asked this on the gentoo forum but noone so far has given me a reason let alone a good reason why the stop-start-daemon is used at all. Especially for stuff like apache where the gentoo initscript has less options then apachectl has.
Anyway rebooting just to see the init scripts seems a bit, odd. Kinda like saying you like windows crashes because of the cool splash screen. Get a girl :)
But if you ever do an emerge -u portage and then etc-update make sure you know what you are doing. A lot of the updates you can simply do EXCEPT for the files wich you may have changed. Problem is you may have forgotten and then you could really break something. I had it happen once when I accidently overwrote the net configuration. No a smart move on a remote machine. Noticed it only after hosting provided added hardware and then rebooted it as a very secure server (no netaccess).
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
You will pry the Slackware init scripts from my cold dead hands!
/etc, because of RedHat's non-standard installation. Not to mention the mass of files in /etc and all over the hdd that I had NO ideea what their purpose was. At that point I realised that the advantage of rpms was far outweighed by the horrible system management in RedHat. Then I tried pretty much all distros out there, and I finally settled on Slackware for my workstation and laptop as well.
On a more serious note, I had always run Slackware on my gateways (about 6 years total), so I know the scripts pretty much inside and out. I have a lot of very specialised scripts that I wrote from scratch tailored specifically for my gateway and home network. But on my workstation I tried a variety of distribuitons, and for a very long time I ran RedHat (from rh4.2 to rh7.3.), mainly because I enjoyed constantly upgrading rpms and trying out new things.
I ran into the same problem you did around the time RedHad came out with rh8.0. I found it amost impossible to track every config file in
I happen to like the BSD style scripts. They make maintainance a breeze, and they almost never need to be changed. Even when I reinstall Slack (for whatever reason, last time it was a hdd starting to fail), I find that most scripts and config files can just be copied over to the new distro. I actually had a masquarading script that lasted me from kernel 2.0.20 untill 2.4.x was released.
So there you have it, I _love_ the Slack init scripts. I'm not sure there are much better ones out there in terms of simplicity and complete control. Sure, maybe RedHat's linuxconf (is that thing still around?) may make changing stuff and automation easier, but at a significant loss of control. And God forbit you fubar linuxconf's dependencies so you can't run it. Then you'll really appreciate Slackware.
I don't think the lack of "/etc/init.d/daemon stop" is that big a disadvantage. "killall daemon" works just as well - in fact, that's all most stop scripts do. The only thing you lose is the pretty color graphics.
This is definitely prime material for a religious war, though, as neither approach offers any real benefit. You can easily make either approach do whatever you want. With SysV-style scripts, it's slightly easier to let packages say how they should be started; with BSD-style scripts, it's slightly easier to understand the "big picture."
For setup and forget, you can't beat BSD init. Sure, as BSD boxen mostly fall into this category (servers).
Now if you're tinkering with your box, you need something like runlevels and separate start/stop script for every daemon and some more things out there. Either traditional SysV or the new parallel style that's emerging from Gentoo and some other places.
But in the end, you'll most likely stick with what your favourite distro provides.
Though partially a joke, I mean that as a not entirely unserious preference.
/tmp and /var.
And nothing more. I can do all that in about
15 lines, why do I need that scattered over
half as many files?
When I started learning to use Linux, I found the layout of init scripts as one of the single most confusing "features". Once the system makes it up, everything seems so simple as to make you cry when you need to admin a Windows box. You invoke a program, it has a corresponding process, you can kill that process if you want to. Even "special" programs, such as daemons, work that way. Only kernel modules really differ, and even they have a conceptually similar interface - You can insmod, lsmod, and rmmod to start, check, and kill them (if applicable).
But then we come to init scripts... Oy. What runs when? What order? With what permissions? Does script X really run, or just take up space in the rc.d directory? Yeah, I know how to answer all of those questions, and know the default answers for a few different styles, but I don't see the need to have them as questions at all. In many ways, a nice monolithic autoexec.bat-style boot script would, for the vast majority of installations, more than suffice.
On my own systems, I usually go through and remove 99% of the init crap. I want to fsck my disks and then mount them, actvate swap if needed, start dhcpd or set up a static interface, load sshd and perhaps a handful of other daemons depending on the purpose of the machine, and perhaps clean up
On more than one system I control, I have inittab do nothing but rc.local, end of configuration. It works just fine, and anyone capable of using an up-and-running Linux box can tweak its bootup activity just as easily.
I love the new rcNG! All of the benefits of SysV without any of the stupidity. Install CUPS and get this cups.sh script. Just drop into /etc/rc.d and you're done! Actually, freeBSD drops cups.sh into /usr/local/etc/rc.d, which is even better. No need to symlink it to death.
But the "old" way wasn't that archaic. Most people arguing on the SysV side seem to think that BSD init scripts got petrified into a single massive script back in 4.3BSD. Hardly!
Don't blame me, I didn't vote for either of them!
If you regularly have long uptimes you will fall into the trap of just doing things from the command line, but never 'saving' that anywhere. If you dont force yourself to use init scripts, then more often then never you will simply run an obscure - but very important command - and it wont be carried out on the next reboot. If you typed it in a week ago you might remember it, and remember the man page (and possibly even have it in your shells history file). If you typed it in 6mo ago you might have compleatly forgeten it. You might waste 5 minutes relearning it, but you might waste 5 hours too.
A varriation on "laziness is a virtue".
I'm a Gentoo fan, not because of the (mostly imaginary) performance advantages, but because to my taste, it's the easiest Linux to maintain once it's up and running. That's largely from portage, but it's also the only Linux on which I've found the init system to not be an enormous pain in the butt.
The SysV system may well have advantages for knowledgeable admins -- but as a user who just wants ntp to run properly, Gentoo has been a blessing. (Also, I don't believe the Gentoo system uses Python. The parent may be thinking of portage, or I may just be wrong.)
What I'm listening to now on Pandora...
"freeBSD drops cups.sh into /usr/local/etc/rc.d, which is even better. No need to symlink it to death."
/usr/local/ was used for EVERYTHING, hunting down where anything gets installed became a huge task even worse than redhats /opt/. You had to babysit every install just to clean stuff up. Thank God for Debian-- Even sorts the docs for you.
Better? Thats one of the things I hated most about freebsd --
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
Now I know why init scripts are one of the major dark areas remaining in my understanding of BSD and Linux: the entire subject area is flamebait.
I think there's a conceptual problem here. Whether a topic is flamebait or not does not stem from the topic, but the audience for the topic.
If my wife asks me "why are you angry?" and I respond "that's flamebait" does that reflect badly on me or my wife?
Probably more to the point, the reason this topic is flamebait is that init scripts are one of the great embarrassments of the BSD/Linux universe. It strikes me that the most passionate arguments occur around the most embarrassing features. In order to hide our embarrassment, we profess love.
Personally, I haven't seen an init script yet that if made human wouldn't show up at a Trek convention dressed as Wesley Crusher.
Gentoo supports arbitrary runlevels.
/etc/runlevels. Use "rc-update add <service> <new runlevel>".
/etc/conf.d/rc.
For example, on my laptop I have boot, default, net, and X. Boot and default are the ones that come with Gentoo's base installation, and they have things like filesystem check, loading modules, hotplug, etc. Net loads PCMCIA modules and the driver for the wireless card, and I start it only if I actually have the card plugged in. X loads the sound drivers, video card modules, and xdm.
Setup: make a directory with the runlevel name in
Use: "rc <new runlevel>".
I'm not an old hand at this UNIX/BSD stuff like most people here seem to be, but I can't think of anything else I'd like from an init system.
P.S.- Gentoo supports parallel startup, too. It's a flag in
Well, there is http://www.linuxbase.org. And as for apt putting things in /usr, this goes back to what you call my *troll* about old software. It might be a troll if it weren't true. And yes, you can get 3rd party .deb packages with *some* newer software, and if you install these, they all go in /usr and can cause conflicts with stuff that *is* in the base system. I've had first hand experience with this.
But whatever, I guess we can agree that the BSD layout *isn't* confusing after all. Neither is debians of course. There is no point in arguing which layout is better since I'm sure we are both very much happy with our respective fav. systems.
Have fun using Debian, and I'll stick with BSD where I have a choice.