Am 04.02.2015 um 22:31 schrieb Lennart Poettering:
On Wed, 04.02.15 22:25, Reindl Harald (h.rei...@thelounge.net) wrote:
Am 04.02.2015 um 21:57 schrieb Lennart Poettering:
OK, let's try this again, with an example:
a) you have one service mydaemon.service
b) you have a preparation service
On Wed, 04.02.15 22:25, Reindl Harald (h.rei...@thelounge.net) wrote:
> Am 04.02.2015 um 21:57 schrieb Lennart Poettering:
> >OK, let's try this again, with an example:
> >
> >a) you have one service mydaemon.service
> >
> >b) you have a preparation service called
> >mydaemon-convert-config.se
Am 04.02.2015 um 21:57 schrieb Lennart Poettering:
OK, let's try this again, with an example:
a) you have one service mydaemon.service
b) you have a preparation service called
mydaemon-convert-config.service that takes config from somewhere,
converts it into a suitable format for myda
On Tue, 03.02.15 23:03, Michael Biebl (mbi...@gmail.com) wrote:
> > While I just made this scenario up I think it's actually quite
> > realistic, and I think it's a valid thing for admins to do
>
> Well, we could easily check if DefaultDependencies=yes in this case.
> Actually, this is alread
2015-02-03 22:38 GMT+01:00 Lennart Poettering :
> On Tue, 03.02.15 22:22, Michael Biebl (mbi...@gmail.com) wrote:
>
>> 2015-02-03 22:10 GMT+01:00 Lennart Poettering :
>> > I don't see how this would apply to non-sysv code. I mean, code that
>> > is written with systemd semantics in mind should be a
On Tue, 03.02.15 22:22, Michael Biebl (mbi...@gmail.com) wrote:
> 2015-02-03 22:10 GMT+01:00 Lennart Poettering :
> > I don't see how this would apply to non-sysv code. I mean, code that
> > is written with systemd semantics in mind should be able to issue a
> > service reload during any time it w
2015-02-03 22:10 GMT+01:00 Lennart Poettering :
> I don't see how this would apply to non-sysv code. I mean, code that
> is written with systemd semantics in mind should be able to issue a
> service reload during any time it wants to, if it keeps the ordering
> issues in mind. For example, if I hav
On Tue, 03.02.15 21:58, Michael Biebl (mbi...@gmail.com) wrote:
> 2015-02-03 21:52 GMT+01:00 Lennart Poettering :
> >
> > But note that this way you alter *all* queued jobs that way,
> > regardless if they are created with the assumptions of sysv behaviour
> > or if they were created in code that
2015-02-03 21:52 GMT+01:00 Lennart Poettering :
>
> But note that this way you alter *all* queued jobs that way,
> regardless if they are created with the assumptions of sysv behaviour
> or if they were created in code that understands systemd's semantics,
> and actually cares for the correct order
On Tue, 03.02.15 20:50, Michael Biebl (mbi...@gmail.com) wrote:
> >> Another option might be to pass --job-mode=ignore-dependencies instead
> >> of --no-block, which was created for usecases like this, even though
> >> it is frickin' ugly...
> >
> > For reload that should be fairly okay, as reload
On Tue, 03.02.15 20:36, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Lennart Poettering [2015-02-03 18:10 +0100]:
> > I am very strongly against adding hacky work-arounds like this to PID
>
> Yeah, indeed. This is why I asked for a more elegant approach, and
> indeed the --no-block or --job-mode
2015-02-03 20:36 GMT+01:00 Martin Pitt :
> Lennart Poettering [2015-02-03 18:10 +0100]:
>> I am very strongly against adding hacky work-arounds like this to PID
>
> Yeah, indeed. This is why I asked for a more elegant approach, and
> indeed the --no-block or --job-mode=ignore-dependencies sound lik
Lennart Poettering [2015-02-03 18:10 +0100]:
> I am very strongly against adding hacky work-arounds like this to PID
Yeah, indeed. This is why I asked for a more elegant approach, and
indeed the --no-block or --job-mode=ignore-dependencies sound like
slightly better approaches to this. I'll test t
On Tue, 03.02.15 18:01, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Lennart Poettering [2015-02-03 17:29 +0100]:
> > Hmm, why precisely does this stall for 90s?
>
> The current transaction has final.target and all other jobs which need
> to be shut down. One of these now trigger "systemctl rel
Lennart Poettering [2015-02-03 17:29 +0100]:
> Hmm, why precisely does this stall for 90s?
The current transaction has final.target and all other jobs which need
to be shut down. One of these now trigger "systemctl reload
postfix.service", but that reload isn't going to actually run in the
same t
On Tue, 03.02.15 17:26, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Hey all,
>
> I'm currently reviewing our Debian patches for systemd, and came
> across this one which sounds important for other distributions, too.
> This was reported and fixed two years ago in
> https://bugs.debian.org/63577
Hey all,
I'm currently reviewing our Debian patches for systemd, and came
across this one which sounds important for other distributions, too.
This was reported and fixed two years ago in
https://bugs.debian.org/635777 which has all the details and logs, but
the summary is:
Distributions have qui
17 matches
Mail list logo
