TheOldFellow theoldfellow at
Sat Feb 17 10:26:54 PST 2007

Jorge Almeida wrote:
> On Sat, 17 Feb 2007, TheOldFellow wrote:
>> Jorge Almeida wrote:
>>> I'm trying to understand how to use runit as substitute for sysvinit.
>> What I now do is to build LFS or CLFS according to the book, but omiting
>> sysvinit and syslog.  I even install the bootscripts!  Then I install
> I think that's the approach of Debian, judging from the contents of the
> runit package (I don't have a debian system, and I don't have any
> experience with debian).

I tried to write my own, but in the end the LFS scripts were well
researched, so I used those.

>> runit mostly into /sbin and /usr/sbin - I don't bother with dietlibc any
> For some special reason? I compiled runit against dietlibc with no
> problems.

No reason other than it's another step. and another package.

>> more.  My /etc/runit/1 script is just a list of calls to the LFS
>> bootscripts:

> Yes, this is much cleaner than the sysvinit stuff...
> I suppose this is the place to add other one-time tasks (ulogd,
> shorewall, hdparm...)
> BTW, what if some of these scripts fails?
> And what about /etc/init.d/kerneld start and /etc/init.d/rmnologin ?
> (, Step 5)

LFS doesn't have those scripts AFAIK.  I look at tasks as either
Initialisation, or Service.  I don't, for instance, run network, since I
treat an IP port as a service, so it gets a service script, that way I
can take a link down when I want to.  Satring loggers should be a
service too, I use socklog.  Hdparm, is initialisation since you're
setting the hardware up, I think.

If a script fails, then it runs through, I did try to trap these once,
but in the end I decided that since I was going to have to fix it, I'd
rather have the machine up than down.

> One question: my current distro (gentoo) forces a fs check after so many
> days or so many mounts, which seems a prudent idea. Should I try to
> adapt the corresponding gentoo checkfs script?

The LFS checkfs script does that.

>> The /etc/runit/3 script is similar, but with 'stop', and only for those
>> scripts that have something in the stop branch of the case.
> One question regarding stage 2: some services just insist on going to
> the background and refuse to write to STDOUT (can't think of an example
> right now, but I'm sure they're out there). What do you do in such
> cases? Dump them to stage 1?

I never dump them into stage 1.  Everything that I've wanted to run as a
service I've found a way round.  If it insists on backgrounding , there
is usually a way of using a finish script to stop it.  Give me a
specific example and I'll see how I'd do it.


More information about the lfs-support mailing list