theoldfellow at gmail.com
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
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
> 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 ?
> (http://smarden.org/runit/replaceinit.html, 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