Re: [systemd-devel] [SPAM]Re: Mount units with After=autofs.service cause ordering cycles
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. 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
Re: [systemd-devel] [SPAM]Re: Mount units with After=autofs.service cause ordering cycles
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. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [SPAM]Re: Mount units with After=autofs.service cause ordering cycles
On 10/31/19 1:08 PM, Lennart Poettering wrote: On Mo, 14.10.19 16:23, John Florian (j...@doubledog.org) wrote: So, I much prefer the expressiveness of systemd's mount units to the naive era of /etc/fstab, but I've found one situation where I seem to always get stuck and am never able to find a reliable solution that survives OS (Fedora & CentOS) updates. I have a NFS filesystem mounted by autofs at /pub that needs to be bind mounted in various places such as /var/www/pub and /var/ftp/pub. So I create a unit that looks like: ~~~ # /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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
