Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 21.04.2017 21:31, k...@aspodata.se wrote: > a, If you have that impression, then why daemonize() which sounds as >the same thing ? > > b, No it isn't. That's why the -f, which is nice to have when debugging. If you dont want the service to daemonize itself, a debug flag doesn't seem the

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Enrico Weigelt: > On 18.04.2017 14:46, k...@aspodata.se wrote: > > > Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in > > either camp, end case. > > I've had the impression that daemon() wasnt't good idea for everybody, a, If you have that impression, then why daemonize() which

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18.04.2017 12:21, Alessandro Selli wrote: > Again, as far as I understood what Enrico Weigelt wrote, the monitor > does not want to know the user:group the daemons runs under, it needs to > *set* them to the appropriate values when it launches the daemon to have > them reflect config file

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18.04.2017 14:46, k...@aspodata.se wrote: > Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in > either camp, end case. I've had the impression that daemon() wasnt't good idea for everybody, and there might be some need for anyone doing something these. So I proposed to move

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18.04.2017 15:15, Arnt Gulbrandsen wrote: > There's hypothetical stuff, what if service x needs service y. Well, > what if it does. Should it demand that y be running at every moment and > on the same host? DOES it demand that? nfs daemons (plural) need portmap. many years ago, I've patched

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18.04.2017 16:08, Alessandro Selli wrote: Hi folks, seems that things got a bit overheated here ... > Where did Enrico Weigelt write the monitor should get it's child PID > from the process itself? This subthread started from these lines: > >>> * srvmgt_droppriv(...) >>> --> drop root

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Tue, Apr 18, 2017 at 11:10:24PM +0200, Alessandro Selli wrote: > On 18/04/2017 at 19:01, KatolaZ wrote: > > On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote: > > > > [cut] > > > >>> There is really no other reasonable alternative, IMVHO. > >> Yes, there is. It's called a good

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18/04/2017 at 19:01, KatolaZ wrote: > On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote: > > [cut] > >>> There is really no other reasonable alternative, IMVHO. >> Yes, there is. It's called a good compromise. Then, outside of it, >> you find the purists and the extremists.

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18/04/2017 at 16:16, KatolaZ wrote: > On Tue, Apr 18, 2017 at 02:48:54PM +0100, Arnt Gulbrandsen wrote: >> kato...@freaknet.org writes: >>> Unfortunately we are already paying the consequences of badly-written >>> software implementing oddly-designed solutions to non-existing >>> problems... >>

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18/04/2017 at 14:46, k...@aspodata.se wrote: [...] > Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in > either camp, end case. This is well *if* the daemon has -f and does daemon(). I know the only programs that do not do it are those that were not intended to be run as

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18/04/2017 at 16:42, k...@aspodata.se wrote: > Alessandro: >> On 18/04/2017 at 15:11, k...@aspodata.se wrote: >>> Alessandro Selli: >>> ... And what I don't like of Karl Aspo's idea is that it takes any instrument of policy checking and enforcing out of the monitor, which ends up

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Alessandro: > On 18/04/2017 at 15:11, k...@aspodata.se wrote: > > Alessandro Selli: > > ... > >> And > >> what I don't like of Karl Aspo's idea is that it takes any instrument of > >> policy checking and enforcing out of the monitor, which ends up not > >> being able to monitor anything, it

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Katola2: > On Tue, Apr 18, 2017 at 03:11:51PM +0200, k...@aspodata.se wrote: ... > > If I can get a value from the kernel instead of from the process, > > I'd take the kernel value. > > > > Why do a process have to query the kernel to get a value and then > > sending it to a monitor over a

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Tue, Apr 18, 2017 at 02:48:54PM +0100, Arnt Gulbrandsen wrote: > kato...@freaknet.org writes: > >Unfortunately we are already paying the consequences of badly-written > >software implementing oddly-designed solutions to non-existing > >problems... > > Indeed. But what's your point? > Oh, you

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18/04/2017 at 15:11, k...@aspodata.se wrote: > Alessandro Selli: > ... >> And >> what I don't like of Karl Aspo's idea is that it takes any instrument of >> policy checking and enforcing out of the monitor, which ends up not >> being able to monitor anything, it becomes just a shell: fire and

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

kato...@freaknet.org writes: Unfortunately we are already paying the consequences of badly-written software implementing oddly-designed solutions to non-existing problems... Indeed. But what's your point? Arnt ___ Dng mailing list Dng@lists.dyne.org

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

kato...@freaknet.org writes: I genuinely don't understand why the kernel should know about the internals of running processes, or get notified if a process is "ready" to do whatever it is supposed to do, or get queried by other processes which would like to access this kind of information, or

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Tue, Apr 18, 2017 at 02:15:38PM +0100, Arnt Gulbrandsen wrote: > I've read this thread fairly thoroughly, but fail to see much of a use > case... > > There's hypothetical stuff, what if service x needs service y. Well, what if > it does. Should it demand that y be running at every moment and

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Alessandro Selli: ... > And > what I don't like of Karl Aspo's idea is that it takes any instrument of > policy checking and enforcing out of the monitor, which ends up not > being able to monitor anything, it becomes just a shell: fire and forget. I honestly do not understand what I have written

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Allesandro, I'm not interested in a debate (people talking past each other), I'm interested in understanding why the proposed library and it function calls are such a good idé, since I don't think it is. Wheter to run a monitor or not is a different question, which I consider is up to the local

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Tue, Apr 18, 2017 at 11:32:00AM +0100, KatolaZ wrote: > On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote: > > Why should a car driver care if the traffic light has the red or the > > green light turned on? > > Why should a sysadmin care if the OS he uses runs systemd or not?

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18/04/2017 at 12:32, KatolaZ wrote: > On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote: > > [cut] > >>> And why should a program/daemon care if >>> it has a monitor or not ? >> Why should a car driver care if the traffic light has the red or the >> green light turned on? >>

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Tue, 18 Apr 2017 11:32:00 +0100 KatolaZ wrote: > > Why should a car driver care if the traffic light has the red or the > > green light turned on? > > Why should a sysadmin care if the OS he uses runs systemd or not? > > > > This is a totally wrong assumption.

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote: [cut] > > > And why should a program/daemon care if > > it has a monitor or not ? > > Why should a car driver care if the traffic light has the red or the > green light turned on? > Why should a sysadmin care if the OS he

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 18/04/2017 at 10:35, k...@aspodata.se wrote: > Alessandro Selli: >> On Fri, 14 Apr 2017 at 12:06:44 +0200 (CEST) >> k...@aspodata.se wrote: >>> Enrico Weigelt: >>> ... Let's just take some example: libsrvmgt with funcs like that: * srvmgt_daemonize() --> detach from

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Alessandro Selli: > On Fri, 14 Apr 2017 at 12:06:44 +0200 (CEST) > k...@aspodata.se wrote: > > Enrico Weigelt: > > ... > > > Let's just take some example: libsrvmgt with funcs like that: > > > > > > * srvmgt_daemonize() > > > --> detach from controlling terminal, etc > > > > Why do any

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Tue, Apr 18, 2017 at 03:36:09AM -0400, Steve Litt wrote: > On Mon, 17 Apr 2017 10:09:02 +0200 > exha...@posteo.net wrote: > > > in the same way that there's not a perfect graphical desktop for all > > the people, > > Quoted for truth! > > You can't *download* or *install* the perfect GUI

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Mon, 17 Apr 2017 10:09:02 +0200 exha...@posteo.net wrote: > in the same way that there's not a perfect graphical desktop for all > the people, Quoted for truth! You can't *download* or *install* the perfect GUI desktop, you must construct the GUI desktop that's best for you. And that

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 17/04/2017 at 03:57, Steve Litt wrote: [...] > 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

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Fri, 14 Apr 2017 at 12:06:44 +0200 (CEST) k...@aspodata.se wrote: > Enrico Weigelt: > ... > > Let's just take some example: libsrvmgt with funcs like that: > > > > * srvmgt_daemonize() > > --> detach from controlling terminal, etc > > Why do any monitor program need to know if the

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

exha...@posteo.net wrote: > In my opinion, this is the best that has been written about init or > supervisor, +1 > (I'm absolutely agree with this) > > "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

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Mon, Apr 17, 2017 at 12:33:06PM +0200, marc wrote: > the kernel thesedays > allows one to delegate the "default-child-collector" function of > init to other processes - that is what the container infrastructure uses. Which seems to be an effective rebuttal against the argument for systemd

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sun, Apr 16, 2017 at 09:57:38PM -0400, Steve Litt wrote: > 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 > > >

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Le 14/04/2017 à 10:57, Enrico Weigelt, metux IT consult a écrit : * srvmgt_report_state(...) --> report the service state to the supervisor --> states could be eg. * SRVMGT_STATE_STARTUP -- still within the startup phase * SRVMGT_STATE_READY_LOCAL -- ready for local

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

> > 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

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

> 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

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

In my opinion, this is the best that has been written about init or supervisor, (I'm absolutely agree with this) "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

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

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

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

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

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

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

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sat, 15 Apr 2017 22:50:20 +0200 marc wrote: > > Concerning the fork-parent.c and fork-parent.h revealed at > > http://welz.org.za/notes/fork-parent.tar.gz , I can't envision how > > you'd bind the fork-parent() function to the stuff your daemon > > actually does, in order

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

> Concerning the fork-parent.c and fork-parent.h revealed at > http://welz.org.za/notes/fork-parent.tar.gz , I can't envision how > you'd bind the fork-parent() function to the stuff your daemon actually > does, in order to have your daemon properly fork and then terminate the > parent when ready

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sat, 15 Apr 2017 08:14:48 +0200 marc wrote: > I have written up the details at > http://welz.org.za/notes/on-starting-daemons.html Concerning the fork-parent.c and fork-parent.h revealed at http://welz.org.za/notes/fork-parent.tar.gz , I can't envision how you'd bind

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sat, 15 Apr 2017 13:50:22 -0400 Steve Litt wrote: Oops. Concerning my statement: > What I > wrote was based on "why would you not simply use a process supervisor > like systemd?" s/systemd/daemontools/ SteveT Steve Litt April 2017 featured book: Troubleshooting

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sat, 15 Apr 2017 19:12:31 +0200 marc wrote: > I appreciate that Steve likes the daemontools approach where the > server process stays in the foreground, and I have no quarrel with > the advice of including a -f foreground option... The daemontools > approach makes a

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Hello again Steve > > The TLDR is that "A good daemon should fork soon, but have the > > parent process exit only once the child is ready to service requests" > > > > Sadly it seems too subtle for many people and the concept goes > > un-noticed ... > > It's as subtle as a 10 megaton nuclear

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 15.04.2017 00:04, Daniel Abrecht wrote: > I still think this isn't a problem the service manager should attempt to > solve. This is a situation where the database is temporary unavailable, > for which there are many possible reasons. The services which relay on > the database should be able to

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 15.04.2017 03:17, Steve Litt wrote: > Sounds like a good idea, but it's not, for the following reasons: > > 1) There will be endless arguments about HOW each and every daemon will >let its init system know "I'm now ready for business". The number of >different ways will make the

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 15.04.2017 11:42, Steve Litt wrote: > Once upon a time, daemon self-backgrounding was necessary, and this nohup (or something similar) was not sufficient ? I don't know when start-stop-daemon was incarnated (related to daemontools ?), but IMHO it seems to handle the daemonizing quite well.

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Sat, 15 Apr 2017 08:14:48 +0200 marc wrote: > > > Go on down your path, but I suspect not many people would cheer > > > at you in this camp... > > > > I can see the merit - on two points, technical and political. > > > > > On the technical side, I can see the

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

> > Go on down your path, but I suspect not many people would cheer at you > > in this camp... > > I can see the merit - on two points, technical and political. > > > On the technical side, I can see the usefulness of a system > wide standardised service status reporting - making it easy > for

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Fri, 14 Apr 2017 21:16:18 +0100 Simon Hobson wrote: > "Enrico Weigelt, metux IT consult" wrote: > > >> For those of us who put consistency above boot speed, simply > >> changing the init script so MySQL doesn't flag as "started" until > >>

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 2017-04-14 20:16, Simon Hobson wrote: > "Enrico Weigelt, metux IT consult" wrote: > >>> For those of us who put consistency above boot speed, simply changing >>> the init script so MySQL doesn't flag as "started" until the daemon >>> is up and ready to accept requests

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

"Enrico Weigelt, metux IT consult" wrote: >> For those of us who put consistency above boot speed, simply changing >> the init script so MySQL doesn't flag as "started" until the daemon >> is up and ready to accept requests would fix it; > > But then you'll have kind of

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Enrico Weigelt: > On 14.04.2017 12:06, k...@aspodata.se wrote: > > Enrico Weigelt: > > ... > >> Let's just take some example: libsrvmgt with funcs like that: > >> > >> * srvmgt_daemonize() > >> --> detach from controlling terminal, etc > > > > Why do any monitor program need to know if the

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Hi From my point of view, systemd always tries to keep services running, no matter how hard they fail, and to mask possible problems when starting a service, so the service maintainers don't have to fix their service, which is really unfortunate. In case of those service state notifications with

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 14.04.2017 12:17, Simon Hobson wrote: > For those of us who put consistency above boot speed, simply changing > the init script so MySQL doesn't flag as "started" until the daemon > is up and ready to accept requests would fix it; But then you'll have kind of daemon who watches mysql until

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 14.04.2017 12:29, Simon Hobson wrote: > But I also recognise that others aren't happy and if they want to > use something else then that's OK by me - as long as what they > propose isn't something that "infects" stuff I want to run under > SysVInit. Exactly my goal. sysvinit users would

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 14.04.2017 12:06, k...@aspodata.se wrote: > Enrico Weigelt: > ... >> Let's just take some example: libsrvmgt with funcs like that: >> >> * srvmgt_daemonize() >> --> detach from controlling terminal, etc > > Why do any monitor program need to know if the program has detached > or not, the

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

KatolaZ wrote: >> For start, we'd just write a small library, that logs to syslog, >> perhaps maintains some pidfiles (maybe even a *compile-time* option >> to route directly to libsystemd), then patch up packages that currently >> use libsystemd to use our new one. >> >

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

Enrico Weigelt: ... > Let's just take some example: libsrvmgt with funcs like that: > > * srvmgt_daemonize() > --> detach from controlling terminal, etc Why do any monitor program need to know if the program has detached or not, the only thing it needs to know is the pid and the state, which

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 14-04-17 11:20, KatolaZ wrote: On Fri, Apr 14, 2017 at 10:57:01AM +0200, Enrico Weigelt, metux IT consult wrote: [cut] * srvmgt_daemonize() --> detach from controlling terminal, etc * srvmgt_droppriv(...) --> drop root privileges (if we are still root) --> several versions, eg.

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On Fri, Apr 14, 2017 at 10:57:01AM +0200, Enrico Weigelt, metux IT consult wrote: [cut] > * srvmgt_daemonize() > --> detach from controlling terminal, etc > * srvmgt_droppriv(...) > --> drop root privileges (if we are still root) > --> several versions, eg. with fetching the target

[DNG] tiny service state api [WAS: Fwd: init system agnosticism]

On 13.04.2017 08:00, Joachim Fahrner wrote: > This is impossible with a binary distribution. systemd is not only an > init system, it pervades the whole system. You can either compile > packages with systemd libraries or without. But you have to decide that > at compile time. That's exactly what