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

[Lennart Poettering]

On Mon, 25.03.13 17:49, Michal Schmidt (mschmidt at redhat.com) wrote:

> 
> On 03/23/2013 03:14 AM, Lennart Poettering wrote:
> >On Wed, 13.03.13 01:44, Michal Schmidt (mschmidt at 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.