Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
maintain it if I had to. The various NetworkManager alternatives that have sprung up at Devuan. Could you point to or list those alternatives, please? I used Devuan occasionally since Beowulf release but now am going to say goodbye to Debian. Sometimes I need alternatives even for ifupdown. Here's my recent bicycle, btw, that might explain my needs: https://declassed.art/en/blog/2022/07/22/ethwifi-throw-away-networking-tools-and-keep-simple-things-simple And, I hope you excuse a newbie for a bit more: I had to use services of a corporation of the good to post this message. I'm a bit passionate about self-hosted software and email is not an exclusion. Never had problems for last year with it but mailing lists spotted the problem: Client host rejected: cannot find your hostname Yes, I'm aware of ptr records, but... setting up email is still complicated as it was 20 years ago. I see no progress over these years. Ideally I'd like to run an email server on my smartphone (and a backup relay on another one). If anyone could do that easily that would make email truly decentralized but there are still obstacles on the way to freedom. It's funny, working for a company in a "country of freedom" I had to ask permission to commit bugfixes to free software we used (finally, those commits did not happen). Now I'm totally liberated but I'm stuck in a devil country and have to use dnat'ed channels over vpn to my actual servers. So I don't want to touch ptr records. How it comes I had no problems with sending regular emails so far? Yes, I'm curious too. You know what? The corporation of the good, where most of my few recipients are, _does not check ptr records_! Wow! After discovering that I immediately commented out these lines in my smtpd.conf: #filter "rdns" phase connect match !rdns disconnect "550 DNS error" #filter "fcrdns" phase connect match !fcrdns disconnect "550 DNS error" If _they_ are not restrictive why am I still on the devil side so far? Did I get tons of spam? No. Anyway I don't delete spam for future analysis if I ever want to write my own mail server. And, dkim checker still works well. Well, I just wrote a draft for my next blog post, sorry. Anyway, I don't appeal to anything, this is just feedback. Who knows what your fairly elected presidents do with the internet tomorrow? Just an allusion, a similar thing happened to Debian. Axy ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
On Sat, 2022-08-06 at 08:36 +0200, Didier Kryn wrote: > Le 05/08/2022 à 07:36, Steve Litt a écrit : > > Perfectionists never finish, and the perfect is the enemy of the good. > > This is absolutely true. But ... > > perfection can be approached when we keep things "simple stupid". > For example the init script suggested by Karl: > > > for i in /etc/rcS.d/S* /etc/rc2.d/S* > > do > > $i start > > done > > doesn't need a maintaining community, Yes it does. The scripts in those directories are extremely complicated, assuming they're from sysvinit or OpenRC. Of course, they could be refactored to be very simple, at the cost of screwing up in corner cases. > and you also consider runit > is simple enough to fall in the same category. Absolutely. Runit run scripts are tiny, simple and straightforward. It's easy to write your own. The C code for Runit is so simple I could take over the project if I had to. > > Often, simplifying a problem till the solution is clear and > obvious, can take a lot of time, but it deserves the effort. It is > sometimes possible. Very, very true. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
Le 05/08/2022 à 07:36, Steve Litt a écrit : Perfectionists never finish, and the perfect is the enemy of the good. This is absolutely true. But ... perfection can be approached when we keep things "simple stupid". For example the init script suggested by Karl: > for i in /etc/rcS.d/S* /etc/rc2.d/S* > do > $i start > done doesn't need a maintaining community, and you also consider runit is simple enough to fall in the same category. Often, simplifying a problem till the solution is clear and obvious, can take a lot of time, but it deserves the effort. It is sometimes possible. High level languages, due to their high expressivity, help reach such simplicity. For example, the above script, translated in C (why not in assembler?) would need a carefull review by a community. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
On Fri, Aug 5, 2022 at 12:37 AM Steve Litt wrote: > > On Thu, 2022-08-04 at 17:36 -0400, Hendrik Boom wrote: > > On Thu, Aug 04, 2022 at 04:06:18AM -0400, Steve Litt wrote: > > ... > > > > > > 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. > > > > Might this be why we're using linux instead of Hurd? > > I never thought of it, but it's a possible cause of Hurd never taking the > lead. > > One of the very smart things Linus did was to forego the pie-in-the-sky dream > of the > theorists, the microkernel, to do the kernel he could actually get done all by > himself, the regular kernel. > > I'm reminded of Perl6, which in 1999 we all knew was going to take over the > world. > Heck, Sams Publishing offered to have me be the main author of an upcoming > Perl6 > Unleashed. But instead of just fixing a few of Perl 5's biggest problem, they > shot > for the moon, during which time Python and Ruby gladly claimed all of Perl's > mindshare. Today Perl 6 is a language called Raku, and for all I know it's a > great > language, but in the persuit of the perfect at the turn of the century they > gave up > the good, and now Raku is a minor league player. There is an update to perl5.xx being worked on IIRC. > > When I started the VimOutliner project, instead of writing it from scratch, I > used > Vim as the engine and just added a few scripts. So I was able to create and > release > it in about a week. > > Examples abound: Eric Raymond's fetchmail. Runit, which is so simple I could > maintain it if I had to. The various NetworkManager alternatives that have > sprung up > at Devuan. > > Perfectionists never finish, and the perfect is the enemy of the good. > My motto has been - - - I'll aim for perfection but I will settle for excellence. Insisting on perfection is like statistically asking for 100% or 0% results - - - - impossible and (I'll let you insert your favorite adjective). Regards ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
On Thu, 2022-08-04 at 17:36 -0400, Hendrik Boom wrote: > On Thu, Aug 04, 2022 at 04:06:18AM -0400, Steve Litt wrote: > ... > > > > 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. > > Might this be why we're using linux instead of Hurd? I never thought of it, but it's a possible cause of Hurd never taking the lead. One of the very smart things Linus did was to forego the pie-in-the-sky dream of the theorists, the microkernel, to do the kernel he could actually get done all by himself, the regular kernel. I'm reminded of Perl6, which in 1999 we all knew was going to take over the world. Heck, Sams Publishing offered to have me be the main author of an upcoming Perl6 Unleashed. But instead of just fixing a few of Perl 5's biggest problem, they shot for the moon, during which time Python and Ruby gladly claimed all of Perl's mindshare. Today Perl 6 is a language called Raku, and for all I know it's a great language, but in the persuit of the perfect at the turn of the century they gave up the good, and now Raku is a minor league player. When I started the VimOutliner project, instead of writing it from scratch, I used Vim as the engine and just added a few scripts. So I was able to create and release it in about a week. Examples abound: Eric Raymond's fetchmail. Runit, which is so simple I could maintain it if I had to. The various NetworkManager alternatives that have sprung up at Devuan. Perfectionists never finish, and the perfect is the enemy of the good. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
Steve Litt: > On Thu, 2022-08-04 at 16:01 +0200, k...@aspodata.se wrote: > > Steve Litt: ... > > There is no requirement of pid files in the above. The notion of pid > > files comes from some req. that you should be able to do > > ./some_script stop. > > I do sv stop daemonname all the time. Well, fine, I don't complain about that, just don't exspect every one to have the same set of requirments. > > If you don't care about scripts like thoose in > > /etc/init.d there is no need for pid files, and if you manage the > > startup and shutdown of single processes on your own then the ps > > output is sufficient. > > What if there are two of them running, or two processes so close in text that > it's > hard to grep between them? I've done stuff like looking at the ps output or > searching thru /proc, but I always felt a little insecure when doing so. . minimizes the number of running processes . when reading ps output, remove the kernel tasks from the list try e.g. ps ax | egrep -v '\]$' | sort -n . if it listens to a socket you can use netstat -tulp Regards, /Karl Hammar ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
On Thu, Aug 04, 2022 at 04:06:18AM -0400, Steve Litt wrote: ... > > 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. Might this be why we're using linux instead of Hurd? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
On Thu, 2022-08-04 at 16:01 +0200, k...@aspodata.se wrote: > Steve Litt: > > On Wed, 2022-08-03 at 09:36 +0200, marc wrote: > > > Karl Hammar > > > > Steve Litt: > ... > > > > 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. > ... > > There is no requirement of pid files in the above. The notion of pid > files comes from some req. that you should be able to do > ./some_script stop. I do sv stop daemonname all the time. > If you don't care about scripts like thoose in > /etc/init.d there is no need for pid files, and if you manage the > startup and shutdown of single processes on your own then the ps > output is sufficient. What if there are two of them running, or two processes so close in text that it's hard to grep between them? I've done stuff like looking at the ps output or searching thru /proc, but I always felt a little insecure when doing so. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
Le 03/08/2022 à 09:36, marc a écrit : 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 ? 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 ... 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. 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 ;) +1 -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
Steve Litt: > On Wed, 2022-08-03 at 09:36 +0200, marc wrote: > > Karl Hammar > > > Steve Litt: ... > > > 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. ... There is no requirement of pid files in the above. The notion of pid files comes from some req. that you should be able to do ./some_script stop. If you don't care about scripts like thoose in /etc/init.d there is no need for pid files, and if you manage the startup and shutdown of single processes on your own then the ps output is sufficient. Note, there is no godsent decry to have anything like a process manager, things works perfectly fine without that cruft, it all depends on your application and your own taste. Regards, /Karl Hammar ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Init respawns - was: Be prepared for the fall of systemd
Two empire falls recorded during the last two millenia it are the fall of the mighty Roman Empire and that of the Ottoman Empire. Both were extremely powerful influencing most of the worlds of their times, but they fell. What I expect from systemd and its adoption by many distributions is to recognise its problems and work harder to implement any advantages it may have had. Like many Devuaneers (users and advocates of Devuan), I expect an init system to remain an init system and package modularity to persist. I also expect a predictable behaviour from an init system. On my Raspberry Pi, systemd occasionally lists sound cards erratically breaking their ID number. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
marc: > Steve Litt: > > 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 requirement for deamons not to background is so that the process manager: 1, will get a SIGCHLD when the process terminates instead of scanning running processes or log files 2, don't need a pid file to find the process for the purpose of terminating it or something else 3, will get log output from a file descriptor instead of scanning syslog possible other things... Depending of your own requirements, that might be important or not. > > 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. ... > TL;DR: just install better daemons ;) ACK. But you have to write them also, what others write is usually out of your hands. Regards /Karl Hammar ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Init respawns - was: Be prepared for the fall of systemd
> 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 ? > 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 ... 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. 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 ;) regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
