Which Style Init Scripts Do You Prefer? 123
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."
FreeBSD 5's RCng (Score:5, Interesting)
It combines, in my opinion, the best of both worlds:
1. Full control over each service through scripts in
2. Dependency-graphs determine service start order. Each file contains a special header declaring its dependencies and what it provides; the system analyzes these on boot, or when you request that a specific service be started, and handles the dependencies for you.
Mmm, tasty.
(And yes, this is quite similar to Gentoo's system, except that Gentoo translates the scripts into actual runlevels behind the scenes, whereas the BSDs do not. That, and this doesn't use python.)
Re:FreeBSD 5's RCng (Score:2)
>RCng (also available in NetBSD, and possibly
>OpenBSD).
Actually, this is a netbsd invention. It's also implemented in Gentoo, albeit as a hack on top of the standard init.
works pretty good, imho.
Re:FreeBSD 5's RCng (Score:2)
Re:FreeBSD 5's RCng (Score:1)
'Yeah! another Distro War... (insert name of distro) rules! I 0\/\/|/| y0u |-|4x0R'
as for witch init script you use... who care! as long as you know waht you are doing or there is good documentation (or a bit or both)
it's kind of a tradeoff: usability or power... usability comes with limits on what you can change
Ok, so i did drink a little tonight and i AM a bit drunk,
Re:FreeBSD 5's RCng (Score:3, Insightful)
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!
Re:FreeBSD 5's RCng (Score:2, Insightful)
Better? Thats one of the things I hated most about freebsd --
Re:FreeBSD 5's RCng (Score:3, Informative)
Re:FreeBSD 5's RCng (Score:1)
So first you say that
BSD layout is simple,
Re:FreeBSD 5's RCng (Score:1)
I don't know what the official filesystem definition of
Re:FreeBSD 5's RCng (Score:2)
So now you're mixing up programs that are part of the OS, and third-party programs that are under package management.
If you want /usr/local to be exclusively for non-package-managed software that you install yourself, then you should be putting package-managed software in a third place, like /opt, not /usr. This is trivial to do with FreeBSD's Ports Collection.
Re:FreeBSD 5's RCng (Score:2)
For me,
Re:FreeBSD 5's RCng (Score:2, Insightful)
But whatever, I guess we can agree that the BSD layout *isn't* confusing after all. Neither is debians
Re:FreeBSD 5's RCng (Score:2)
Re:FreeBSD 5's RCng (Score:2)
In any case, agreed to disagree.
Re:FreeBSD 5's RCng (Score:4, Insightful)
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.)
lukem of netbsd invented it (Score:3, Interesting)
Mac OS X (Score:4, Interesting)
An article describing a similar concept for Linux can be seen at IBM DeveloperWorks [ibm.com].
Sounds like that may be what Gentoo does?
Re:Mac OS X (Score:3, Informative)
My init scripts (Score:3, Interesting)
Re:My init scripts (Score:1, Insightful)
Two things I hate about gentoo and on topic. (Score:4, Insightful)
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).
Re:Two things I hate about gentoo and on topic. (Score:1)
Hence, the diff output showing the difference between old and new. But you're right, it's the crappiest part of Gentoo, and it's a mistake everyone makes once (myself included). I think they're working on a better solution to this...
Re:Two things I hate about gentoo and on topic. (Score:3, Insightful)
Just look at the diffs - it's pretty obvious then that something is machine-specific. (even better, when changing something in /etc, just add a comment right above your change
fstab (Score:2)
Obviously, the more technical people can recommend something better, but the point should be clear.
As for 2 tabs or whatever, I agree. I hate having to see a diff of 2 files that have no significant changes. They smarttened up a bit by automatically merging comments. I think that people should be shot when they just spacing because it wastes everybody's time.
A cool option would be to aut
I usually preview, but apparently not this time. (Score:2)
Re:I usually preview, but apparently not this time (Score:2)
Thanks! [nt] (Score:1)
init scripts are ESPECIALLY important (Score:4, Insightful)
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".
Re:My init scripts (Score:2, Informative)
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 pla
Re:My init scripts (Score:2)
A month? You're not even getting close to full bragging rights. I have one friend who lamented haveing to reboot his Sun after 3 years of uptime (had to flick a dip switch), and another spitting fire because someone at his colo provider f*cked up with the UPS system just about the time his box was set to bread one year of uptime.
Netcraft notes [netcraft.com] that Linux (among others) has this minor
Re:My init scripts (Score:2)
Re:My init scripts (Score:2)
I dual boot my main box once in a while to play a W
Re:My init scripts (Score:2)
That's because BSD/OS has about the same stability as Linux, but doesn't wrap it's uptime counter at 490 days. If Linux's counter didn't wrap, then I'd expect you to see a mix of BSD and Linux in the top 50. The Cable & Wireless 'linux' boxes 1000+ days uptime are most probably BSD boxes behind a Linux firewall, or something of that nature.
(they have notes on how their OS guesses can som
Re:My init scripts (Score:2)
rc-update (add|del) (service) default
rc
Have fun.
Grump (Score:3, Funny)
BSD all the way! (Score:2)
I like staying close to the metal on my machine. /etc/rc.local has my customization, other stuff is run manually from ~root/.bash_history. I don't like layers, and hence `linuxconf` is beneath contempt.
Re:BSD all the way! (Score:2)
Well, considering I work daily on Solaris and Linux, it's really never been a question. Obviously Sys V init scripts are much easier to work with since Solaris uses them (and 90% of my admin work is Solaris).
On the handful of machines that I work with that are BSD based, I've always found it VERY awkward to restart services. With s
Re:BSD all the way! (Score:2)
Red Hat systems, and probably other SysV based distros have a service command.
service foo stop/start/restart/status
I also find it amusing how everyone using BSD initscripts seems to think a mess of symlinks is a bad thing, and that there's no easy way to manage them.
chkconfig --list foo
chkconfig -
Slackware's init (Score:5, Insightful)
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.
Re:Slackware's init (Score:1)
I cut my teeth on Solaris' sysV-stylee scripts so because I'm used to them, they don't bother me.
As to RedHat - in 8.0 and higher, the official way to manage startup scripts (I believe) is using chkconfig. chkconfig is great, even tho I think it was stolen from IRIX.
It lets you add/delete startup scripts into the sequence, muck with the order (by editing the script I think tho) and other bits and bobs. Very nice - I think it's great, and it saves a lot of symlink-wrangling.
The NetBSD/F
Re:Slackware's init (Score:2)
Patrick V., if you're reading... pleeeease?
Re:Slackware's init (Score:3, Insightful)
I know its scripts inside out too, altho I just use joe and delete entire swaths of scripts I'll not need like quotas, RCS, dos ums etc. Usually I follow that with a new kernel compile to finish things up and have a real personal server.
I know them really well, but I cant really say I 'lik
Re:Slackware's init (Score:3, Insightful)
Re:Slackware's init (Score:2, Informative)
Re:Slackware's init (Score:1)
to maintain.
Slack's scripts are fine... (Score:3, Informative)
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?
Re:Slack's scripts are fine... (Score:1)
I have used linux for 7 years now (mainly slackware and mandrake) and there is nothing wrong with any of the scripts IMO.
Re:Slack's scripts are fine... (Score:2, Interesting)
True. And IIRC many of these are either new standard packages or were removed from rc.inet[12] starting with Slackware 9.0 (so the original question is somewhat moot). However, there are still s
BSD-style (Score:5, Insightful)
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."
Well, that's not exactly a good way... (Score:2)
You stick dbshut inside
If you want a controlled way to free resources which isn't handled by just sending a signal to a daemon, then it's nice to have a script that can handle it, and a procedure to call it.
Plus it's also nice to link in a K99final script into rc0.d that does something like unlock all tapes in a carousel, send a message to a router or load balancer or whatever.
Re:BSD-style (Score:2)
BSD sysv mix.... (Score:2)
Having written my own init scripts and played with BSD, the one thing I miss in BSD is he ability to switch run levels. SysV is a bit much with run levels from 0 to 6. I'd like 3 run levels. single user, multi user, multi with X. I don't really think that the need for 0 and 6 is really there. Instead of saying init 0 or init 6 why not just say reboot or shutdown and skip the init sequence. That is about all I ever use. BSD has boot -s and multi, so if they were to adopt o
Re:BSD sysv mix.... (Score:2)
Re:BSD sysv mix.... (Score:2)
The distinction between single-user and multi-user is all I seem to need (by the way: your posting could be read as if BSD would require a reboot to go single-user. It doesn't, you can use 'init 1' or 'kill -TERM 1'). I don't use xdm or some such however, that might have something to do with that.
Gentoo's bootscripts do not use Python. (Score:2, Informative)
Re:Gentoo's bootscripts do not use Python. (Score:2)
the BSD style changed (Score:5, Informative)
Re:the BSD style changed (Score:1)
To begin the discussion on the for side, here's one benefit to runlevels. You can specify which services are to be running at each runlevel: single, multi console, multi windowsystem, etc. The behavior is documented in a well known way, not a pile of custom scripts. So this is a benefit and a convenience.
Re:the BSD style changed (Score:2)
For the life of me, I can't think of anytime I needed something other than single user or multiuser. (I'm not counting halt or reboot as runlevels). For example, all multiuser X gives you is xdm, so why not just start xdm from ttys if you want it?
Or to put it another way, why are the three to five runlevels all that you need? If they're so useful, why not have fif
Re:the BSD style changed (Score:2)
> So this is a benefit and a convenience.
Same is true for the NetBSD way and even more so. Especially if you have to write your own startup scripts and feed it into the startup procedure.
You have something called 'myservice', that must be started when the network is up, after the start of somedaemon but before xdm?
Nothing simplier than that, just put special comments like this:
# REQUIRE: NETWORKING somedaemon
# BEFORE: xd
Re:the BSD style changed (Score:2)
Gentoo +++ (Score:1, Troll)
Re:Gentoo +++ (Score:2)
Actually, in this case I think he is right! I'm not a Gentoo-zealot, Gentoo has a lot of bad sides, but its init-system is really friggin' great! How many of you people who are praising BSD or SysV-init style have actually TRIED Gentoo's SysV-inspired dependancy-based init? Because it is based on dependancies instead of a hardcoded order it can start services in parallell, really reducing s
First impression (Score:4, Informative)
I really don't care, but. (Score:2)
BSD style seems a little more work, for no more gain.
Maybe yet another style... (Score:2, Informative)
depends ... (Score:2, Insightful)
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.
Red hat not too bad, once you get used to it. (Score:2)
One thing I've disliked about BSD style startup is that while there is a lot of potential, a busy admin is all-too-likely to just pop one more line in rc.local and call it good.
It's nice not to have to recall every bizarre syntax for daemon restarts -- lets see, is it
Re:Red hat not too bad, once you get used to it. (Score:2)
Re:Red hat not too bad, once you get used to it. (Score:1)
MS-DOS autoexec.bat, baby! (Score:3, Insightful)
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.
BSD (Score:1)
Re:BSD (Score:2)
roll your own... (Score:2)
Hell, I remember a great approach to starting/init'ing services using Makefiles a few months back. The article can be found here:
http://lwn.net/Articles/50115/ [lwn.net]
That article inspired me to create my own binary that gets called from init. My binary is basically just a static series of system() calls. I chose these over exec() because they require one less call to sh.
Long story short - using a Makefile or a simple C binary can allow you
Daemontools svscan/supervise (Score:1)
For a short time I as applying this system to as much of the system as possible. It was very nice but it was alot of work so I've not used it recently except for qmail and friends.
Slackware's bsd-style init scripts were also good.
Don't care, don't reboot enough... (Score:3, Informative)
Re:Don't care, don't reboot enough... (Score:1)
--
Phil
From Slack to Gentoo (Score:1)
I moved to Gentoo for the package management. I really miss the simplicity of Slackware's init scripts. Maybe it is just because I used it for years, but they are really easy and simple. However, I mostly only use one runlevel on my laptop (and who cares about init scripts on my servers since they never get rebooted).
I heard portage is getting ported to Slackware. I may have to go back to slackware.
Re:From Slack to Gentoo (Score:2)
Re:From Slack to Gentoo (Score:2)
Re:From Slack to Gentoo (Score:2)
Gentoo does have one problem. It'll make very easy to drive on the bleeding edge of libs/apps. Stay on the bleeding edge too long, and you'll see system breakage -- probabilities don't lie. My last one was on an upgrade from
Re:From Slack to Gentoo (Score:2)
They both suck... (Score:2)
A good system would explicitly know about dependencies, and would then concurrently start/stop everything for which the dependencies are already satisfied. That's what multi-tasking is for. Each time a daemon reports a successful start, all the other services whose dependencies are satisfied by it, would immediately be concurrently launched.
Problem is, no distribution s
Re:They both suck... (Score:2)
You've just described Gentoo's init system, which builds a dependency graph, and can be configured to start/stop services concurrently (although that's not the defa
Re:They both suck... (Score:2)
Gentoo's one of the few distro's I've never taken a look at. Mybe it's time for me to take a closer look.
Why? (Score:1)
Runit: the ONLY sane solution (Score:3, Informative)
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 :))
Re:Runit: the ONLY sane solution (Score:2)
Re:Runit: the ONLY sane solution (Score:2)
Slackware Conversion (Score:1)
There are a couple of init styles associated with Slackware's booting. . . The basic, and most prominent laying around are the rc.d startup scripts. Slackware also has a directory in /etc/rc.d/ where you can put all your init.d scripts. It is actually an extremely easy conversion if you want to do it.
Flaw in SysV Init Scripts (Score:4, Interesting)
flamebait (Score:3, Insightful)
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 emba
sysV or BSD? Who knows. As long as it works. (Score:2, Interesting)
When I picked up Linux (RedHat 6.0), I felt like I knew what I was looking at because it was similar. After that, I stalled with the RedHat upgrade cycle at 7.3 because it worked and worked well.
Finally I had to
Re:sysV or BSD? Who knows. As long as it works. (Score:2, Insightful)
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
SSS - the fast init script engine (Score:2, Interesting)
ftp://atrey.karlin.mff.cuni.cz/pub/local/mj/linux/ sss-0.0.1.tar.gz [mff.cuni.cz]
It's easily configurable, as everything is kept in a single, hierarchicaly structured config file.
It's very convenient to use, since you can bring up whole subtrees of services up and down with a single command.
And it's damn FAST, allowing to boot my system under three seconds from LILO to running WindowMaker desktop. It achieves that by reading just the single con
Closed source stuff expecting Sys V init (Score:3, Informative)
Good Thing (Score:2)
A couple interesting approaches... (Score:1, Interesting)
The first one I really like is OpenBSD. Their boot scripts are the most straightforward. It's all just a very simple shell script. I also like the idea of
However, customizing those scripts could be a pain.
The other example I really like has been well articulated by Richard Gooch, creator of Linux devfs (now labelled a failed experiment by kernel hackers). You can read about what Richard has
Start, stop, and restart services (Score:2)
Re:Sounds like a lot of trouble (Score:2, Informative)
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...