Brett Neumeier:
It's maybe a little heavy-handed, but is there any technical reason
not to just pick an arbitrary FD, like say 3, and just always use that
for a particular daemon?
Further to what M. Bercot said, see
https://unix.stackexchange.com/a/331104/5132 .
It's maybe a little heavy-handed, but is there any technical reason not to
just pick an arbitrary FD, like say 3, and just always use that for a
particular daemon?
For a given daemon, no, there's no reason not to pick an arbitrary fd
and stick to it. That's the intended usage.
For a
On Sat, Apr 4, 2020 at 5:18 PM Serge E. Hallyn wrote:
> > On the daemon side, you can use any option you like to tell the daemon
> > what fd it should write to. It has nothing to do with s6, and I have no
> > recommended policy for daemons.
>
It's maybe a little heavy-handed, but is there any
On Sat, Apr 04, 2020 at 09:29:04PM +, Laurent Bercot wrote:
>
> > Yes it sounds like I completely misread the earlier emails, sorry about
> > that. Now, looking at http://skarnet.org/software/s6/notifywhenup.html,
> > I'm probably not reading that quite right, but it seems to tie the
> >
Yes it sounds like I completely misread the earlier emails, sorry about
that. Now, looking at http://skarnet.org/software/s6/notifywhenup.html,
I'm probably not reading that quite right, but it seems to tie the
proposal to the 'notifcation-fd' file in the service directory, making
it a bit
On Fri, Apr 03, 2020 at 07:41:25AM +, Jonathan de Boyne Pollard wrote:
> Serge E. Hallyn:
>
> > If making changes to daemons were going to palatable, [...]
> >
>
> Clearly, it *is* palatable, given that a few people have been adding the
> systemd mechanism to their programs for several
On Wed, Apr 01, 2020 at 05:13:06PM +, Laurent Bercot wrote:
>
> > There are pros and cons, but you are arguing for parsing stdout for a
> > text message and/or using pidfiles (written to an fd).
>
> I'm arguing for none of these things.
> I'm arguing for daemons to write a newline to a fd
Serge E. Hallyn:
If making changes to daemons were going to palatable, [...]
Clearly, it *is* palatable, given that a few people have been adding the
systemd mechanism to their programs for several years, now.
Pierre-Yves Ritschard's code and Cameron Norman's code come straight out
of
There are pros and cons, but you are arguing for parsing stdout for a
text message and/or using pidfiles (written to an fd).
I'm arguing for none of these things.
I'm arguing for daemons to write a newline to a fd of their choice,
which is hardly anything difficult. And hardly anything
On Wed, Apr 01, 2020 at 03:59:25PM +, Laurent Bercot wrote:
> > You'd have to buy into it with a syscall that says "let me know when
> > something listens on tcp port N". In turn s6-supervise would only do
> > that if some config said "don't start service Y until something (which
> > is
You'd have to buy into it with a syscall that says "let me know when
something listens on tcp port N". In turn s6-supervise would only do
that if some config said "don't start service Y until something (which
is expected to be service X) proves it's ready by listening on port N".
The idea was to
On Wed, Apr 01, 2020 at 03:06:49PM +, Laurent Bercot wrote:
> > I've been considering for several years trying to push a kernel patch
> > which would provide a way for userspace to find out when someone starts
> > listening on some port. Based on problems I saw long ago in the late
> > days
I've been considering for several years trying to push a kernel patch
which would provide a way for userspace to find out when someone starts
listening on some port. Based on problems I saw long ago in the late
days of upstart and early days of systemd, that seemed like it would
solve a not
I am curious, does anyone on this list know of examples of such daemons? I
am considering creating and submitting patches for some daemon programs
that I use that do *not* support this mechanism as yet, and am curious if
it is as simple as it looks like it should be.
- I'm trying to make it so
I've been considering for several years trying to push a kernel patch
which would provide a way for userspace to find out when someone starts
listening on some port. Based on problems I saw long ago in the late
days of upstart and early days of systemd, that seemed like it would
solve a not
On Wed, Apr 01, 2020 at 08:23:26AM -0500, Brett Neumeier wrote:
> I am curious, does anyone on this list know of examples of such daemons? I
> am considering creating and submitting patches for some daemon programs
> that I use that do *not* support this mechanism as yet, and am curious if
> it is
16 matches
Mail list logo
