]] 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
Anthony Towns a...@erisian.com.au 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
Tollef Fog Heen tfh...@err.no 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
On 31 December 2013 12:55, Colin Watson cjwat...@debian.org 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
On Fri, Jan 17, 2014 at 12:50 AM, Anthony Towns a...@erisian.com.au wrote:
On 31 December 2013 12:55, Colin Watson cjwat...@debian.org 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
Anthony Towns a...@erisian.com.au 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
Anthony Towns a...@erisian.com.au 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
On 18 January 2014 17:19, Russ Allbery r...@debian.org 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
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 nikol...@rath.org writes:
Cameron Norman
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.,
Steve Langasek vor...@debian.org 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
Russ Allbery r...@debian.org 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
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
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 chunks of
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 to
]] 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 think
On Mon, Dec 30, 2013 at 09:52:04PM -0800, Russ Allbery wrote:
Steve Langasek vor...@debian.org 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
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
Hi,
Colin Watson cjwat...@debian.org 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,
On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
Colin Watson cjwat...@debian.org 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
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 cjwat...@debian.org writes:
Basically, systemd would be more compelling to me if it tried to do
less. I don't expect to persuade systemd advocates of
Colin Watson cjwat...@debian.org 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
On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath nikol...@rath.org wrote:
Colin Watson cjwat...@debian.org 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
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 cookbook,
Cameron Norman camerontnor...@gmail.com writes:
On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath nikol...@rath.org wrote:
Colin Watson cjwat...@debian.org writes:
The criticisms of Upstart's event model in the systemd position
statement simply do not make sense to me. Events model how things
On Wed, Jan 1, 2014 at 5:09 PM, Nikolaus Rath nikol...@rath.org wrote:
Cameron Norman camerontnor...@gmail.com writes:
On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath nikol...@rath.org wrote:
Colin Watson cjwat...@debian.org writes:
The criticisms of Upstart's event model in the systemd
Cameron Norman camerontnor...@gmail.com 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
]] 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 actually
On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson cjwat...@debian.org
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,
Steve Langasek vor...@debian.org 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
Oh, sorry, I forgot to respond to this part.
Steve Langasek vor...@debian.org 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
On Mon, Dec 30, 2013 at 10:04:09PM -0800, Russ Allbery wrote:
Oh, sorry, I forgot to respond to this part.
Steve Langasek vor...@debian.org 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
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
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
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 easier
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
On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson cjwat...@debian.org
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.
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
38 matches
Mail list logo
