Steve Langasek vor...@debian.org writes:
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 (beyond
To wrap up this subthread, I want to state clearly for the record that the
answers that have been given here have addressed my concerns about the
raciness of systemd socket activation. It appears that the state of the art
is rather substantially improved since the last time I had looked at
On Sat, 28 Dec 2013 at 16:45:38 -0800, Russ Allbery wrote:
The second supported option is DAEMON_OPTS, which sets additional flags to
add to the process. For as long as we need to support multiple init
systems, this option needs to stay in /etc/default/lbcd and be read from
there by all
Simon McVittie s...@debian.org writes:
On Sat, 28 Dec 2013 at 16:45:38 -0800, Russ Allbery wrote:
The second supported option is DAEMON_OPTS, which sets additional flags
to add to the process. For as long as we need to support multiple init
systems, this option needs to stay in
On Tue, Dec 31, 2013 at 08:44:15AM -0800, Russ Allbery wrote:
I'd like to suggest that this should only be done for daemons where
there is anything that a sysadmin can sensibly configure in this
way. The patch proposed for #712167 (native Upstart init support in
dbus) did this, but after
Le dimanche 29 décembre 2013 à 22:50 -0800, Steve Langasek a écrit :
Socket-based activation has never been a feature that upstart upstream has
promoted the use of.
I am a bit confused here. You wrote in the upstart position statement,
almost at the top:
“Upstart supports both bus
Josselin,
I actually added that to the statement. I did so because it has
legitimate uses, and because it is something that a number of people
have expressed interest in using.
Best regards,
Cameron Norman
On Tue, Dec 31, 2013 at 5:56 PM, Josselin Mouette j...@debian.org
wrote:
Le dimanche
Le mercredi 01 janvier 2014 à 01:54 -0008, cameron a écrit :
On Tue, Dec 31, 2013 at 5:56 PM, Josselin Mouette j...@debian.org
wrote:
I am a bit confused here. You wrote in the upstart position
statement, almost at the top: “Upstart supports both bus activation
and socket activation.”
I
On Wed, Jan 01, 2014 at 01:54:17AM -0008, cameron wrote:
I actually added that to the statement. I did so because it has
legitimate uses, and because it is something that a number of people
have expressed interest in using.
Right, I never wrote that. I've reverted these changes to the
Steve,
I am very sorry, I did not see the paragraph. I will familiarize myself
with the debate system before contributing to it again.
Happy New Years,
Cameron Norman
On Tue, Dec 31, 2013 at 6:21 PM, Steve Langasek vor...@debian.org
wrote:
On Wed, Jan 01, 2014 at 01:54:17AM -0008, cameron
Steve Langasek vor...@debian.org writes:
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
On Sun, Dec 29, 2013 at 10:05:17PM +0100, Tollef Fog Heen wrote:
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
]] Steve Langasek
I'm also interested to know how systemd purports to handle the exceptional
cases, where a dependency on basic.target is not possible.
In general «you need to write the dependencies manually, then». As
you're pointing out in your mail, that can get tricky to get right.
On Sat, Dec 28, 2013 at 10:31:32PM -0800, Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Adding the mentioned Requires=lbcd.socket line should ensure that the
service is never started without the socket running. I'm quite sure that
daemons intended to run under systemd
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
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
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, 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
Steve Langasek vor...@debian.org writes:
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
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:
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 activation does not require
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
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
Resending this message, slightly edited, since Don pointed me in the right
direction to figure out the erroneous virus definition and work around it.
I've been continuing down the path of adding as complete of systemd and
upstart support as is feasible to one of my packages, and have started
I have now uploaded lbcd 3.5.0-1 to the archive. This contains what I
believe to be a full implementation of systemd and upstart compatibility
for a UDP-based daemon from both an upstream and packaging perspective,
including dealing with some upgrade issues from previous bad decisions I'd
made
Russ Allbery r...@debian.org writes:
I have now uploaded lbcd 3.5.0-1 to the archive.
And now lbcd 3.5.0-2, because I completely forgot to add the stanzas to
the systemd unit and upstart configuration file to run lbcd as a non-root
user. Whoops. (And, of course, I noticed one more problem
On Sat, 2013-12-28 at 17:24 -0800, Russ Allbery wrote:
* systemd synchronization support added via sd_notify.
* systemd socket activation support.
Does sd_notify() actually give any positive effect compared to just
using type=simple, given that you already have socket activation? The
UDP socket
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Does sd_notify() actually give any positive effect compared to just
using type=simple, given that you already have socket activation? The
UDP socket should buffer packets until the daemon reads them. Explicit
notify does have the negative effect
On Sat, 2013-12-28 at 21:29 -0800, Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Does sd_notify() actually give any positive effect compared to just
using type=simple, given that you already have socket activation? The
UDP socket should buffer packets until the daemon
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Adding the mentioned Requires=lbcd.socket line should ensure that the
service is never started without the socket running. I'm quite sure that
daemons intended to run under systemd should have no need to implement
any socket-opening code themselves
35 matches
Mail list logo
