Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Sun, 16 Apr 2017 19:22:36 -0400 Hendrik Boom wrote: > On Sun, Apr 16, 2017 at 05:04:18PM -0400, Hendrik Boom wrote: > > On Sun, Apr 16, 2017 at 09:59:36PM +0200, Enrico Weigelt, metux IT > > consult wrote: > > > By the way: maybe we should write an RFC draft for the whole > > > issue ... > > > > Looked for a relevant RFC. But found only this: > > https://lists.ubuntu.com/archives/kernel-team/2008-December/003628.html > > [RFC] [PATCH] notify init daemon when children are reparented to it > > > > But this doesn't seem to be quite what we want, and I can't say I > > have enough context to understand it. > > That so-calledRFC seems to be very much in the style of > requiring the init process to be intimately involved in process > supervision actions, which is a strong constraint on what init > systems can be chosen. And, I suspect, an init system that is so > involved is a potential tool to gradually take over the entire OS, as > systemd has done. And, in fact, being written in 2008, that so called rfc might have been either the excuse or the inspiration for systemd. The "rfc" suffers from a perfectionism related to bikeshedding. Heaven forbid there's ever a zombie or a process with a 'T' in the ps status field! We simply MUST make a perfect init or supervisor system: Nothing less will do. And while we're indulging our perfection, it's important to remember that simplicity not be a priority at all. We will remain oblivious to the fact that complexity and lack of encapsulation creates flaws far worse than the flaws we're moving heaven and earth to get rid of. And for gosh sakes, let's forget the facts: THE FACTS * sysvinit is perfectly workable for the vast majority of users, or at least it was until the systemd people influenced the "upstreams" to build in code to fail with sysvinit. * sysvinit plus daemontools is perfectly workable for almost all users who are capable of writing a short run file and creating a symlink. Daemontools suffers from none of the problems hand-wrung by the "rfc", and indeed in a daemontools world (or at least as a runit world which I assume is the same), the only process whose parent is PID1 is runsvdir (equivalent of daemontools svscanboot). On my computer, the executables reparented to PID1 are all stuff spawned by dmenu or UMENU, as well as the gvim executable, which doubleforks itself automatically. More on this later... * sysvinit plus OpenRC is perfectly workable for most users who don't want daemon respawning. * sysvinit plus OpenRC plus daemontools is perfectly workable for users who want some daemons respawnable. * A PID1 consisting of an rc file that somehow respawns the virtual terminals, background-runs any daemons necessary, and then ends in a loop that listens for and handles signals to PID1, is perfectly workable for a person operating a small, special purpose computer. If I knew how to respawn virtual terminals I'd do just that as a demonstration, but respawning gettys is incredibly difficult: It often kills the process that tried to respawn it. * The 83 line Suckless Init spawning an rc file is perfectly workable for someone wanting simplicity and the ultimately simple PID1. Bottom line, all this bikeshedding perfectionism is unnecessary unless you're a big commercial company trying to turn Free Software into a cash cow by complexifying it. All the problems were solved long ago, or are easily solvable by simple, user space addons needing no modification to the likes of sysvinit, daemontools, runit, s6, Epoch, OpenRC and the like. For instance, I have a real problem with zombies and T status processes created by my use of dmenu and UMENU. It wouldn't be particularly difficult for me to build a userspace daemontools analog, where one process parented to PID1 (my analog of svscanboot) would spin around listening for commands and/or scripts to run in such a way that IT was the parent, or perhaps via analogs of svscan that don't respawn. I could then modify dmenu and UMENU to message my daemon in order to run commands. Notice the idea in this paragraph requires not one modification to whatever "init system" you're using. And it's simple enough that even I could implement it, given the time. There's no need to search for the perfect init or supervisor. Long ago we got a bunch of them that are all good enough, and can be combined to fill almost any need. This continuing search for a perfect init is just wheel spinning, or perhaps an excuse for profit-driven complexification. SteveT Steve Litt April 2017 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
Re: [DNG] Some links found at a report on a Debian bug squashing party
On 2017-04-16 19:21, Hendrik Boom wrote: Recently I failed to attend a Debian bug squashing party here in Montreal because I was otherwise engaged that day. If I had attended I would have learned something about Debian packaging, which could perhaps have been useful here. But the report on the bug squashing party contains links to the documents that were to clue the attendees in to Debian packaging. I therefore refer those interested to that report: https://anarc.at/blog/2017-04-09-montreal-bsp-report/ with links to https://anarc.at/software/debian-development/ https://wiki.debian.org/sbuild Also: Montreal is the location of the next Debconf: https://debconf17.debconf.org/ And at the footer of the bug squshing paty report, there's a link to concerns about ambiguous wording in the new terms of service at Github: https://anarc.at/blog/2017-03-22-github-tos-update/ -- hendrik Have you seen our very own Devuan packaging helper? https://dev1galaxy.org/viewtopic.php?id=549 golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Some links found at a report on a Debian bug squashing party
Recently I failed to attend a Debian bug squashing party here in Montreal because I was otherwise engaged that day. If I had attended I would have learned something about Debian packaging, which could perhaps have been useful here. But the report on the bug squashing party contains links to the documents that were to clue the attendees in to Debian packaging. I therefore refer those interested to that report: https://anarc.at/blog/2017-04-09-montreal-bsp-report/ with links to https://anarc.at/software/debian-development/ https://wiki.debian.org/sbuild Also: Montreal is the location of the next Debconf: https://debconf17.debconf.org/ And at the footer of the bug squshing paty report, there's a link to concerns about ambiguous wording in the new terms of service at Github: https://anarc.at/blog/2017-03-22-github-tos-update/ -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Sun, Apr 16, 2017 at 05:04:18PM -0400, Hendrik Boom wrote: > On Sun, Apr 16, 2017 at 09:59:36PM +0200, Enrico Weigelt, metux IT consult > wrote: > > On 15.04.2017 19:50, Steve Litt wrote: > > > > > About my characterizations: "Baroque" is a relative thing. What I wrote > > > was based on "why would you not simply use a process supervisor like > > > systemd?" If a person has a reason not to use such a supervisor, and in > > > fact the whole OpenRC init system seems to be based on such objections > > > to supervisors, then the six system call solution you outline > > > transitions from "a whole bunch of needless stuff" to "hey, that's a > > > pretty darn kool solution." So your solution is baroque only so far as > > > one enjoys using daemontools or similar. > > > > If one doesn't want a supervisor, why not just using something like > > start-stop-daemon ? IIRC, it should handle that quite well. > > > > I wonder why that general task of daemonizing cant just be done in a > > generic separate program and left out of the individual daemons. > > So, everybody can decide on this own how to actually start/manage > > the daemons - some use a supervisor, some just call via a daemonizer > > program from init scripts, etc, etc. > > > > By the way: maybe we should write an RFC draft for the whole issue ... > > Looked for a relevant RFC. But found only this: > https://lists.ubuntu.com/archives/kernel-team/2008-December/003628.html > [RFC] [PATCH] notify init daemon when children are reparented to it > > But this doesn't seem to be quite what we want, and I can't say I have > enough context to understand it. That so-calledRFC seems to be very much in the style of requiring the init process to be intimately involved in process supervision actions, which is a strong constraint on what init systems can be chosen. And, I suspect, an init system that is so involved is a potential tool to gradually take over the entire OS, as systemd has done. Of course, even with such an init system, it's possible to use the other mechanisms we have been discussing here to enable specific daemons to ignore the init system. -- hendrik > > It seemms to follow the practice of creating two processes for a > daemon, a parent and a child, and then orphaning the child. > This is not what we seem to be discusison here, and leads to > init having nontrivial ongoing work. > > And although it says [RFC] in the title, it doesn't seem to be an > official RFC. > > -- hendrik > > > > > > > --mtx > > ___ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Sun, Apr 16, 2017 at 09:59:36PM +0200, Enrico Weigelt, metux IT consult wrote: > On 15.04.2017 19:50, Steve Litt wrote: > > > About my characterizations: "Baroque" is a relative thing. What I wrote > > was based on "why would you not simply use a process supervisor like > > systemd?" If a person has a reason not to use such a supervisor, and in > > fact the whole OpenRC init system seems to be based on such objections > > to supervisors, then the six system call solution you outline > > transitions from "a whole bunch of needless stuff" to "hey, that's a > > pretty darn kool solution." So your solution is baroque only so far as > > one enjoys using daemontools or similar. > > If one doesn't want a supervisor, why not just using something like > start-stop-daemon ? IIRC, it should handle that quite well. > > I wonder why that general task of daemonizing cant just be done in a > generic separate program and left out of the individual daemons. > So, everybody can decide on this own how to actually start/manage > the daemons - some use a supervisor, some just call via a daemonizer > program from init scripts, etc, etc. > > By the way: maybe we should write an RFC draft for the whole issue ... Looked for a relevant RFC. But found only this: https://lists.ubuntu.com/archives/kernel-team/2008-December/003628.html [RFC] [PATCH] notify init daemon when children are reparented to it But this doesn't seem to be quite what we want, and I can't say I have enough context to understand it. It seemms to follow the practice of creating two processes for a daemon, a parent and a child, and then orphaning the child. This is not what we seem to be discusison here, and leads to init having nontrivial ongoing work. And although it says [RFC] in the title, it doesn't seem to be an official RFC. -- hendrik > > > --mtx > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Enrico Weigelt: ... > If one doesn't want a supervisor, why not just using something like > start-stop-daemon ? IIRC, it should handle that quite well. Why not just start the program and kill it when not needed anymore ? You know, you don't have to have a supervisor. > I wonder why that general task of daemonizing cant just be done in a > generic separate program and left out of the individual daemons. > So, everybody can decide on this own how to actually start/manage > the daemons - some use a supervisor, some just call via a daemonizer > program from init scripts, etc, etc. ... http://software.clapper.org/daemonize/daemonize.html BTW, -f and using daemon() is darn easy to implement. We did have a kind of supervisor in inetd (mostly to save memory and reduce load), but it's use has fallen out of favour. So why do we have to invent new ways of starting and killing programs ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 15.04.2017 19:50, Steve Litt wrote: > About my characterizations: "Baroque" is a relative thing. What I wrote > was based on "why would you not simply use a process supervisor like > systemd?" If a person has a reason not to use such a supervisor, and in > fact the whole OpenRC init system seems to be based on such objections > to supervisors, then the six system call solution you outline > transitions from "a whole bunch of needless stuff" to "hey, that's a > pretty darn kool solution." So your solution is baroque only so far as > one enjoys using daemontools or similar. If one doesn't want a supervisor, why not just using something like start-stop-daemon ? IIRC, it should handle that quite well. I wonder why that general task of daemonizing cant just be done in a generic separate program and left out of the individual daemons. So, everybody can decide on this own how to actually start/manage the daemons - some use a supervisor, some just call via a daemonizer program from init scripts, etc, etc. By the way: maybe we should write an RFC draft for the whole issue ... --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Sun, 16 Apr 2017 10:01:02 +0200 marc wrote in response to Steve Litt: > > And therefore I was wondering > > why fork_parent() didn't take a function address as an argument, and > > call that callback function's address where you have the elipses. > > No function pointers needed. After a fork() system call you have two > almost identical copies of the same process. The one which sees a > return code greater than 0 is the parent. The parent instance however > never makes it out of the fork_parent() library call. > > > Yes. It makes sense. My question was where you put the code > > represented by your elipses above. > > The code in the elipses runs outside the fork_parent() call. It could > run in the main() function or elsewhere. OK, I completely understand. It makes sense. It's pretty slick, too. I never would have thought of it. Being a daemontools enthusiast, I still don't see fork_parent() as an asset in late boot. But I have a feeling it, or something similar, could be an asset in different contexts. As a matter of fact, in my UMENU program, I might change my backgrounding code to incorportate that, and perhaps in doing so eliminate some sleep kludges. Thanks, SteveT Steve Litt April 2017 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
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Hello > Wait. Are you saying that the way fork_parent() is used is to modify > the source code of fork_parent() itself? No - you just call it, like daemon(). Then later, outside fork_parent() you call close(). > I was under the impression that fork-parent() was a library > call that you made to properly background your source code, which > exists outside of function fork_parent(). That is the correct impression. > And therefore I was wondering > why fork_parent() didn't take a function address as an argument, and > call that callback function's address where you have the elipses. No function pointers needed. After a fork() system call you have two almost identical copies of the same process. The one which sees a return code greater than 0 is the parent. The parent instance however never makes it out of the fork_parent() library call. > Yes. It makes sense. My question was where you put the code represented > by your elipses above. The code in the elipses runs outside the fork_parent() call. It could run in the main() function or elsewhere. > Is fork_parent() a template (in the general > sense, not the C++ sense) that you modify, No, not a template. > or is it a tool you use, as > is, to background code you put in a separate function? It is a library call. regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /etc/debian_version
On Sat, Apr 15, 2017 at 08:32:30PM -0700, Gregory Nowak wrote: > On Sat, Apr 15, 2017 at 01:06:53PM +0200, Jaromil wrote: > > Yet I believe we should file this as a bug as /etc/debian_version is > > not there on new installs. The /etc/debian_version file is checked by > > an enormous quantity of scripts in all sorts of deployements, we have > > encountered this problem also with Vagrant, that I remember. So we > > shall keep that file around and fill it with the Debian version we use > > to fallback packages in each release, that is so far: > > Thanks. File this as a bug where, debian or devuan, and against what > specifically? > Hi Greg, All, we have our own Bug Tracking System since a few weeks ago. It's at http://bugs.devuan.org and is compatible with the one used at Debian. Bugs are filed using the "reportbug" utility, or directly via email. Just check that you have the last version of reportbug (6.6.3+devuan1.2) which is in the main repo in jessie. That one knows about bugs.devuan.org (even if some of the branding still says Debian). HopeThisHelps KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan 1.0 RC and DistroWatch
On Sat, 15 Apr 2017, Ismael L. Donis Garcia wrote: > How can you advertise to Devuan 1.0 RC in DistroWatch? the release canidate is not yet out. I will be announced on tuesday. Distrowatch journalists pick up regularly on our announcements which are circulated via the official devian-announce mailinglist. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /etc/debian_version
On Sat, 15 Apr 2017, Gregory Nowak wrote: > Thanks. File this as a bug where, debian or devuan, and against what > specifically? a bug for devuan: https://bugs.devuan.org against the 'base-files' package which we have forked here https://git.devuan.org/devuan-packages/base-files thanks ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
