svn bootscripts

DJ Lucas dj at
Mon May 30 19:55:25 PDT 2011

On 05/30/2011 02:55 PM, Bruce Dubbs wrote:

 > I'd appreciate it if you could do a revert. I took a look at the 
patch and it installs initd-tools as yet another
 > package. I looked at the source to initd-tools and I don't understand 
why we need a C program to do that. It could
 > be done in a shell script. That would require someeffort to create, 
but would be much easier to maintain.

I'll jump in and fix that for now real quick then, I'll also add the 
subsystem call to udev script, but IDK about scripting 
{install,remove}_initd. Initd-tools is one extra package, it's tiny, it 
works, and being only in C, the maintenance burden is likely to be very 

 > Perhaps I can try writing the script after the middle of next month. 
We have a big deadline coming up.
 > After that, I think I've earned about a year of comp time.

I'll wish you luck then. ;-) Been there, done that. It was really slow 
in just bash (and a couple hundred sed and grep calls), but was a neat 
learning exercise none the less. For fun, I then wound up using make to 
handle dependencies and the script was almost fast enough to be usable 
(somebody had suggested using make as a replacement for init in some 
passing conversation and I thought it a neat idea). :-) Then I decided 
to use it as an excuse to learn perl. Dan came up with initd-tools 
before I really even got started on it in perl (which I still do not 
know well BTW). I thought C would be perfect (no additional dependencies 
for LFS), so I scrapped all three previous attempts.

At any rate, here are a couple of caveats that I vaguely remember 
causing me to start from scratch or make major changes to the way I was 
doing things a few times:

1. Scriptname != Facility. Admittedly, this seems obvious now.
2. Do not fall into the trap of looking at /etc/rc.d/init.d and 
expecting all scripts to be activated. The easiest method I came up with 
for a list of activated scripts was to run through all of the rc?.d 
directories to assemble a list of link targets. From that list, I then 
read all of the headers into multiple arrays and worked only from the 
index with the new script as the last in the array so that disk i/o was 
limited to the beginning and end of the script.
3. Don't forget about start links in 0 and 6 which will be dependent on 
both *-stop and *-start of the current runlevel, but not scripts 
supplied in runlevel S (formerly sysinit).
4. All other runlevels will have to account for items started in 
runlevel S.
5. The Default-St{art,op} does not have to define in which runlevels any 
existing activated scripts are started, but both Dan and I, while 
working independently, chose to do so as the spec does not limit the 
program in that way, and the note at the bottom of 
does not seem to indicate that will change. LFS does not provide any 
existing automation, and in practice this is really the most direct way 
of managing runlevel 4 if needed, and provides similar functionality to 
insserv or chkconfig in Suse or RedHat without any added complexityor 
additional tools(in fact, in all test cases that I could come up with, 
it greatly simplifies the job to always reorder as opposed to trying to 
fit a script in between others).


-- DJ Lucas

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

More information about the lfs-dev mailing list