jalmeida at math.ist.utl.pt
Sat Feb 17 11:49:22 PST 2007
On Sat, 17 Feb 2007, TheOldFellow wrote:
>> I suppose this is the place to add other one-time tasks (ulogd,
>> shorewall, hdparm...)
Actually, ulogd is a service, whereas shorewall is an initialization
task. This means that for some time the kernel messages are lost. Is
this harmless? Is it worth the trouble of cooking up some workaround?
(Like starting shorewall at stage 2, via some sort of fake service?)
Of course, assuming that network starts only at stage 2 (as you do),
there are no kernel messages to log. I suppose that the firewall can be
started before the network is up. Is this right?
>> 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
Indeed, they are not in /etc/rc.d/init.d. From what I got by googling,
a file /etc/nologin is created (at least in Debian) in the beginning of
the initialization process to avoid loging in before the initialization
is done (I suppose rmnologin takes care of removing the file
afterwards?). Since xdm and gettys only appear on stage 2, I suppose
there's no need for rmnologin (but what about LFS with sysvinit?)
kerneld seems to be obsolete as of many kernels ago. Maybe the runit
package wasn't updated?
> 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.
>> 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.
Thanks. I browsed the script but I was unable to identify the relevant
>> 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.
No example yet. I'll ask if it comes up.
More information about the lfs-support