Re: [systemd-devel] [PATCH 2/3] unit: do not care if order isn't right when retroactively starting deps

2013-03-25 Thread Michal Schmidt 

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

2013-03-25 Thread Lennart Poettering 
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

2013-03-23 Thread Mantas Mikulėnas 
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

2013-03-22 Thread Lennart Poettering 
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

2013-03-12 Thread Michal Schmidt 
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