Re: [systemd-devel] fstab generator and nfs-client.target
On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. This would have the side effect of nfs-common not being started in single user mode, which is not likely to be the wanted outcome. 2) nfs-common makes itself pulled in by network-online.target, and orders itself before that. This way, the service is started when the network is upped. Why isn't WantedBy=remote-fs.target an option? This would make any auto remote mount pull nfs-common, but if none is then it won't be started (unless that part of local-fs doesn't apply to remote-fs). -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On Sun, 26.07.15 00:08, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Sat, 25 Jul 2015 12:50:39 +0200 Michael Biebl mbi...@gmail.com пишет: 2015-07-25 3:18 GMT+02:00 Rich Freeman r-syst...@thefreemanclan.net: I noticed that mount units for nfs shares created by the generator do not Want=nfs-client.target or similar. That means that if you don't explicitly want nfs-client in your configuration then nfs shares will get mounted, but services like rpc-statd-notify.service won't run. Would it make sense to have the generator add the nfs-client target as a want to nfs mount services it creates? remote mount units do have a After remote-fs-pre.target ordering and tools like nfs-common/rpcbind are supposed to hook up into remote-fs-pre.target. They are supposed to be /ordered before/ remote-fs-pre.target; but I do not remember that remote-fs-pre.target itself was intended to pull anything. This was designed as pure synchronization point. http://www.freedesktop.org/software/systemd/man/systemd.special.html#remote-fs-pre.target Note that this unit is generally not part of the initial transaction, unless the unit that wants to be ordered before all remote mounts pulls it in via a Wants= type dependency. So if I read it, nfs-common should pull in remote-fs-pre, but that leaves question what should pull in nfs-common itself. Remote mounts are ordered after network.target, after remote-fs-pre.target and after network-online.target. remote-fs-pre.target and network.target are indeed passive, they should be pulled in by the service that wants to be the hook, not by the mount that uses it. r-f-p.t is specifically for network mounts in this case, while n.t is more generic. r-f-p.t is much stricter defined, while n.t is very loosely defined and mostly about shutdown order, not so much abotu startup order. n-o.t otoh is an active target, it's actively pulled in by all remote mounts, and hence can be used to add a service to the transaction as soon as a remote mount is attempted. Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. 2) nfs-common makes itself pulled in by network-online.target, and orders itself before that. This way, the service is started when the network is upped. If you are looking for a way to start this service only when an NFS mount is attempted, then I must disappoint you: there's currently no way to do this nicely, as you can neither express applies only to NFS, nor is there a way to actively pull in things from remote mounts. (There's a reason for both limitations: we try to avoid pull-deps on mounts, since we want to keep the effect of manually ordered /bin/mount invocations, and systemd-ordered .mount activations as close as possible.) Hope this is useful, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote: On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. This would have the side effect of nfs-common not being started in single user mode, which is not likely to be the wanted outcome. Well, then set DEfaultDEpendencies=no and pull it in by sysinit.target. But that's only OK if the service is capable of running in early-boot mode (i.e does not try to access /var and stuff). 2) nfs-common makes itself pulled in by network-online.target, and orders itself before that. This way, the service is started when the network is upped. Why isn't WantedBy=remote-fs.target an option? This would make any auto remote mount pull nfs-common, but if none is then it won't be started (unless that part of local-fs doesn't apply to remote-fs). Remote mount units do not pull that in. you can use it to mount all remote mounts, but the remote mounts will not pull it in, the dependency is only one way. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On Mon, 27.07.15 13:25, Rich Freeman (r-syst...@thefreemanclan.net) wrote: On Mon, Jul 27, 2015 at 10:51 AM, Lennart Poettering lenn...@poettering.net wrote: If you are looking for a way to start this service only when an NFS mount is attempted, then I must disappoint you: there's currently no way to do this nicely, as you can neither express applies only to NFS, nor is there a way to actively pull in things from remote mounts. Presumably if the .mount unit had Wants=nfs-common.target or something similar it would pull it in when it mounts, right? That would probably require a change to the generator to detect nfs shares and add this. Whether you want to do it that way is a different matter. Yeah, we want to avoid such fs-specific hacks. Note that there's generic support via mount options for this via the x-systemd.requires= fstab option. See systemd.mount(5) for details. But that requires patching fstab of course. (There's a reason for both limitations: we try to avoid pull-deps on mounts, since we want to keep the effect of manually ordered /bin/mount invocations, and systemd-ordered .mount activations as close as possible.) Would it actually affect ordering? If the mount wants nfs-common and is after remote-fs-pre.target, and nfs-common is before remote-fs-pre.target is after nfs-common, then won't nfs-common be started before any remote fs are mounted? The only change would be that the mount wants nfs-common, so that it is started when it otherwise might not have been. Or am I missing something? What I tried to say is that we don't want to add too many implicit requirement deps to mounts, but only ordering deps, so that carefully paced manual /bin/mount invocations have pretty much the same effect as those done by systemd itself: the number of units pulled in should be the same. It's basically the same reason we never added ExecStartPre= or so to .mount units: the effect of /bin/mount /foo invocations should be similar to what systemd would do due to systemctl start /foo, modulo the ordering. The executed commands should be the same. (Of course, if you use x-systemd.requires= as suggested above, or if you write manual .mount files, then the effect will be quite different, but then you did this explicitly, and hopefully knowingly, and that's OK. However we should be careful with too many automatisms there...) I hope that makes some sense, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On Mon, Jul 27, 2015 at 10:51 AM, Lennart Poettering lenn...@poettering.net wrote: If you are looking for a way to start this service only when an NFS mount is attempted, then I must disappoint you: there's currently no way to do this nicely, as you can neither express applies only to NFS, nor is there a way to actively pull in things from remote mounts. Presumably if the .mount unit had Wants=nfs-common.target or something similar it would pull it in when it mounts, right? That would probably require a change to the generator to detect nfs shares and add this. Whether you want to do it that way is a different matter. (There's a reason for both limitations: we try to avoid pull-deps on mounts, since we want to keep the effect of manually ordered /bin/mount invocations, and systemd-ordered .mount activations as close as possible.) Would it actually affect ordering? If the mount wants nfs-common and is after remote-fs-pre.target, and nfs-common is before remote-fs-pre.target is after nfs-common, then won't nfs-common be started before any remote fs are mounted? The only change would be that the mount wants nfs-common, so that it is started when it otherwise might not have been. Or am I missing something? -- Rich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On Mon, 27.07.15 15:37, Felipe Sateler (fsate...@debian.org) wrote: On 27 July 2015 at 12:36, Lennart Poettering lenn...@poettering.net wrote: On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote: On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. This would have the side effect of nfs-common not being started in single user mode, which is not likely to be the wanted outcome. Well, then set DEfaultDEpendencies=no and pull it in by sysinit.target. But that's only OK if the service is capable of running in early-boot mode (i.e does not try to access /var and stuff). Or basic.target? The description of basic.target says: Usually this should pull-in all mount points, swap devices, sockets, timers, and path units and other basic initialization necessary for general purpose daemons. Something that provides services for mountpoints could be hooked up here, no? The description of sysinit.target doesn't really tell me what this target is all about, or how to choose between it and basic.target. Yeah, it's not obvious. Basically, sysinit.target is where all the small early-boot mini-services are pulled in. basic.target otoh pulls in the various other targets then, without pulling in any .mount, .service, .socket, ... units on its own. Or in other words: we group all early-boot services in sysinit.target, we group all mounts in local-fs.target, all swaps in swaps.target, all sockets in sockets.target, and so on, and then group all the aforementioned targets as basic.target. Makes sense? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On 27 July 2015 at 12:36, Lennart Poettering lenn...@poettering.net wrote: On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote: On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. This would have the side effect of nfs-common not being started in single user mode, which is not likely to be the wanted outcome. Well, then set DEfaultDEpendencies=no and pull it in by sysinit.target. But that's only OK if the service is capable of running in early-boot mode (i.e does not try to access /var and stuff). Or basic.target? The description of basic.target says: Usually this should pull-in all mount points, swap devices, sockets, timers, and path units and other basic initialization necessary for general purpose daemons. Something that provides services for mountpoints could be hooked up here, no? The description of sysinit.target doesn't really tell me what this target is all about, or how to choose between it and basic.target. 2) nfs-common makes itself pulled in by network-online.target, and orders itself before that. This way, the service is started when the network is upped. Why isn't WantedBy=remote-fs.target an option? This would make any auto remote mount pull nfs-common, but if none is then it won't be started (unless that part of local-fs doesn't apply to remote-fs). Remote mount units do not pull that in. you can use it to mount all remote mounts, but the remote mounts will not pull it in, the dependency is only one way. Oh I misread the manpage. Thanks for clarifying. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On 27 July 2015 at 15:58, Lennart Poettering lenn...@poettering.net wrote: On Mon, 27.07.15 15:37, Felipe Sateler (fsate...@debian.org) wrote: On 27 July 2015 at 12:36, Lennart Poettering lenn...@poettering.net wrote: On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote: On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. This would have the side effect of nfs-common not being started in single user mode, which is not likely to be the wanted outcome. Well, then set DEfaultDEpendencies=no and pull it in by sysinit.target. But that's only OK if the service is capable of running in early-boot mode (i.e does not try to access /var and stuff). Or basic.target? The description of basic.target says: Usually this should pull-in all mount points, swap devices, sockets, timers, and path units and other basic initialization necessary for general purpose daemons. Something that provides services for mountpoints could be hooked up here, no? The description of sysinit.target doesn't really tell me what this target is all about, or how to choose between it and basic.target. Yeah, it's not obvious. Basically, sysinit.target is where all the small early-boot mini-services are pulled in. basic.target otoh pulls in the various other targets then, without pulling in any .mount, .service, .socket, ... units on its own. Except for RequiresMountsFor=/var /tmp /var/tmp specified in basic.target. Or in other words: we group all early-boot services in sysinit.target, we group all mounts in local-fs.target, all swaps in swaps.target, all sockets in sockets.target, and so on, and then group all the aforementioned targets as basic.target. Makes sense? Yes, makes sense. I will try to come up with a patch to the documentation to clarify this. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
В Sat, 25 Jul 2015 12:50:39 +0200 Michael Biebl mbi...@gmail.com пишет: 2015-07-25 3:18 GMT+02:00 Rich Freeman r-syst...@thefreemanclan.net: I noticed that mount units for nfs shares created by the generator do not Want=nfs-client.target or similar. That means that if you don't explicitly want nfs-client in your configuration then nfs shares will get mounted, but services like rpc-statd-notify.service won't run. Would it make sense to have the generator add the nfs-client target as a want to nfs mount services it creates? remote mount units do have a After remote-fs-pre.target ordering and tools like nfs-common/rpcbind are supposed to hook up into remote-fs-pre.target. They are supposed to be /ordered before/ remote-fs-pre.target; but I do not remember that remote-fs-pre.target itself was intended to pull anything. This was designed as pure synchronization point. http://www.freedesktop.org/software/systemd/man/systemd.special.html#remote-fs-pre.target Note that this unit is generally not part of the initial transaction, unless the unit that wants to be ordered before all remote mounts pulls it in via a Wants= type dependency. So if I read it, nfs-common should pull in remote-fs-pre, but that leaves question what should pull in nfs-common itself. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
2015-07-25 3:18 GMT+02:00 Rich Freeman r-syst...@thefreemanclan.net: I noticed that mount units for nfs shares created by the generator do not Want=nfs-client.target or similar. That means that if you don't explicitly want nfs-client in your configuration then nfs shares will get mounted, but services like rpc-statd-notify.service won't run. Would it make sense to have the generator add the nfs-client target as a want to nfs mount services it creates? remote mount units do have a After remote-fs-pre.target ordering and tools like nfs-common/rpcbind are supposed to hook up into remote-fs-pre.target. http://www.freedesktop.org/software/systemd/man/systemd.special.html#remote-fs-pre.target -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] fstab generator and nfs-client.target
I noticed that mount units for nfs shares created by the generator do not Want=nfs-client.target or similar. That means that if you don't explicitly want nfs-client in your configuration then nfs shares will get mounted, but services like rpc-statd-notify.service won't run. Would it make sense to have the generator add the nfs-client target as a want to nfs mount services it creates? -- Rich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
