[Resending to the list, as it seems recipients were wrong in the first attempt]
The discussion on this died down. I'm bringing this back up as it's IMO
quite a significant problem.
To recap:
The core issue is that if a start job is queued for foo.service,
systemctl reload foo.service blocks
On Fri, 15.08.14 21:10, Michael Biebl (mbi...@gmail.com) wrote:
2014-08-15 12:50 GMT+02:00 Lennart Poettering lenn...@poettering.net:
I think most of the confusion here comes from the fact that sysv service
restarts don't care about ordering at all, really, and we do. But the
answer to
Lennart Poettering wrote on 18/08/14 15:05:
On Fri, 15.08.14 21:10, Michael Biebl (mbi...@gmail.com) wrote:
2014-08-15 12:50 GMT+02:00 Lennart Poettering lenn...@poettering.net:
I think most of the confusion here comes from the fact that sysv service
restarts don't care about ordering at
On Fri, 15.08.14 05:09, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
Before this commit systemctl reload on an inactive unit with a queued
start job would block until the unit had started if the unit supported
reload, but return failure immediately if the unit didn't.
This sounds
On Fri, 2014-08-15 at 12:50 +0200, Lennart Poettering wrote:
On Fri, 15.08.14 05:09, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
Before this commit systemctl reload on an inactive unit with a queued
start job would block until the unit had started if the unit supported
reload, but
В Fri, 15 Aug 2014 20:25:57 +0300
Uoti Urpala uoti.urp...@pp1.inet.fi пишет:
What is your desired state for reload then?
*operating* with the new configuration loaded.
The problem with this is that it's common for things updating
configuration to be separate from things using
On Fri, 2014-08-15 at 22:22 +0400, Andrei Borzenkov wrote:
В Fri, 15 Aug 2014 20:25:57 +0300
Uoti Urpala uoti.urp...@pp1.inet.fi пишет:
The problem with this is that it's common for things updating
configuration to be separate from things using the daemon. If something
changes, the
2014-08-15 12:50 GMT+02:00 Lennart Poettering lenn...@poettering.net:
I think most of the confusion here comes from the fact that sysv service
restarts don't care about ordering at all, really, and we do. But the
answer to that is not to weaken the current strong semantics of
blocking, but
On Wed, 16.07.14 04:15, Jon Severinsson (j...@severinsson.net) wrote:
Sorry for the late review, but this stuff is a bit harder to grok, so I
needed some time to have a closer look.
Before this commit systemctl reload on an inactive unit with a queued
start job would block until the unit had
On Fri, 2014-08-15 at 01:59 +0200, Lennart Poettering wrote:
On Wed, 16.07.14 04:15, Jon Severinsson (j...@severinsson.net) wrote:
Before this commit systemctl reload on an inactive unit with a queued
start job would block until the unit had started if the unit supported
reload, but return
10 matches
Mail list logo
