e8d2f6cde0af86eece9118718ad0a8a19e1cffec |
|
25-Mar-2013 |
Lennart Poettering <lennart@poettering.net> |
units: introduce remote-fs-setup.target to pull in dependencies from remote mounts
This introduces remote-fs-setup.target independently of
remote-fs-pre.target. The former is only for pulling things in, the
latter only for ordering.
The new semantics:
remote-fs-setup.target: is pulled in automatically by all remote mounts.
Shall be used to pull in other units that want to run when at least one
remote mount is set up. Is not ordered against the actual mount units,
in order to allow activation of its dependencies even 'a posteriori',
i.e. when a mount is established outside of systemd and is only picked
up by it.
remote-fs-pre.target: needs to be pulled in automatically by the
implementing service, is otherwise not part of the initial transaction.
This is ordered before all remote mount units.
A service that wants to be pulled in and run before all remote mounts
should hence have:
a) WantedBy=remote-fs-setup.target -- so that it is pulled in
b) Wants=remote-fs-pre.target + Before=remote-fs-pre.target -- so that
it is ordered before the mount point, normally. |
6bde0b3220e95a08cefb70846f73b2cf24b7734a |
|
12-Mar-2013 |
Harald Hoyer <harald@redhat.com> |
remote-fs.target: want remote-fs-pre.target
This pulls in remote-fs-pre.target if remote-fs.target is needed.
Previously remote-fs-pre.target was not active, if no remote fs was
mounted from /etc/fstab. So, every manual remote fs mount was ordered
against the inactive remote-fs-pre.target and umount.target.
Because remote-fs-pre.target was not active, the remote fs was umounted
at umount.target time, which was too late (network already down).
Now remote-fs-pre.target is active, even if no remote fs is mounted.
On shutdown it is deactivated in the correct order and all manual remote
fs mounts also. |
54763e12662d465a038c424ea7baf565cca7be76 |
|
14-Jun-2011 |
Tom Gundersen <teg@jklm.no> |
remote-fs.target: do not order after network.target
remote-fs.target is ordered after the {auto,}mount units. In case of automount
we do not want to wait for the network to come up before proceeding. In case
of a regular mount unit, the unit will be ordered after network.target
so the behavior is unchanged.
This speeds up boot quite a bit for me when having some services needing
NetworkManager-wait-online.service, and having my home partition on nfs
under an automountpoint. |