djb utilities

Michael A. Peters mpeters at
Sun May 4 19:05:49 PDT 2003

On Sun, 2003-05-04 at 15:38, Michael A. Peters wrote:
> Red Hat was the first to make it into a binary - at least in Linux.
> It was a shell script in some distro's before Red Hat wrote code, and I
> believe it was in SCO Unix originally.

Clarification -
It was IRIX that originally shipped with chkconfig.
It was in 1993 when a linux shell script version appeared - I don't know
if it was included with any distro's or not, that was way before my
entry into linux.

Several years later was when Red Hat came out with their version.

Not that it matters - but I wanted to clarify my mistake on the history
of it.

> > 
> > So you want to give us a real reason why the DJB stuff shouldn't included? 
> Yes. It's not needed.

To clarify my view on this -
There is already standard facilities for stopping/starting daemons in
LFS/BLFS via the sysV init mechanism.

By adding DJB's daemontools it adds complexity to the system because
there are now more than one way that daemons are controlled. Some with
SysV init and some with daemontools (and potentially some with xinetd -
though I haven't found a need to install xinetd and would prefer not to
for the same reason of simplicity).

qmail can be started by the facilities that LFS/BLFS already have (SysV
init) and I just don't think its a good idea to have a separate facility
for doing what already can be done with the standard facility that
virtually all LFS/BLFS'ers already have (SysV init). For those who chose
a BSD style init script instead, qmail can be started that way as well.

I'm not saying that qmail shouldn't be included as an alternative MTA to
Sendmail (which imho should be avoided when possible, which it sometimes
isn't) or Postfix - but since daemontools isn't required for qmail and
since daemontools is in conflict with the LFS/BLFS method for
starting/stopping daemons and since daemontools has FHS/LSB issues (so
does postfix - it doesn't create a PID file as far as I can tell) - I
personally don't think it needs to be there.

I apologize to you specifically and to the list for coming off strong.
I don't want to start flame wars, but sometimes I'm quick to speak and
slow to listen, which is something I need to change.

> -- 
> Michael A. Peters <mpeters at>
Michael A. Peters <mpeters at>

Unsubscribe: send email to listar at
and put 'unsubscribe blfs-dev' in the subject header of the message

More information about the blfs-dev mailing list