Hi, Just trying to work out a few problems on our (Mageia's) NFS packages.
As with a lot of things we often take the units from Fedora (we will soon have a nicer way to share units I hope - need to get release out the way before I can help and put my bit of the work into this tho'). However I'm a bit confused by the latest units. > nfs-server.service:[Unit] > nfs-server.service:Description=NFS Server > nfs-server.service:Requires=proc-fs-nfsd.mount var-lib-nfs-rpc_pipefs.mount > rpcbind.service > nfs-server.service:Requires=nfs-idmap.service nfs-mountd.service > nfs-rquotad.service > nfs-server.service:After=network.target named.service > nfs-server.service:[Service] > nfs-server.service:Type=oneshot > nfs-server.service:RemainAfterExit=yes > nfs-server.service:StandardError=syslog+console > nfs-server.service:EnvironmentFile=-/etc/sysconfig/nfs > nfs-server.service:ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig > nfs-server.service:ExecStartPre=/usr/sbin/exportfs -r > nfs-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT > nfs-server.service:ExecStartPost=-/usr/lib/nfs-utils/scripts/nfs-server.postconfig > nfs-server.service:ExecStop=/usr/sbin/rpc.nfsd 0 > nfs-server.service:ExecStopPost=/usr/sbin/exportfs -f > nfs-server.service:[Install] > nfs-server.service:WantedBy=multi-user.target This is the main server unit. It requires the idmap, mountd and rquotad services. It has After=named.service. Should this not be After=nss-lookup.target instead? Bind/named might not be the only thing that does name lookups after all and nss-lookup.target is meant to encapsulate this does it not? (e.g. ldap could factor in here). > nfs-idmap.service:[Unit] > nfs-idmap.service:Description=NFSv4 ID-name mapping daemon > nfs-idmap.service:BindTo=nfs-server.service > nfs-idmap.service:After=nfs-server.service > nfs-idmap.service:[Service] > nfs-idmap.service:Type=forking > nfs-idmap.service:StandardError=syslog+console > nfs-idmap.service:EnvironmentFile=-/etc/sysconfig/nfs > nfs-idmap.service:ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS > nfs-idmap.service:[Install] > nfs-idmap.service:WantedBy=nfs.target This unit is bound to nfs-server so it will follow it's start/stop cycle. Yet it is also wanted by nfs.target. What purpose does nfs.target actually serve here? Ditto for the mountd and rquotad units which are similarly structured. Also, It is my understanding (and feel free to correct me here) but nfs-idmap is often needed on client systems also? I'm sure I had to configure a client in the past to ensure idmap was running in order to avoid permissions problems and users getting mapped to the 65k uid that means "nobody. I had to force this by setting NEEDS_IDMAP=yes in the old sysconfig file /etc/sysconfig/nfs-common (I'm pretty sure we had the same sysvinit setup as Fedora in the past). This being the case should idmap be enablable as an independent unit for client systems (same as nfs-lock.service). Again, feel free to correct me here if I'm wrong. If this is the case the BindTo would have to be dropped, but the Require could still be kept. The install rule would have to be made independant of nfs.target. To aid sysadmin clarity, it would make sense to have the nfs-server.service's [Install] section to have an Also= directive so that the relevant unit's enabled/disabled status's are shown more clearly to sysadmins. If mountd and rquotad make no sense to run separately then they should just have their [Install] sections nuked (more comments about rquoatad below tho'). > nfs.target:[Unit] > nfs.target:Description=Network File System Server > nfs.target:Requires=var-lib-nfs-rpc_pipefs.mount proc-fs-nfsd.mount > rpcbind.service > nfs.target:After=network.target named.service > nfs.target:[Install] > nfs.target:WantedBy=multi-user.target If nfs.target is "Network File Systemd Server", and the units are already set to be BindTo AND Require, then I really don't grok what nfs.target is for. It's not like it provides any additional level of isolation or configurability. In fact, enabling/disabling idmap, mountd and rquotad services will have no effect anyway due to them being requires/bound to nfs-server.service. Should this target just be dropped? > nfs-rquotad.service:[Unit] > nfs-rquotad.service:Description=NFS Remote Quota Server > nfs-rquotad.service:BindTo=nfs-server.service > nfs-rquotad.service:After=nfs-server.service > nfs-rquotad.service:[Service] > nfs-rquotad.service:Type=forking > nfs-rquotad.service:StandardError=syslog+console > nfs-rquotad.service:EnvironmentFile=-/etc/sysconfig/nfs > nfs-rquotad.service:ExecStart=-/usr/sbin/rpc.rquotad $RPCRQUOTADOPTS > nfs-rquotad.service:[Install] > nfs-rquotad.service:WantedBy=nfs.target This package refers to a binary that is actually shipped in a different package (rpc.rquotad comes from the "quota" package). Shipping units in different packages to the binaries is pretty strange. Shouldn't this unit be renamed to rpc-rquotad.service and shipped instead in the quota package? Perhaps with no [Install] rule or one that makes sense in isolation if it can be sensibly used separately from nfs. > nfs-mountd.service:[Unit] > nfs-mountd.service:Description=NFS Mount Daemon > nfs-mountd.service:BindTo=nfs-server.service > nfs-mountd.service:After=nfs-server.service > nfs-mountd.service:[Service] > nfs-mountd.service:Type=forking > nfs-mountd.service:EnvironmentFile=-/etc/sysconfig/nfs > nfs-mountd.service:ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDOPTS > nfs-mountd.service:StandardError=syslog+console > nfs-mountd.service:[Install] > nfs-mountd.service:WantedBy=nfs.target The variable name here ends in OPTS, but all the others end in ARGS. Consistency aids understanding and this is already confusing for me, so every little helps!! > nfs-blkmap.service:[Unit] > nfs-blkmap.service:Description=pNFS block layout mapping daemon > nfs-blkmap.service:Wants=var-lib-nfs-rpc_pipefs.mount > nfs-blkmap.service:Requires=var-lib-nfs-rpc_pipefs.mount > nfs-blkmap.service:[Service] > nfs-blkmap.service:Type=forking > nfs-blkmap.service:StandardError=syslog+console > nfs-blkmap.service:EnvironmentFile=-/etc/sysconfig/nfs > nfs-blkmap.service:ExecStart=/usr/sbin/blkmapd $BLKMAPDARGS > nfs-blkmap.service:[Install] > nfs-blkmap.service:WantedBy=multi-user.target No real comment here other than I am left still unsure if I need to manually enable this or not and under what circumstances I should care etc. > nfs-lock.service:[Unit] > nfs-lock.service:Description=NFS file locking service. > nfs-lock.service:Requires=rpcbind.service network.target > nfs-lock.service:After=network.target named.service rpcbind.service > nfs-lock.service:Before=remote-fs-pre.target > nfs-lock.service:[Service] > nfs-lock.service:Type=forking > nfs-lock.service:StandardError=syslog+console > nfs-lock.service:EnvironmentFile=-/etc/sysconfig/nfs > nfs-lock.service:ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-lock.preconfig > nfs-lock.service:ExecStart=/sbin/rpc.statd $STATDARG > nfs-lock.service:# Make sure lockd's ports are reset > nfs-lock.service:ExecStopPost=-/sbin/sysctl -w fs.nfs.nlm_tcpport=0 > fs.nfs.nlm_udpport=0 > nfs-lock.service:[Install] > nfs-lock.service:WantedBy=multi-user.target No comment here really. The only thing I would say is that rpcbind.target also exists... should this be used as a higher level After= (rather than rpcbind.service) or should we be aiming to kill rpcbind.target in the long term? > nfs-secure-server.service:[Unit] > nfs-secure-server.service:Description=Secure NFS Server > nfs-secure-server.service:Requires=var-lib-nfs-rpc_pipefs.mount > nfs-server.service > nfs-secure-server.service:After=syslog.target var-lib-nfs-rpc_pipefs.mount > nfs-server.service > nfs-secure-server.service:[Service] > nfs-secure-server.service:Type=forking > nfs-secure-server.service:StandardError=syslog+console > nfs-secure-server.service:EnvironmentFile=-/etc/sysconfig/nfs > nfs-secure-server.service:ExecStart=/usr/sbin/rpc.svcgssd $RPCSVCGSSDARGS > nfs-secure-server.service:[Install] > nfs-secure-server.service:WantedBy=multi-user.target > > nfs-secure.service:[Unit] > nfs-secure.service:Description=Secure NFS > nfs-secure.service:Requires=var-lib-nfs-rpc_pipefs.mount > nfs-secure.service:After=syslog.target var-lib-nfs-rpc_pipefs.mount > nfs-secure.service:[Service] > nfs-secure.service:Type=forking > nfs-secure.service:StandardError=syslog+console > nfs-secure.service:EnvironmentFile=-/etc/sysconfig/nfs > nfs-secure.service:ExecStart=/usr/sbin/rpc.gssd $RPCGSSDARGS > nfs-secure.service:[Install] > nfs-secure.service:WantedBy=multi-user.target Only comment here is that it is unclear from the unit names what these actually do and how they interoperate. Do I need to enable both for things to work? If so why are they not using Requires/BindTo like the other units? If they work independently (perhaps one is server and one client?), then the descriptions need to be adjusted I think. All in all, I think there is scope to tidy these up and make them better. Adding man pages and Documentation= directives would also help a lot. Happy to help out here if I can get some feedback on some of the points above. Many thanks. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
