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."
The choice is "important" in terms of minimising workload / maximising efficiency - the different approaches allow you to do different things more or less easily.
This discussion is not particularly important, the poster was just "curious" - although people may well give useful information to each other as a direct result of its existence...
You want ssh? /etc/rc.d/sshd start /etc/rc.d/rc.httpd start /etc/rc.d/rc.samba start
Apache?
Samba?
Same goes for nfsd, inetd, gpm, cups, bind, acpid, etc...
rc.6 for restart, rc.0 is statically linked to it to make sure they're always the same.
rc.S is called on runlevel 1 by default, as rc.M is called for 3.
On top of that, if you like your System 5 scripts, call rc.sysvinit.
Where exactly is the problem?
If you had bothered to actually look at Gentoo's bootscripts, you would have noticed there is no python. It is all bash based.
The notion of a run-level is a flaw that is fatal, and will lock you in. However, the BSD's never did lock themselves into this notion, and in fact doesn't support init levels except for compatibility. NetBSD doesn't support init 6 for instance, but freebsd does. I think OpenBSD, and Slackware are the only distro's left that use the old BSD way, as NetBSD and FreeBSD now use rcNG (next generation) in their startup. The think is that system startup is linier in nature (aka in line, and in order). The sysV style startup is based on the shell's lexical ordering, which is nice, but is way too simple. You cannot have complex dependancies like scriptA depends on scriptFOO, and scriptFOO might depend on scriptB. Lexical ordering is easy, but too simple. For example the timed might depend on the network to be started before it can contact the stratum servers. So the new BSD startup scripts has a notion of ordering that isn't dependant on lexical alphabet soup. Your script PROVIDES a service, and might REQUIRE another service before it starts, and might need to run BEFORE another service. These keywords can be placed in commenst of yoru startup scripts to control the startup ordering of the services via the program called rcorder, which parses all the startup scripts, and then executes them in order. This the best way to startup because it doesn't depend on a flawed notion of run-levels which plauge the unix history. the only problem is that they do not provide a way to starup sevices in tandem, or to execute an forget orphan services which neither REQUIRE another service to startup, or need to be run before anything else. It would be possible to speed up startup execution if you could have job-control in the startup scripts. Luck for us the shell can do this, but nobody seems to use it. The problem with having complex dependancies is that you remove the simplicity of lexical orderign which seems so intuative. Now you have to edit the scripts to achive the ordering you want, which is cumbersom, and only for a few seconds increase in overall startup speed. And to think that all this is as simply as /sbin/init executing one user land process (a shell script). Certainly when you think of it this way it is simple, but nobody wants to write startup scripts, which is basicly redesigning the wheel.
It isn't a lie if you belive it.
The company I work for end up with a motley crew of turbolinux machines that had daemontools put on them, I did not like it, but some people swear by being able to do a svc -u /service/apache instead of a /etc/init.d/apache start, I guess it comes down to what you are comfortable with, but I've gotten used to /etc/rc.X/S* start|stop|restart from solaris, just pick one and stay with it.
09f911029d74e35bd84156c5635688c0
IBM Dev Pages had an interesting view on this. Althougt it is more for desktop setups (system boots faster - who needs that?). But still it is IMO interesting: Boot Linux Faster.
However, I do like using 'svscan' (DJB) behind the init scripts. Shutdown/restart/etc is simple and logging is handled well.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
an interesting thing with the Mac OS X boot is that all this service starting isn't driven by the init scripts like linux and *BSD. Mac OS X has a 'service' started by the BSD rc scripts, called SystemStarter, that does all the parallel service starting. there are still some services that are started serially, (like NetInfo, after the Mach bootstrap based services, and portmap) however most services are started by SystemStarter.
Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
The second script runs something analagous to daemontools's svscan and runs svdirs, which are obviously superior to init scripts because you do not replicate any code. All of the start/stop/etc handling is done by the process that controls the daemon.
The most obvious benefits are that .pid files are obsolete as it's obvious which process is being run by the system (as it is a child of a runsv process that monitors it) and that services can be started in parallel with dependency handling. Additionally, runit will automatically restart processes that die/crash and handle logging their stderr to rotated logfiles via multilog.
Debian users can apt-get install runit runit-run and experience this themselves. I have run runit as process 0 on my laptop and desktop machines for months and use it on servers to monitor daemon processes, it has worked without a hitch. I highly recommend it (and wish that Debian would provide more runit svdirs for daemon processes :))
/usr/local is for everything that doesn't belong to the base OS. Additional packages, in other words. It's following the FHS standard. Why should it drop third party configuration files into /etc?
Don't blame me, I didn't vote for either of them!
This can sometimes be a problem - when I started my job there were a few machines which hadn't been rebooted in a year or two.
During that time extra services like SSH, rsync, etc, had been installed and they'd been started manually.
When it finally came to the time for the machines to be brought down and restarted then lots of services which had been running for the past few months would be mysteriously missing.
Several times I tracked this down to missing init scripts - and shortly afterwards I made a plan of bringing down each of our machines at least once every six months to make sure that all the startups systems work correctly.
Sure no more uptime pissing contents but I do know that if there is a power outage and the machines go down they will come back up (barring frying!)
Like VMWare, it just *expects* Sys V init, so installing it in Slackware is kinda painful for a newbie.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
Stripped to the bare bones, a minimal RH7.3 installation is 350MB, and you don't even need everything you get. If you choose the "server" class installation, you need 1.3GB just to install. If you claim "it wouldn't look much like RH when (you were) done," why would you start with that much baggage in the first place? I like OBSD for mail servers (among others). You don't have to recompile all the packages just to get them to work the way you need, and it includes what you need to run a server -- mail server, apache, etc. The default installation is lean and sleek at 225MB, and you can do bare bones under 100MB. There are plenty of Linux distributions out there designed with the same idea. Why not use one of those and leave RH to tend their market? If you want to roll your own, why use RH in the first place? BTW, you have static and dynamic linking confused. Static linking builds libs into binaries. Dynamic linking trims executable sizes and uses shared libraries on disk (think DLLs), and is what's giving you problems when you upgrade only parts of your system. Sounds like you have a good start learning Linux, and with a little more experience, you'll be building real servers soon. Best of luck to you.