summaryrefslogtreecommitdiffstats
path: root/systemd/rpc-statd.service
Commit message (Collapse)AuthorAgeFilesLines
* systemd: Afters are also needed for the Wants=network-online.targetSteve Dickson2017-04-241-1/+1
| | | | | | | | | | | Commit 9d4fc3fb added Wants=network-online.target which is not enough to ensure the network is completely up before the NFS server is started. After=network-online.target is also needed. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1419351 Signed-off-by: Steve Dickson <steved@redhat.com>
* systemd: NFS server services should use network-onlineSteve Dickson2017-04-101-1/+2
| | | | | | | | | | | | | | | | There has been an number startup problems where parts of the NFS server fails to start due to DNS and other parts of the network not be up. Reading the systemd.special it seems network.target is a passive unit which does not wait for the entire network to come up and network-online.target is an active unit which does wait. So this adds Wants=network-online.target to all of the NFS server services Signed-off-by: Steve Dickson <steved@redhat.com>
* systemd: Remove the nfs-config.serviceNeilBrown2016-12-201-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have /etc/nfs.conf, a lot of configuration can be read directly. So nfs-config isn't really needed any more. Some distributions allow command-line arguments for various daemons to be set in an environment file (/etc/sysconfig, /etc/defaults). Passing these through /etc/nfs.conf is not possible. Instead, a distro that needs this functionality can create drop-in files which select the required value. As no commands are given default arguments by systemd unit files, the drop-in can just add distro-specific args. For example /lib/systemd/system/nfs-mountd.service.d/local.conf [Service] EnvironmentFile=/etc/sysconfig/nfs ExecStart= ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDOPTS Note the need for the empty assignment to remove existing definitions first. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* statd: allow --no-notify to be passed via environment variable.NeilBrown2016-12-201-1/+2
| | | | | | | | | | The significant value of allowing this is that it means that for default operation, systemd unit files do not need to pass any options to any programs. The purpose of this will become apparent in the next patch. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* systemd unit files: fix up dependencies on rpcbind.NeilBrown2016-05-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The dependencies on rpcbind have been changed a few times and I think they are still wrong. So I'll go into some detail to justify this change. Firstly: rpcbind.target rpcbind.socket or rpcbind.service? The systemd documentation talks about targets as "synchronization points" and likens them to SysV init run levels. Run levels are about ordering but not dependencies. The systemd.special man page describes rpcbind.target as intended explicitly for ordering sysvinit scripts, with "After=" dependencies. So while I think it is valid to use rpcbind.target for ordering (before/after) it shouldn't be used for dependencies (Wants/Requires). The rpcbind.target file included in systemd does not "Require" the actual service, so requiring rpcbind.target itself is pointless. I think we shouldn't use rpcbind.target at all. Leave it for sysvinit synchronization. So: .socket or .service? I think nfs only needs the socket to be active. On first connection the service will be started. But nfs does not need to wait for the service to start, only the socket. So I think we should exclusively use rpcbind.socket. Next: Wants or Requires. rpc.statd definitely Requires rpcbind. It needs to register to be useful, and without rpcbind it cannot register. nfs-server does not necesarily require rpcbind. Specifically if configured for NFSv4 only, nfs-server will work quite happily without rpcbind. Someone with an NFSv4 only setup who wants rpcbind to not run can use systemctl mask rpcbind.socket to ensure it never runs. So nfs-server should only "Wants: rpcbind.socket". I think Commit: 4fabfcd08206 ("systemd: Decouple the starting and stopping of rpcbind/nfs-server") should have changed "Requires" to "Wants" rather than "server" to "target" to fix the dependency problem. Finally: After? It only makes sense to declare an ordering relation as "After:" something that will actually be started. If "foo.service" is not part of the systemd transaction, then "After: foo.service" has no effect. So having: Requires: rpcbind.target After: rpcbind.socket doesn't make much sense unless there is some relationship between rpcbind.target and rpcbind.socket, and there is no general guarantee of that (though what individual distros do, I don't know). So the "After" should match the "Wants" or "Requires". It might make sense to Requires: rpcbind.socket After: rpcbind.target as it is reasonable to assume that rpcbind.target will be ordered with rpcbind.socket, but as we can use rpcbind.socket explictly, that is clearer. So my conclusion is that nfs-server should: Wants: rpcbind.socket After: rpcbind.socket and rpc-statd should Requires: rpcbind.socket After: rpcbind.socket which is what this patch puts into effect. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* systemd: Decouple the starting and stopping of rpcbind/nfs-serverSteve Dickson2015-11-161-1/+1
| | | | | | | | | | | | Commit b98f2af15 introduced a regression that cause the starting and stop of rpcbind and the nfs-server to be depended on each other The starting of the NFS server should start rpcbind but bring rpcbind down should not bring the NFS server down. Signed-off-by: Steve Dickson <steved@redhat.com>
* systemd: add PIDFile directives where appropriate.NeilBrown2014-03-241-0/+1
| | | | | | | Only two of our daemons write out pid files. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
* systemd units: create nfs-config.service as single location to process config.NeilBrown2014-03-241-2/+3
| | | | | | | | | Instead of processing the config information into command lines every time it might be needed, do it once in a separate service that other services can Want. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
* systemd: tidy up DefaultDependenciesNeilBrown2014-03-241-0/+1
| | | | | | | | | | | | | | | DefaultDependencies should be "yes" (the default) for things needed only be the NFS server, as that is a service that doesn't need to start early. DefaultDependencies should be "no" for things needed to mount an NFS filesystem, and filesystems are mounted before basic.target. To ensure these services are shut down in a timely fashion, they must Conflict with systemd.umount so they are shutdown when everything is unmounted. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
* systemd: add nfs-utils.service which can be used to restart everything.NeilBrown2014-03-241-0/+2
| | | | | | | | | | With this patch, systemctl restart nfs-utils will restart any nfs-utils daemons that are currently running, whether there were started via nfs-server.service, nfs-client.target, or directly by systemctl. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
* Added systemd/rpc-statd.serviceNeilBrown2014-03-241-0/+12
Signed-off-by: Steve Dickson <steved@redhat.com>