On 10/31/19 2:59 PM, Lennart Poettering wrote:
On Do, 31.10.19 14:09, John Florian (jflor...@doubledog.org) wrote:
# /etc/systemd/system/var-www-pub.mount
[Unit]
Description=mount /pub served via httpd
Requires=autofs.service
After=autofs.service
[Mount]
What=/mnt/pub
Where=/var/www/pub
Options=bind,context=system_u:object_r:httpd_sys_content_t
[Install]
WantedBy=multi-user.target
~~~
The above worked for a long time, but once again a `dnf upgrade` seems to
have broken things because now I have a ordering cycle that systemd must
break. Since I haven't changed my mount units, my ability to mesh with
those shipped by the OS proves fragile. I'm deliberately avoiding too much
detail here because it would seem that there should be a relatively simple
solution to this general sort of task -- I just can't seem to discover it.
Any recommendations that don't involve an entirely different approach?
What precisely is the ordering cycle you are seeing? It's usually
dumped along with the log message.
systemd[1]: local-fs.target: Found ordering cycle on var-www-pub.mount/start
systemd[1]: local-fs.target: Found dependency on autofs.service/start
systemd[1]: local-fs.target: Found dependency on rpc-statd.service/start
systemd[1]: local-fs.target: Found dependency on network-online.target/start
systemd[1]: local-fs.target: Found dependency on network.target/start
systemd[1]: local-fs.target: Found dependency on
NetworkManager.service/start
systemd[1]: local-fs.target: Found dependency on sysinit.target/start
systemd[1]: local-fs.target: Found dependency on
systemd-update-done.service/start
systemd[1]: local-fs.target: Found dependency on local-fs.target/start
systemd[1]: local-fs.target: Job var-www-pub.mount/start deleted to break
ordering cycle starting with local-fs.target/start
The ordering dep between local-fs.target and var-ww-pub.mount is what
you have to get rid of to remove the cycle. Set:
…
[Unit]
DefaultDependencies=no
Conflicts=umount.target
Before=umount.target
…
[Install]
WantedBy=remote-fs.target
…
i.e. make this a dep of remote-fs.target, not the implicit
local-fs.target, so that we don#t pull it in early boot, but only
during late boot, before remote-fs.target.
Thanks Lennart! That did the trick. I and others I know have knocked
heads on this one several times and somehow never came to this
conclusion. It makes sense now that I see it, however. <shrugs/> Maybe
local-fs.target should have stood out to me, but I think it was mostly
accepted since if you follow all deps far enough, you'll eventually
cover (most?) everything.
I think this just means I need to use `systemctl show` more even though
`systemctl cat` is so much easier to digest for what I think I need to
know. Abstracting the default deps is both good in expression but also
difficult in comprehension. I wish there was something "in between",
but I don't even know how to define what that means. Maybe just
grouping all the settings from `show` somehow, e.g.: ordering, deps,
etc. or maybe by unit type: unit, exec, mount, etc.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
