On Wed, 2022-08-03 at 09:36 +0200, marc wrote:
> > Thanks Karl,
> >
> > Some questions:
>
> Hello
>
> > 1) Does Busybox init require the daemon to background itself?
>
> So I seem no reason why "nohup daemon > /var/log/logfile &" isn't sufficient
> for this, or is there something I am not aware of ?

The preceding involves PID files, which can get mixed up or stale. Also, the
nohup.out file can grow to a monstrosity, although that can be handled (no pun
intended) by redirection to /dev/null.

>
> > 2) Does Busybox init give you a reasonable way to automatically restart the
> > process
> > after the process terminates?
> >
> > 3) Does Busybox init give you the choice of auto-restart or not for each
> > different
> > process? If it does, that's something specifically missing in Runit.
>
> At the risk of pinning my own interpretation on this:
>
> I suppose for quick, dirty and crashy hacks maybe automated restarts
> are useful to paper over some problems. But if the daemon you are running
> is likely to crash, it might also just hang in an infinite loop or
> leak file descriptors, or fill up a partition or grind through swap, things
> that a respawn doesn't really solve ...

True.

>
> We are often told that "thesedays computers are cheap and programmers are
> expensive" as an excuse for writing flaky software, and from the perspective
> of the greedy and immortal AI that is a corporation, this makes sense - a
> bit of bespoke software, even if flaky, might do the work of a human more
> quickly and cheaper while the costs are externalised.

True.
>
> But the free software universe things are different - unreliable or
> bloated software wastes the time and hardware resources of thousands, perhaps
> millions of people. And even if you are happy to ignore the environmental
> costs (electricity, more hardware bought more often), then maybe some
> other reasoning might be persuasive: I certainly often marvel at the
> craftsmanship of people from previous ages - from as small as an excellent
> hand tool to as expansive as a church, mosque or similar - those things were made
> not "meh, good enough", but as good as humanly possible, and I would
> think that the free software world has some similarities there - while
> software might be written to scratch an itch, the solution is often
> created for the joy of it, for the satisfaction of building something
> really good - be it just for fun, the desire to leave a legacy or
> building a contemplative mandala.
>
> TL;DR: just install better daemons ;)

Most of what you write above is true, but a lot of times it's just nicer to have the
daemon get restarted, along with a note in a log somewhere as to what happened.
Sometimes restarting can risk damage so you don't want to restart. Other times,
assuming the crashes or unintended exits aren't common, it's better to have the
daemon always up.


When I write Free Software, I'm one of those "meh, good enough" guys, although I'd
phrase it "Awww Riiight, good enough!". The reason is that perfectionists never
finish. And if I left a bug, I'll hear about it soon enough and can fix it.

In C I tend to use assert() for error checking, which is about as crude as you can
get. But whenever I see or hear about one of those asserts() actually firing, I
replace it with real error handling. If I were to put in real error handling on
every fopen() and calloc() and NULL check on initial authoring, I'd lose my train of
thought and never finish. So I use assert() for the time being.

SteveT