Zbigniew Jędrzejewski-Szmek writes:
>> As I understand, a systemd unit with "Requires=jobTwo" will not start
>> without jobTwo running.
>
> If you request the start of "jobOne", without "jobTwo" running,
> systemd will start "jobTwo" in addition to "jobOne".
>
> There's also a Requisite= dependenc
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
> As I understand, a systemd unit with "Requires=jobTwo" will not start
> without jobTwo running.
If you request the start of "jobOne", without "jobTwo" running,
systemd will start "jobTwo" in addition to "jobOne".
There's also a Requisite= dependency, where if "jobTwo" isn't runnning,
starting "j
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, Jan 1, 2014 at 3:40 PM, Chris Knadle wrote:
>> I appreciate the explanation, and I'm familiar with the contents of the
>> decision. I simply see nothing there that should have motivated a
>> tech-ctte decision, rather than simply a couple of bug reports against
>> network-manager and an ad
On Wed, Jan 01, 2014 at 09:37:24PM +, Ian Jackson wrote:
> Josh Triplett writes ("Re: Bug#727708: init system other points, and
> conclusion"):
> > On Wed, Jan 01, 2014 at 03:40:17PM -0500, Chris Knadle wrote:
> > > In other words, what you're saying is that not only [something
> > > about Net
Josh Triplett writes ("Re: Bug#727708: init system other points, and
conclusion"):
> On Wed, Jan 01, 2014 at 03:40:17PM -0500, Chris Knadle wrote:
> > In other words, what you're saying is that not only [something
> > about NetworkManager]
>
> It's fairly clear that NetworkManager [something some
On Wed, Jan 01, 2014 at 03:40:17PM -0500, Chris Knadle wrote:
> On Wednesday, January 01, 2014 08:47:13 Josh Triplett wrote:
> > On Wed, Jan 01, 2014 at 08:09:56AM -0500, Chris Knadle wrote:
> > > On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote:
> > > > Steve Langasek wrote:
> > > > >On
On Wednesday, January 01, 2014 08:47:13 Josh Triplett wrote:
> On Wed, Jan 01, 2014 at 08:09:56AM -0500, Chris Knadle wrote:
> > On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote:
> > > Steve Langasek wrote:
> > > >On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
> > > >>
On Wed, 2014-01-01 at 05:48 +0100, Mourad De Clerck wrote:
> So last time I tried, this just worked - my rootfs got mounted using a
> keyscript in the initramfs, and there were no problems, not a peep from
> systemd when it took over, no re-setup or anything.
Sure... but that applies, AFAIU, only
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 1, 2014 at 4:56 AM, Colin Watson wrote:
> On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote:
> > On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson
> > >inotify is used to notice changes to configuration files. This is
> > >certainly helpful for users, but it isn't critical as "ini
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 30 Dec 2013, at 18:47, Russ Allbery wrote:
> However, I think it's the best available approach that balances our ideals
> as a project against the opportunities offered by a new init system. This
> approach does permit full use of new init system features for jessie
> except for eliminating /e
On Wed, Jan 01, 2014 at 08:09:56AM -0500, Chris Knadle wrote:
> On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote:
> > Steve Langasek wrote:
> > >On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
> > >> So unless the TC wants to remove a great number of packages from the
>
Hi,
Ian Jackson wrote (31 Dec 2013 16:58:17 GMT) :
> I think you have misunderstood. Or perhaps I hae misunderstood you.
> The "work" that I'm saying needs to be done anyway is the work to
> disentange the parts of systemd which are required by (say) GNOME from
> the parts which are only relevant
On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote:
> Steve Langasek wrote:
> >On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
> >> So unless the TC wants to remove a great number of packages from the
> >> archive, you need to take into account the fact that some voluntary
On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote:
> On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson
> >inotify is used to notice changes to configuration files. This is
> >certainly helpful for users, but it isn't critical as "initctl
> >reload-configuration" works without it. We could prob
On Tue, Dec 31, 2013 at 10:18:08PM -0800, Russ Allbery wrote:
> For upstart readiness, obviously one needs some sort of explicit flag or
> trigger to enable the raise(SIGSTOP) behavior, since that will otherwise
> cause rather obvious problems in getting the daemon to work outside of
> upstart. I
On Tue, Dec 31, 2013 at 07:08:34PM -0800, Steve Langasek wrote:
> On Tue, Dec 31, 2013 at 11:15:33AM -0800, Russ Allbery wrote:
> > Similarly, I'm not sure why the focus on only adding necessary tools to
> > the initramfs image. Surely this doesn't matter much if the tools are
> > harmless when un
]] Ian Jackson
> (Sorry, 2nd copy here because I missed up the change of To field in
> the previous one.)
>
> cameron writes ("Re: Bug#733452: init system daemon readiness protocol"):
> > I was curious: why should SOCK_STREAM be used instead of SOCK_DGRAM in
> > your proposed protocol?
>
> SOC
26 matches
Mail list logo
