Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sat, 11 Oct 2014 21:21:14 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> On Sb, 11 oct 14, 13:40:08, Steve Litt wrote:
> >
> > sysvinit is an idea whose time has gone. sysvinit is a poor way to
> > showcase the Unix Way. First of all, the whole idea of runlevels is
> > bizarre, and adds a lot of complexity to init scripts. If you
> > compare a daemontools /service/myserviced/run to an init script,
> > you'll see an order of magnetude simplification, without
> > sacrificing the flexibility of a shellscript.
>
> Why should I write a script? I'm not a programmer.
Why should I configure and maintain a firewall? I'm not an admin.
One's being a "programmer" is such an arbitrary division. OK, you're
not the first guy I'd call if I wanted a device driver coded, but I'd
have complete confidence in you to write a short shellscript. And,
being able to write a short shellscript (which I'm sure you can do),
would make you a much more able Linux administrator and user.
>
> [snip]
>
> > I *might* characterize the preceding as trying to reduce complexity
> > for the dufus who can't even write a shellscript. However, the cost
> > of this reduced complexity for the dufus is huge complexity within
> > the program: complexity even smart people can't work around without
> > some truly ridiculous kludges.
>
> I can write a (simple) shellscript, but I wouldn't dare write an
> initscript or even a daemontools runscript.
Daemontools runscripts are incredibly simple shellscripts, that I'm
sure you could write no sweat except in very wierd edge cases. Here's
my run script for my home-grown cron substitute:
======================================================
#!/bin/sh
####### DON'T START littcrond UNTIL THE NETWORK'S UP #######
pingaddr=8.8.8.8
pingaddr=192.168.100.96
echo littcrond checking network 1>&2
while ! ping -q -c1 $pingaddr > /dev/null; do
sleep 1
echo littcrond REchecking network 1>&2
done
####### RUN THE DAEMON #######
exec envuidgid slitt envdir ./env setuidgid slitt \
/d/at/python/littcron/littcron.py \
/d/at/python/littcron/crontab
======================================================
The last three lines are really one line that wordwraps in email. If I
hadn't checked for the network being up, this would have been a two
line shellscript. I've known you (online) for several months, and
although we sometimes disagree, I know you're pretty smart, so I'm
positive you could have written this shellscript without breaking a
sweat.
>
> > I have a theory on that. runit, s6, init-ng, etc never caught on
> > because sysvinit was considered good enough, and it was easier for
> > the average person to work around its rough edges rather than learn
> > a new init system.
>
> I recently needed something to run imapfilter and restart it in case
> it might exit, so I had a look at daemontools. I gave up quickly
> after I realised the amount of scaffolding required just to get
> daemontools itself running (additional top-level directories, are you
> kidding?).
>
> With systemd (v215) I had to write this unit file:
[clip Andre's easy description of daemonizing imapfilter with systemd]
Yes, there's significant scaffolding, mostly revolving around
installing daemontools. Also, Andre didn't bring this up, but it's
implicit in his objection: Most daemontools documentation is terse and
assumes a whole lot of Unix-smarts on the part of the reader, with few
examples.
That's why I wrote this document:
http://www.troubleshooters.com/linux/djbdns/daemontools_intro.htm
Armed with the preceding document, a person can learn daemontools in a
day, and use it for the rest of his life.
If you can run imapfilter in the foreground, it's trivial to have
daemontools daemonize it for you. And you'll know *exactly* how it's
going to work.
The other benefit of daemontools is it works, every single time. It
never misfires, it never behaves in ways that are unspecified or
against specification, it keeps working for years, and a simple (as
root) backup walks it from distro to distro.
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Reply to: