Re: [systemd-devel] [PATCH 2/3] unit: do not care if order isn't right when retroactively starting deps
On 03/23/2013 03:14 AM, Lennart Poettering wrote: On Wed, 13.03.13 01:44, Michal Schmidt (mschm...@redhat.com) wrote: Attempt to satisfy requirement dependencies retroactively even if the unexpectedly activated unit would prefer to be started After them. This way remote-fs-pre.target can be pulled in by performing a manual mount (the mount units have both Wants= and After= remote-fs-pre.target). I am a bit concerned abou this. Wouldn't this also mean that if a mount for /foobar/waldo suddenly shows up we'd still retroactively mount /foobar too, if that happens to have a unit file? That sounds wrong, no? You are right. It would do exactly this wrong thing. I need to rethink. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] unit: do not care if order isn't right when retroactively starting deps
On Mon, 25.03.13 17:49, Michal Schmidt (mschm...@redhat.com) wrote: On 03/23/2013 03:14 AM, Lennart Poettering wrote: On Wed, 13.03.13 01:44, Michal Schmidt (mschm...@redhat.com) wrote: Attempt to satisfy requirement dependencies retroactively even if the unexpectedly activated unit would prefer to be started After them. This way remote-fs-pre.target can be pulled in by performing a manual mount (the mount units have both Wants= and After= remote-fs-pre.target). I am a bit concerned abou this. Wouldn't this also mean that if a mount for /foobar/waldo suddenly shows up we'd still retroactively mount /foobar too, if that happens to have a unit file? That sounds wrong, no? You are right. It would do exactly this wrong thing. I need to rethink. As discussed on IRC I have now commited a patch that adds a new target remote-fs-setup.target which is now used to pull in things (without ordering), and is different from remote-fs-pre.target which is now used again to order things (without pulling things in). http://cgit.freedesktop.org/systemd/systemd/commit/?id=e8d2f6cde0af86eece9118718ad0a8a19e1cffec Now, I don't actually have any remote mounts here locally, so I am really looking for some feedback before I release this with 199. This is the last thing I wanted to get settled before 199, so I'd be very thankful if somebody could test this in a setup that actually makes sense. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] unit: do not care if order isn't right when retroactively starting deps
On Sat, Mar 23, 2013 at 4:14 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 13.03.13 01:44, Michal Schmidt (mschm...@redhat.com) wrote: Attempt to satisfy requirement dependencies retroactively even if the unexpectedly activated unit would prefer to be started After them. This way remote-fs-pre.target can be pulled in by performing a manual mount (the mount units have both Wants= and After= remote-fs-pre.target). I am a bit concerned abou this. Wouldn't this also mean that if a mount for /foobar/waldo suddenly shows up we'd still retroactively mount /foobar too, if that happens to have a unit file? That sounds wrong, no? If that happens, it sounds especially wrong since /foobar would be mounted *on top*, denying access to /foobar/waldo... -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] unit: do not care if order isn't right when retroactively starting deps
On Wed, 13.03.13 01:44, Michal Schmidt (mschm...@redhat.com) wrote: Attempt to satisfy requirement dependencies retroactively even if the unexpectedly activated unit would prefer to be started After them. This way remote-fs-pre.target can be pulled in by performing a manual mount (the mount units have both Wants= and After= remote-fs-pre.target). I am a bit concerned abou this. Wouldn't this also mean that if a mount for /foobar/waldo suddenly shows up we'd still retroactively mount /foobar too, if that happens to have a unit file? That sounds wrong, no? Lennart --- src/core/unit.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/src/core/unit.c b/src/core/unit.c index a6cc3b6..d1f109d 100644 --- a/src/core/unit.c +++ b/src/core/unit.c @@ -1226,28 +1226,23 @@ static void retroactively_start_dependencies(Unit *u) { assert(UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(u))); SET_FOREACH(other, u-dependencies[UNIT_REQUIRES], i) -if (!set_get(u-dependencies[UNIT_AFTER], other) -!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) +if (!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) manager_add_job(u-manager, JOB_START, other, JOB_REPLACE, true, NULL, NULL); SET_FOREACH(other, u-dependencies[UNIT_BINDS_TO], i) -if (!set_get(u-dependencies[UNIT_AFTER], other) -!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) +if (!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) manager_add_job(u-manager, JOB_START, other, JOB_REPLACE, true, NULL, NULL); SET_FOREACH(other, u-dependencies[UNIT_REQUIRES_OVERRIDABLE], i) -if (!set_get(u-dependencies[UNIT_AFTER], other) -!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) +if (!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) manager_add_job(u-manager, JOB_START, other, JOB_FAIL, false, NULL, NULL); SET_FOREACH(other, u-dependencies[UNIT_REQUISITE], i) -if (!set_get(u-dependencies[UNIT_AFTER], other) -!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) +if (!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) manager_add_job(u-manager, JOB_START, other, JOB_REPLACE, true, NULL, NULL); SET_FOREACH(other, u-dependencies[UNIT_WANTS], i) -if (!set_get(u-dependencies[UNIT_AFTER], other) -!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) +if (!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) manager_add_job(u-manager, JOB_START, other, JOB_FAIL, false, NULL, NULL); SET_FOREACH(other, u-dependencies[UNIT_CONFLICTS], i) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] unit: do not care if order isn't right when retroactively starting deps
Attempt to satisfy requirement dependencies retroactively even if the unexpectedly activated unit would prefer to be started After them. This way remote-fs-pre.target can be pulled in by performing a manual mount (the mount units have both Wants= and After= remote-fs-pre.target). --- src/core/unit.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/src/core/unit.c b/src/core/unit.c index a6cc3b6..d1f109d 100644 --- a/src/core/unit.c +++ b/src/core/unit.c @@ -1226,28 +1226,23 @@ static void retroactively_start_dependencies(Unit *u) { assert(UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(u))); SET_FOREACH(other, u-dependencies[UNIT_REQUIRES], i) -if (!set_get(u-dependencies[UNIT_AFTER], other) -!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) +if (!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) manager_add_job(u-manager, JOB_START, other, JOB_REPLACE, true, NULL, NULL); SET_FOREACH(other, u-dependencies[UNIT_BINDS_TO], i) -if (!set_get(u-dependencies[UNIT_AFTER], other) -!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) +if (!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) manager_add_job(u-manager, JOB_START, other, JOB_REPLACE, true, NULL, NULL); SET_FOREACH(other, u-dependencies[UNIT_REQUIRES_OVERRIDABLE], i) -if (!set_get(u-dependencies[UNIT_AFTER], other) -!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) +if (!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) manager_add_job(u-manager, JOB_START, other, JOB_FAIL, false, NULL, NULL); SET_FOREACH(other, u-dependencies[UNIT_REQUISITE], i) -if (!set_get(u-dependencies[UNIT_AFTER], other) -!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) +if (!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) manager_add_job(u-manager, JOB_START, other, JOB_REPLACE, true, NULL, NULL); SET_FOREACH(other, u-dependencies[UNIT_WANTS], i) -if (!set_get(u-dependencies[UNIT_AFTER], other) -!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) +if (!UNIT_IS_ACTIVE_OR_ACTIVATING(unit_active_state(other))) manager_add_job(u-manager, JOB_START, other, JOB_FAIL, false, NULL, NULL); SET_FOREACH(other, u-dependencies[UNIT_CONFLICTS], i) -- 1.8.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel