On Sat, Dec 28, 2013 at 05:24:57PM -0800, Russ Allbery wrote:
I'll have more to say about the relative merits of the two init systems
later, but one thing I wanted to not briefly: this exercise was extremely
valuable in helping me get a more realistic picture of both init systems.
I had gone
]] 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.
On Sat, Dec 28, 2013 at 04:45:38PM -0800, Russ Allbery wrote:
After some more experimentation (the documentation doesn't say clearly
whether pre-start can expose environment variables to exec or not), it
looks like a better approach is:
expect stop
pre-start script
test -x
On Sat, Dec 28, 2013 at 03:56:49PM -0800, Russ Allbery wrote:
Also, the approach to the systemd integration introduces a new runtime
package dependency on init-system-helpers, which despite its
generic-sounding name actually contains only helpers for systemd and is
maintained in Debian by
Le dimanche 29 décembre 2013 à 01:10 -0800, Steve Langasek a écrit :
If I'm not mistaken (no references to hand - sorry), systemd upstream has
claimed in the course of discussions on debian-devel that lazy activation is
not the purpose of socket-based activation, and that using socket-based
On Sun, Dec 29, 2013 at 05:56:30AM +0200, Uoti Urpala wrote:
On Thu, 2013-12-26 at 21:42 +, Colin Watson wrote:
The first reason is, I suppose, rather selfish: I've been working on
this on and off for fourteen years and it seems a bit rude for systemd
to turn up and declare that it's
]] 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 power socket
On Sun, 2013-12-29 at 01:10 -0800, Steve Langasek wrote:
However, I think this gets to the heart of why upstart upstream has avoided
ever recommending the use of socket-based activation. There are some fairly
fundamental problems that basically halted development of socket-based
activation in
On Sun, Dec 29, 2013 at 11:21:07AM +0100, Josselin Mouette wrote:
Le dimanche 29 décembre 2013 à 01:10 -0800, Steve Langasek a écrit :
If I'm not mistaken (no references to hand - sorry), systemd upstream has
claimed in the course of discussions on debian-devel that lazy activation is
not
Steve Langasek vor...@debian.org writes:
This still leaves the concern I have about start-time races. According
to systemd.unit(5), using 'Requires=', as Uoti suggested to Russ, does
*not* guarantee ordering:
Note that requirement dependencies do not influence the order in which
On Sun, 2013-12-29 at 10:37 -0800, Steve Langasek wrote:
It's quite possible that I am doing something wrong, but I don't think this
is it. Each of the .service units in question already had
'WantedBy=multi-user.target', and each of the .socket units had
'WantedBy=sockets.target'; on Fedora
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
but as I said at the end of
https://lists.debian.org/debian-ctte/2013/12/msg00206.html there's an
automatic Before: dependency created from sockets to identically named
services. So it shouldn't be necessary to give it explicitly.
Ah! You did say
]] Russ Allbery
It would, however, be nice if this were more clearly stated, since the
guidance to the author of the unit file about what dependencies one should
or should not explicitly add is a bit sparse. In particular, I wonder if
there is an implicit After= dependency in a service unit
Tollef Fog Heen tfh...@err.no writes:
]] Russ Allbery
It would, however, be nice if this were more clearly stated, since the
guidance to the author of the unit file about what dependencies one should
or should not explicitly add is a bit sparse. In particular, I wonder if
there is an
Steve Langasek vor...@debian.org writes:
On Sat, Dec 28, 2013 at 05:24:57PM -0800, Russ Allbery wrote:
I'll have more to say about the relative merits of the two init systems
later, but one thing I wanted to not briefly: this exercise was extremely
valuable in helping me get a more realistic
Hello,
It's already been mentioned elsewhere, but I think it should be included in
this bug for reference. The minimum code to support systemd style readyness
notification is (from
https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/37AWJLE3XcJ):
static void notify(const char
On Sun, 2013-12-29 at 14:02 +, Colin Watson wrote:
I was referring more to Tollef's position, really. Debian systemd
maintenance ought to take into account matters of Debian integration,
which includes whether it fits well into best-of-breed Debian practice.
If it's easy enough to
Ian Jackson ijack...@chiark.greenend.org.uk writes:
It does, however, have a number of missing features. Those I have in
mind are:
- ability to log daemon output to syslog
- multiple socket activation (systemd socket activation protocol)
- socket activation for IPv6 (and datagram
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
We seem to be at the point of the process where at least those of us who
did early investigation are stating conclusions. I think I have enough
information to state mine, so will attempt to do so here.
This is probably going to be rather long, as there were quite a few
factors that concerned me
Steve Langasek vor...@debian.org wrote:
However, I think this gets to the heart of why upstart upstream has avoided
ever recommending the use of socket-based activation. There are some fairly
fundamental problems that basically halted development of socket-based
activation in upstart, and a
On Sun, Dec 29, 2013 at 01:43:59PM -0800, Nikolaus Rath wrote:
I'm a bit surprised that you mention this only now, after Russ'
extensive mail. Could you tell us if there are there other components in
systemd that you think are similarly flawed,
Why should it have been mentioned before now? I
22 matches
Mail list logo
