]] Ian Jackson
> (Sorry, 2nd copy here because I missed up the change of To field in
> the previous one.)
>
> cameron writes ("Re: Bug#733452: init system daemon readiness protocol"):
> > I was curious: why should SOCK_STREAM be used instead of SOCK_DGRAM in
On Mon, Dec 30, 2013 at 9:38 AM, Ian Jackson
wrote:
(Sorry, 2nd copy here because I missed up the change of To field in
the previous one.)
cameron writes ("Re: Bug#733452: init system daemon readiness
protocol"):
I was curious: why should SOCK_STREAM be used instead of SOCK
(Sorry, 2nd copy here because I missed up the change of To field in
the previous one.)
cameron writes ("Re: Bug#733452: init system daemon readiness protocol"):
> I was curious: why should SOCK_STREAM be used instead of SOCK_DGRAM in
> your proposed protocol?
SOCK_DGRAM sock
Tollef Fog Heen writes ("Bug#733452: init system daemon readiness protocol"):
> Ian Jackson:
> > I conclude therefore that we should design another simple protocol -
> > preferably, a variation on one of the existing ones - and have (at
> > least) both Debian
Hello Mr. Jackson,
I was curious: why should SOCK_STREAM be used instead of SOCK_DGRAM in
your proposed protocol?
Have you seen Lennart Poettering's pastebin of a short daemon side
implementation of that protocol: http://fpaste.org/64821/32737713/? It
meets all your desired criteria, it is u
]] Tollef Fog Heen
> ]] Ian Jackson
>
> > I conclude therefore that we should design another simple protocol -
> > preferably, a variation on one of the existing ones - and have (at
> > least) both Debian's systemd and Debian's upstart implement it.
>
> I think you're into ever-multiplying pow
]] Ian Jackson
> I conclude therefore that we should design another simple protocol -
> preferably, a variation on one of the existing ones - and have (at
> least) both Debian's systemd and Debian's upstart implement it.
I think you're into ever-multiplying power socket standards territory
here.
Ian Jackson writes:
> (I have cloned the bug for this, to keep this particular
> sub-discussion separable.)
>
> As I have reported, we have a problem with non-forking daemon
> readiness protocols.
"We have a problem" seems a bit exxagerated to me. So far, the only
problem that I have seen is that
Ian Jackson writes:
> The systemd protocol is troublesome because it requires too much code
> in the daemon, leaving the daemon author with the trilemma which has
> previously been discussed.
This statement as written is only true if you're unwilling to link with a
shared library, a stance that
(I have cloned the bug for this, to keep this particular
sub-discussion separable.)
As I have reported, we have a problem with non-forking daemon
readiness protocols.
There are two competing protocols that I'm aware of (not counting the
protocol implied by daemon(3)): upstart's, where the daemon
10 matches
Mail list logo
