Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Operating Systems Software Unix IT Technology

Which Style Init Scripts Do You Prefer? 123

Posted by Cliff from the handling-your-services dept.
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."
This discussion has been archived. No new comments can be posted.

Which Style Init Scripts Do You Prefer? More

Which Style Init Scripts Do You Prefer?

Comments Filter:

  • FreeBSD 5's RCng (Score:5, Interesting)

    by cbiffle ( 211614 ) on Thursday February 05, 2004 @08:45PM (#8196567)
    You might want to take a gander at FreeBSD 5's RCng (also available in NetBSD, and possibly OpenBSD).

    It combines, in my opinion, the best of both worlds:
    1. Full control over each service through scripts in /etc/rc.d. Want to restart your sshd? /etc/rc.d/sshd restart. Very similar to init.d.
    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.)
    • >You might want to take a gander at FreeBSD 5's
      >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.
      • A hack? Like its really a complex subject to recursively traverse dependencies. I myself vote for Gentoo on this, btw. The init scripts are quite elegant, and they just work.
    • You know, i imagined the first post would be more like:

      '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 ...fine grain power comes with having full access, but having to do everything...

      Ok, so i did drink a little tonight and i AM a bit drunk,
    • 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!
      • "freeBSD drops cups.sh into /usr/local/etc/rc.d, which is even better. No need to symlink it to death."

        Better? Thats one of the things I hated most about freebsd -- /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.

        • Re:FreeBSD 5's RCng (Score:3, Informative)

          by Brandybuck ( 704397 )
          /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?
        • /usr/local/ was used for EVERYTHING, hunting down where anything gets installed became a huge task even worse than redhats /opt/.

          So first you say that /usr/local is used for EVERYTHING, then complain you don't know where ANYTHING is? Well, hmm, maybe it's in... /usr/local? Nah. Too simple. Docs? How about /usr/local/share/docs (or something similar).

          BSD layout is simple, /usr/ for SYSTEM stuff, ie anything not in ports, /usr/local/ for everything else. And I use Debian at work (not by choice, I like sof
          • Yeah, and "I like software that isn't 3 years old" as an argument against Debian is a better troll.

            I don't know what the official filesystem definition of /usr/local is, but I use it for anything I personally install. Everything managed by the package manager goes into /usr, and everything I bring in and compile goes to /usr/local. That makes sense to me.

            • Everything managed by the package manager goes into /usr, and everything I bring in and compile goes to /usr/local. That makes sense to me.

              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.

              • I guess this boils down to BSD being a true "system" whereas Linux is really just a kernel which is usually distributed with GNU tools. There's no accepted definition of what constitutes a "base" Linux system. Is it whatever was installed? Whatever it takes to be POSIX-compliant? Whatever some consortium of distributors says?

                For me, /usr/local is stuff I can't just apt-get back after a crash.

                • Re:FreeBSD 5's RCng (Score:2, Insightful)

                  by merdark ( 550117 )
                  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

    • Re:FreeBSD 5's RCng (Score:4, Insightful)

      by Otter ( 3800 ) on Thursday February 05, 2004 @11:48PM (#8197941) Journal
      (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.)

      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.)

    • and here's a good overview of it with more technical links [netbsd.org]. it is my favorite setup by far, and i'm very glad to see fbsd5 and gentoo adopting its style.

  • Mac OS X (Score:4, Interesting)

    by Tor ( 2685 ) on Thursday February 05, 2004 @08:52PM (#8196651) Homepage
    Mac OS X does what I have long wanted to see in a UNIX system, parallell/dependent startup. For instance, "vtun" depends on "tunnel.kext" and "networking", but both "tunnel.kext" and "networking" can be started simultaneously. Also, the "StartupParameters.plist" meta-information file has some parameters related to order preference ("early", "late", and so on).

    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)

      by Hes Nikke ( 237581 )
      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.

  • My init scripts (Score:3, Interesting)

    by Kethinov ( 636034 ) on Thursday February 05, 2004 @08:52PM (#8196653) Homepage Journal
    Init scripts concern my very little because I almost never reboot. For the record, I use Gentoo and they seem to work fine, but my Gentoo box is nearing a month of uptime. I only rebooted it because I recompiled the kernel. Maybe I should reboot now just to watch the init scripts for fun...
    • 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.

    • Two things I hate about gentoo and on topic. (Score:4, Insightful)

      by SmallFurryCreature ( 593017 ) on Thursday February 05, 2004 @09:03PM (#8196795) Journal
      One is that on every emerge portage a number of configurations changes are made that are pointless. Like a change of the number of spaces in /etc/fstab. 1. who cares if there are two or three tabs between options? 2. /etc/fstab will always be different for the user anyway since the default one has nonsense values.

      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).

      • Problem is you may have forgotten and then you could really break something.

        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...

      • 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.

        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

      • I totally agree with you here. The very least that they should offer is: /dev/hda1 /boot /dev/hda2 swap /dev/hda3 /root

        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
    • It forces you to save your configuration. And being forced to save your configuration might get you to think about it in an orderd and structured way before you do so. If you reboot every other day then you will catch (or resolve) these problems when they are still fresh in your mind.

      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)

      by stevey ( 64018 )

      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

    • Init scripts concern my very little because I almost never reboot. .... my Gentoo box is nearing a month of uptime.

      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

      • It's called power outages due to crappy weather for which we get a lot of in Kansas. Not to mention the fact that since I'm a college student, my computers get shuttled around a lot between my house and my parents' house. >2 months of uptime is extremely difficult with such a lifestyle.
        • So, other than power cycling (due to either weather or moving), your machine 'almost never reboots'... Still, in the Unix world rebooting every 2 monts or so still doesn't qualify as 'rarely'.. This differs greatly from the Windows world, where powering off every time you get up to go for coffee isn't entirely unheard of. Once you get stable (and perhaps buy yourself a UPS), you'll probably find that going 6 months without a reboot isn't at all strange.

          I dual boot my main box once in a while to play a W


    • rc-update (add|del) (service) default
      rc

      Have fun.

  • Grump (Score:3, Funny)

    by NanoGator ( 522640 ) on Thursday February 05, 2004 @09:06PM (#8196832) Homepage Journal
    I think I'm going to upgrade to BOOT.ini.
  • This is a bit of a religious war, but I'll bite at the flamebait. I cannot abide Sys-V mess'o'symlinks, one reason I stay with Slackware, one of the only BSD-style distros.

    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.

    • This is a bit of a religious war, but I'll bite at the flamebait. I cannot abide Sys-V mess'o'symlinks, one reason I stay with Slackware, one of the only BSD-style distros.

      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

      • With sysv, it's just natural to type /etc/init.d/whatever restart or /etc/init.d/whatever stop && /etc/init.d/whatever start. I suppose BSD has ways to do this, but sysv's way is more elegant IMHO.

        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)

    by c.r.o.c.o ( 123083 ) on Thursday February 05, 2004 @09:16PM (#8196923)
    You will pry the Slackware init scripts from my cold dead hands!

    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 /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.

    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.
    • Couple of thoughts:

      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
    • Slackware rc.d dittoes. The only improvement I would make is to include a shutdown-time equivalent of rc.local. I named mine rc.local.6, and I just call it from rc.6.

      Patrick V., if you're reading... pleeeease?

    • Re:Slackware's init (Score:3, Insightful)

      by mnmn ( 145599 )
      I cut MY teeth on slackware. We ordered 3 CDs from infomagic, a debian, a slackware and redhat and we split it among 3 friends. Slackware was the one I could install the fastest before even learning anything about Linux.

      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)

      by macdaddy ( 38372 )
      I've been using RH for a long time now. Frankly if someone asked me to build them a rock solid mail server today I'd build it on a RH 7.3 installation. Granted it wouldn't much look like RH when I was done but that would be my foundation. I have RH 9 on my newest server and I can't stand it. Don't get me wrong, I love RH-style init scripts. I write and submit init scripts all the time for packages I use that don't already have them. It's easy and yet powerful. I don't really give a hoot about dependa
      • 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 s
    • I actually went slackware one better and replaced all the scripts with one rc script that took a single argument to describe the runlevel. That way everything ended up in one file. It was a breeze
      to maintain.

  • Slack's scripts are fine... (Score:3, Informative)

    by damien_kane ( 519267 ) on Thursday February 05, 2004 @09:16PM (#8196924)
    You want ssh? /etc/rc.d/sshd start
    Apache? /etc/rc.d/rc.httpd start
    Samba? /etc/rc.d/rc.samba start
    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?
    • There's nothing wrong with any of the scripts.
      I have used linux for 7 years now (mainly slackware and mandrake) and there is nothing wrong with any of the scripts IMO.

    • You want ssh? /etc/rc.d/sshd start
      Apache? /etc/rc.d/rc.httpd start
      Samba? /etc/rc.d/rc.samba start
      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.

      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)

    by ctr2sprt ( 574731 ) on Thursday February 05, 2004 @09:16PM (#8196928)
    The thing I like most about BSD-style scripts is that they don't insist on starting and killing daemons one at a time. They also allow for asymmetric scripts, sort of; Linux tends to kill every service individually on shutdown, which is really annoying because it takes forever. 99.9% of programs can handle kill -TERM -1 && sleep 5 && kill -KILL -1, which init does automatically when it changes runlevels. I guess it's nothing inherent in SysV-style scripts I dislike; it's the way they're used.

    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."

    • to shut down oracle.

      You stick dbshut inside /etc/init.d/oracle 's stop) section.

      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.

    • "killall daemon" works just as well - in fact, that's all most stop scripts do
      Just make sure you don't transfer your script to Solaris, or unexpected results will occur. Hint: under Solaris, killall does exactly what it says on the tin; it kills all processes. Since Solaris 7, it's provided pkill for the same (if not greater) functionality as killall under linux etc.
  • Ideally there would be a mix.

    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

    • Single-user in Linux usually isn't, so there's a pseudo-runlevel that doesn't touch the init scripts at all. If memory serves, it's boot -e[mergency]. What a mess. Linux is a little too eager to depart from Unix tradition at times.
    • Interesting. I started with Linux, and mostly switched to BSD (first Open, now Free) about 2 years ago. Come to think of it, I never missed runlevels, and didn't even use them on Linux anyway.

      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.

  • 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 BSD style changed (Score:5, Informative)

    by JDizzy ( 85499 ) on Thursday February 05, 2004 @09:24PM (#8196974) Homepage Journal
    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.
    • Okay, so all the BSD guys are bashing runlevels. What's wrong with runlevels, exactly?

      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.
      • You really haven't stated why runlevels are useful. I wouldn't need to specify which services run in which runlevel, if I didn't have runlevels.

        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
      • > The behavior is documented in a well known way, not a pile of custom scripts
        > 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

  • Gentoo +++ (Score:1, Troll)

    by n1ywb ( 555767 )
    I love Gentoo's system. It's everything an RC system should be and more. Everything else is antiquated junk IMO.

  • First impression (Score:4, Informative)

    by bofkentucky ( 555107 ) <bofkentucky.gmail@com> on Thursday February 05, 2004 @09:37PM (#8197095) Homepage Journal
    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.
  • Its nice to have /etc/inittab for some workstations, but I could easily configure it in both styles. The only really annoying thing, different directories for startup scripts. I like /etc/init.d, so I have to symlink on some systems, just easier that way.

    BSD style seems a little more work, for no more gain.

  • 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 [ibm.com].

  • depends ... (Score:2, Insightful)

    by Pegasus ( 13291 )
    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.
  • I've got to say that I've gotten used to the "Red Hat Style" startup, especially in the past couple of years where you have an /etc/init.d/ directory to do things like /etc/init.d/httpd restart or whatever.

    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 /usr/local/ndc restart, or was it k

  • MS-DOS autoexec.bat, baby! (Score:3, Insightful)

    by pla ( 258480 ) on Thursday February 05, 2004 @10:22PM (#8197382) Journal
    Though partially a joke, I mean that as a not entirely unserious preference.

    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 /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?

    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)

    by antizeus ( 47491 )
    I started with Slackware, which primarily uses BSD style scripts. Therefore it is more natural for me. The other way, conversely, seems unnatural.
  • If you're that worried about startup, why not roll your own scripts?

    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
  • I've never really used runlevels at all, so I don't care much about that. What I do like is DJB's /service setup. It's easy to control daemons with the svc command, and if they ever crash they'll automatically be restarted.
    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)

    by rthille ( 8526 ) <web-slashdot@ran g a t .org> on Thursday February 05, 2004 @10:29PM (#8197441) Homepage Journal
    However, I do like using 'svscan' (DJB) behind the init scripts. Shutdown/restart/etc is simple and logging is handled well.
  • I switched to Gentoo from Slackware a few months ago (I had been a slackware user for years).
    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.
    • This is getting OT but how do you like Gentoo? I'm downloading the ISOs as we speak. I've been a RH user forever but I'm sick to death of RH9 and looking for something better. Is portage all it's cracked up to be? I compile all my daemons and most of my power tools by hand. I rarely use a RPM for anything anymore. Being able to upgrade a library and any library that depends on it at the drop of a hat would be ubber nice. I canned RH's sasl RPMs the other day and rolled my own only to find out that Rh
      • Sounds like you'll like Gentoo. You won't need to compile anything by hand anymore, but if you insist on doing so, portage provides the emerge --inject command, which tells it that a package you installed yourself is on the system and should not be considered an unsatisfied dependency.
      • From your description, I guess you'll like Gentoo. Take the time to go through the docs (very good quality documentation), namely the USE variable configuration. You should be able to have portage compile all but the most exquisite packages for you, configured just the way you want it.

        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

  • ... because they both (as typically implemented, anyway) start/stop each servide one at a time. Way too much unnecessary serialization!

    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

    • 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.

      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

  • I don't have real intimate knowledge of startup scripts, but I get along with them well enough (having written a few myself), and I just don't see what the huge fuss is about. After all, your system boots once, and once it's up then it's up. Being nice and flexible as *nix is, you can tweak system services to your heart's content while the thing is live; you wouldn't have to reboot for anything save kernel changes. Just make sure your system is configured to boot the way you want it most of the time and

  • Runit: the ONLY sane solution (Score:3, Informative)

    by OdinHuntr ( 109972 ) <ebourgNO@SPAMpo-box.mcgill.ca> on Thursday February 05, 2004 @11:17PM (#8197773)
    runit [smarden.org] operates like DJB's daemontools but is tailored to run as process 0 in a unix system. Its operation consists of three scripts: one which starts the system, one which is alive for the duration of the system's uptime, and a third which handles shutdown.

    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 :))

  • 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)

    by edward.virtually@pob ( 6854 ) on Friday February 06, 2004 @12:20AM (#8198164)
    As other(s) have noted, this article is flamebait. My personal preference is BSD style. Beyond that, the only serious problem I've encountered with the SysV style is what happens if the "stop" case in a given script is flawed -- if it fails to exit, as in the case of trying to stop a program that is wedged due to failed hardware (i.e.: why you're trying to shutdown in the first place), the shutdown will hang at that point and you will be forced to reboot via the reset or power switches. This can result in serious data loss and is a failure in the SysV init design. This issue may have been addressed by now. Ideally, init should timeout if a given script takes "too long" and move on to the next one. Of course, this brings up the question of how long is too long and where you would set this, etc. Anyway, you asked.

    • flamebait (Score:3, Insightful)

      by epine ( 68316 )

      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
  • IIRC, sysV has all these /etc/rc.?/ directories (corresponding to run levels) with a whole lot of S??foo and K??bar symlinks going back to /etc/rc.d/foo and /etc/rc.d/bar. I remember thinking, hey that's kind of a neat way to do things. That was when I was learning UNIX (Digital/Compaq Tru*64).

    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
    • Gentoo supports arbitrary runlevels.

      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 /etc/runlevels. Use "rc-update add
  • Well, for init scripts, I'm using the 'sss' program for quite a while:

    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)

    by Xpilot ( 117961 ) on Friday February 06, 2004 @11:47AM (#8201668) Homepage
    Like VMWare, it just *expects* Sys V init, so installing it in Slackware is kinda painful for a newbie.
  • It's a good thing you didn't put this in apple /., because by now otherwise you'd have everyone telling you their favourite was AppleScript.

  • A couple interesting approaches... (Score:1, Interesting)

    by Anonymous Coward
    The two ways that impress me the most are exact opposites: one is simple, and one is complicated.

    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 /etc/rc.conf.

    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
  • I also liked having the scripts around to start, stop, and restart services.
    Slackware does have scripts to start/stop/restart most services, in /etc/rc.d. For example, to restart gpm run `/etc/rc.d/rc.gpm restart`.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close