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 c
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 s
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 set
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 that
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 p
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 p
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
Il 18/04/2017 23:10, Alessandro Selli ha scritto:
> 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, out
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.
>>
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.
>
We have seen what an irresistible avala
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...
>>
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 dae
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
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 becomes
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 commun
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
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
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
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
mai
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 on
On Tue, Apr 18, 2017 at 03:11:51PM +0200, k...@aspodata.se wrote:
[cut]
>
> > I was also been ironic on Aspo, as many times he can only counter
> > another person's ideas asking "What if cannot be trusted?",
> > as if this constitutes a valid argument against being able to set
> > policies for
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
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 on the
same host? DOES it demand that?
This isn't a good thing to spend
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
On Tue, Apr 18, 2017 at 01:32:01PM +0200, Adam Borowski wrote:
[cut]
> >
> > This is a totally wrong assumption. Being a sysadmin is all about
> > setting and implementing *policies*. And the choice between systemd or
> > anything else is exactly a matter of policy. So yes, a sysadmin *must*
> >
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?
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?
>>
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. Being a sysadmin is all a
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 us
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 contr
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 monit
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 desk
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 requires
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 perhaps
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 progra
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 combined
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
bei
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
> > > consult wrote:
>
> > > > By
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 clie
> > 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 fr
> 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
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
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 ...
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
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 pers
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 t
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 seem
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 fo
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
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 to have your daemon p
> 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 f
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 the fork-parent() functi
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 Techniques
of the Succ
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 completely different set
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 dev
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
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 number
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.
I
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 usefulness of a system
> >
> > 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 on
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
> >> the daemon is up and ready to accept requests would
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 would fix it;
>> But then
"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 daemon who watches mysql
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 progr
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
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 it'
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 proba
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 only
k...@aspodata.se wrote:
> Given the choises given, it seems that the target of the monitor is
> network servers. Couldn't the monitor find out the ready_local,
> ready_all and shutdown by itself by monitoring which ports are open ?
...
> And, what if the monitor cannot trust the program it monit
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.
>>
>
> I personally don't se
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 wo
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. wi
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 uid/gid
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
74 matches
Mail list logo
