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
Fedora'
Steve Langasek 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 merging of Sc
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
wrote:
On Wed, Jan 01, 2014 at 01:54:17AM -0008, cameron wrote:
I actuall
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 posit
Le mercredi 01 janvier 2014 à 01:54 -0008, cameron a écrit :
> On Tue, Dec 31, 2013 at 5:56 PM, Josselin Mouette
> 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 actua
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
wrote:
Le dimanche 29 décembre 201
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 acti
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
Simon McVittie 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 /etc/default/lbcd and
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 su
Steve Langasek 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 should it h
]] 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 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
>
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?
Steve Langasek 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 picture of
Tollef Fog Heen 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 implicit
]] 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 u
Uoti Urpala 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 this, and I forgot
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 Fedor
Steve Langasek 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
> services are starte
Steve Langasek 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 you to pay the
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
>
Steve Langasek 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 stop
>>
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
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 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
> tes
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 go
On Sat, Dec 28, 2013 at 10:31:32PM -0800, Russ Allbery wrote:
> Uoti Urpala 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
Uoti Urpala 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 (unless they do some
On Sat, 2013-12-28 at 21:29 -0800, Russ Allbery wrote:
> Uoti Urpala 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
Uoti Urpala 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 that depending services
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 socke
Russ Allbery 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 after that
upload,
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 (as
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
worki
35 matches
Mail list logo
