Tollef Fog Heen writes:
> I believe you can do this fairly easily.
> A is the service that needs to be reloaded when a network device shows
> up. In A's service file, have ReloadPropagatedFrom=network.target and
> then make your ifup@.service include an ExecStart=systemctl reload
> network.targ
Anthony Towns writes:
> I think this would be most analogous to the "complex conditions" bit,
> where you'd say
> start on Y and Q
> so that it will only be started when event "Q" happens if "Y" has also
> already happened. I don't see how you'd prevent it from being manually
> started withou
]] Russ Allbery
> That, however, is also a good point. This specific case is the place
> where an event model does have a clear advantage. It looks like the
> preferred strategy in the systemd model is to teach daemons to watch for
> this themselves, which while certainly a good idea (most high
On 18 January 2014 17:19, Russ Allbery wrote:
> It's worth noting that even the second solution above does not allow
> simulation of systemd's Requisite=, only Requires=. Now, normally
> Requires= (when starting X, start Y if not already started) is going to be
> fine, but I can certainly imagine
Anthony Towns writes:
> To emulate systemd dependencies in an event model (ie, X depends on
> Y), you'd need to do either:
> * change Y's job to say "start on starting X"
> * add "stop on stopping Y" to X's job description
> or
> * add a pre-start script to X in order to start Y fi
Anthony Towns writes:
> To emulate systemd dependencies in an event model (ie, X depends on
> Y), you'd need to do either:
>
> * change Y's job to say "start on starting X"
> * add "stop on stopping Y" to X's job description
>
> or
>
> * add a pre-start script to X in order to start Y
On Fri, Jan 17, 2014 at 12:50 AM, Anthony Towns wrote:
> On 31 December 2013 12:55, Colin Watson wrote:
> > The criticisms of Upstart's event model in the systemd position
> > statement simply do not make sense to me. Events model how things
> > actually happen in reality; dependencies are arti
On 31 December 2013 12:55, Colin Watson wrote:
> The criticisms of Upstart's event model in the systemd position
> statement simply do not make sense to me. Events model how things
> actually happen in reality; dependencies are artificial constructions on
> top of them, and making them work requi
Hello,
I am aware that this bug already has a lot of emails in it, but I think
the issue below is important enough to warrant a
*ping*
to the upstart developers. It would be great if someone could comment on
this.
Best
Nikolaus
Nikolaus Rath writes:
> Cameron Norman writes:
>> On Wed, Jan 1
Russ Allbery writes:
> However, that said, I believe the integration of systemd will actually
> be easier in the long run because upstart is rather... weird.
On that front, I also wanted to ask about:
https://bugs.launchpad.net/upstart/+bug/447654
If I'm understanding this bug correctly, i
Steve Langasek writes:
> The purpose of failsafe.conf is to ensure that services which have not
> been converted to the native format, but instead provide initscripts
> that are called upon reaching runlevel 2, are started at the right time
> - so that they aren't unreliable due to racing the net
On Thu, 02 Jan 2014, Steve Langasek wrote:
> our users. If we decide for systemd, what do you think is the right way to
> mitigate such problems for jessie? Some of these issues are only going to
> be seen once people start making use of systemd in anger with their existing
> server configs (e.g.
Hi,
first, thank you for describing this problem in details.
I have never met it while using systemd on Debian Wheezy and sid for
18 months. Anyhow, with your indications at hand, I realize that my
use cases probably fall into the category that does not expose
this problem.
Steve Langasek wrote
On Mon, Dec 30, 2013 at 09:52:04PM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > Upstart (as implemented in Ubuntu) restores this guarantee (with
> > provisions for failsafe booting in the case of a wrong network config),
> > and it takes advantage of upstart's capability of sending arb
]] Colin Watson
> Perhaps this is the fundamental disagreement. I do not necessarily
> consider compatibility as an end in itself. Where Debian is already
> better than other distributions, we should remain better, not stick to a
> lowest common denominator for the sake of compatibility.
I thi
On Thu, 2014-01-02 at 12:31 +, Colin Watson wrote:
> On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
> > You can simply not install any of these additional services if you don't
> > want them. This is completely trivial to do.
>
> It is indeed technically trivial, but I invite you
On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
> On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote:
> > On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
> > > On the other hand even when using upstart as an init replacement, we'll
> > > continue to use large chunk
Hi Colin,
Le mercredi 01 janvier 2014 à 17:17 +, Colin Watson a écrit :
> > > Basically, systemd would be more compelling to me if it tried to do
> > > less. I don't expect to persuade systemd advocates of this, as I think
> > > it amounts to different basic views of the world, but the basic
Cameron Norman writes:
>> > I think you raise a lot of good points in this email, but here you
>> > are saying something which may demonstrate your (understandable)
>> > confusion about the Upstart event model. Upstart does not treat
>> > dependencies as events. Often times, Upstart //jobs// treat
On Wed, Jan 1, 2014 at 5:09 PM, Nikolaus Rath wrote:
> Cameron Norman writes:
> > On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath wrote:
> >
> >> Colin Watson writes:
> >> > The criticisms of Upstart's event model in the systemd position
> >> > statement simply do not make sense to me. Events m
Cameron Norman writes:
> On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath wrote:
>
>> Colin Watson writes:
>> > The criticisms of Upstart's event model in the systemd position
>> > statement simply do not make sense to me. Events model how things
>> > actually happen in reality; dependencies are a
On 01/01/2014 04:00 PM, Nikolaus Rath wrote:
> My second point is that by treating dependencies as events, upstart does
> not seem to truly recognize dependencies as such and is then unable to
> resolve them. For example, with the following two job files (created
> according to the upstart cookboo
On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath wrote:
> Colin Watson writes:
> > The criticisms of Upstart's event model in the systemd position
> > statement simply do not make sense to me. Events model how things
> > actually happen in reality; dependencies are artificial constructions on
> >
Colin Watson writes:
> The criticisms of Upstart's event model in the systemd position
> statement simply do not make sense to me. Events model how things
> actually happen in reality; dependencies are artificial constructions on
> top of them, and making them work requires the plethora of differ
On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote:
> On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
> > Colin Watson writes:
> > > Basically, systemd would be more compelling to me if it tried to do
> > > less. I don't expect to persuade systemd advocates of this, as I thin
On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
> Colin Watson writes:
> > Reservations with systemd
> > -
> [...]
> > Basically, systemd would be more compelling to me if it tried to do
> > less. I don't expect to persuade systemd advocates of this, as I
Hi,
Colin Watson writes:
> Reservations with systemd
> -
[...]
> Basically, systemd would be more compelling to me if it tried to do
> less. I don't expect to persuade systemd advocates of this, as I think
> it amounts to different basic views of the world, but the basic
On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson
wrote:
The criticisms of Upstart's event model in the systemd position
statement simply do not make sense to me. Events model how things
actually happen in reality; dependencies are artificial constructions
on
top of them, and making them work r
]] Steve Langasek
> > In any case, systemd does indeed "support" this case; simply make your
> > service depend on network-online.target, which will block for a
> > reasonable amount of time to see if a network interface comes online,
> > and eventually time out if that doesn't occur. This will
On Mon, Dec 30, 2013 at 10:04:09PM -0800, Russ Allbery wrote:
> Oh, sorry, I forgot to respond to this part.
> Steve Langasek writes:
> > Of course if we were writing all our services according to best
> > practices, we wouldn't have to worry about this, as the service would
> > just handle this
Oh, sorry, I forgot to respond to this part.
Steve Langasek writes:
> Of course if we were writing all our services according to best
> practices, we wouldn't have to worry about this, as the service would
> just handle this gracefully (or maybe hand the complexity off to the
> init system for s
Steve Langasek writes:
> Upstart (as implemented in Ubuntu) restores this guarantee (with
> provisions for failsafe booting in the case of a wrong network config),
> and it takes advantage of upstart's capability of sending arbitrary
> signals to do so. I can see how one could implement the equi
On Mon, Dec 30, 2013 at 07:26:23PM -0800, Russ Allbery wrote:
> > (Now, I've been working with Upstart's model for years, and it's now a
> > pretty fundamental way of how I think of system operation; so if people
> > who are new to *both* models rather than partisans of one side or the
> > other co
On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson
wrote:
The ptrace arrangements used for "expect fork" and "expect daemon"
have
been rather flaky in practice, especially when Upstart jobs are
written
by people not experts in doing so, and they are an obstacle to
portability. I think we shou
On Tue, 2013-12-31 at 02:55 +, Colin Watson wrote:
> My main concerns with systemd relate to its broad scope regarding units
> it provides for system initialisation tasks currently performed by other
> packages, and the potential for that to interfere with past and future
> work elsewhere in De
Colin Watson wrote:
> (Now, I've been working with Upstart's model for years, and it's now a
> pretty fundamental way of how I think of system operation; so if people
> who are new to *both* models rather than partisans of one side or the
> other consistently tell me that the systemd model is easie
Thanks for this write-up, Colin. This was very interesting to me,
particularly in the concrete examples of where you've felt like systemd
has stepped into areas that will pose integration problems for us. This
is something that I've seen referred to in the abstract frequently, but
without a lot o
I see that the LWN commentariat already has my decision selected in
advance, so I might as well write up some more detailed thoughts before
any other words are put into my mouth!
Choice of default
-
Firstly, I've tried to keep my employer affiliation out of this as much
as possib
38 matches
Mail list logo