Didier Kryn said on Mon, 31 Jan 2022 10:27:53 +0100 >Le 29/01/2022 à 21:00, k...@aspodata.se a écrit : >> I don't see the point in letting init do serious process monitoring. >> Just use a minimal init and startup a separate process monitoring >> daemon (or what theese things are called). >> >> ... >> I don't see the point, learn to write good deamons. It seems the need >> to use theese process monitors has sprung up from the availability >> of shitty deamons. >> In my view, when a deamon dies by any other cause than from your >> will then it shall die so hard that it causes a major headacke and >> the shitty programmer should be publicly flogged as a reminder and >> example to other programmers -- well not really, but you get my >> point. >> >> Most deamons I have run, they just run, they don't need a process >> monitor except me. >> > I fully share this pov. I'm happy with sysvinit or Busybox init. >If I was still active, and needing to write daemons, I would certainly >welcome improvements on the following points: > > - simplify start/stop scripts and find a better way to express >their dependencies
Runit does that. > - help daemons ack when they're actually ready Runit goes one better, by allowing you to put tests in the run scripts of dependent processes to see when their dependencies are fully functional. The beauty is that YOU decide the meaning of "fully functional", not the daemon author, who might not understand your individual situation. > > Writing a self-daemonizing daemon in C was a routine when I was >still active, though I understand it could be more difficult in shell. But more difficult in Python. I try to stay away from C if Python does the job. I think Python3 plus its standard libraries are more secure than C code written by the error prone Steve Litt. As far as "routine", I would think it's a lot more difficult to have a program doublefork itself when finished than the 9 or so lines it takes to doublefork something else. I was unable to write a doublefork-something-else routine in /bin/sh. Maybe smarter shellscript people than I can do it, but I can't. >Also I like that the logs are sent to syslog. I'm pretty sure runit can send logs to syslog. > > But, as a user, I'm satisfied with sysvinit. Boot is so fast that >I've abandonned the use of suspend/resume. I'm pretty sure runit boots faster than sysvinit. Also, an excellent move is to use sysvinit for PID1, and use runit for most of the rest of your daemons. About writing good daemons... Sometimes, for my personal use, I want to write a quick and dirty daemon in Python, and if it dies have runit run it again. If I were to write a daemon where a crash would signify something terrible that needs to be investigated, it can be run as a one-shot by any init system. Whatever shellscript runs the daemon could end by getting $? and if it's non-zero, make a lot of noise. This could also be done if it's supervised. So I still say daemons are usually best run in the foreground and supervised by a supervisor. And therefore I'm not especially impressed by finit. Everything I said about runit in this email is also true of s6. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
