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

Lennart Poettering lennart at poettering.net
Mon Mar 25 15:43:38 PDT 2013

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).


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


Lennart Poettering - Red Hat, Inc.

More information about the systemd-devel mailing list