Linux NFS development
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Neil Brown <neilb@suse.de>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: A couple systemd questions
Date: Sun, 11 Jan 2015 10:24:39 -0500	[thread overview]
Message-ID: <54B295B7.9070509@RedHat.com> (raw)

Hey Neil,

You being the architect of the systemd scribes ;-)  I have a 
couple questions. 

The nfs-server service brings both the rpc.mountd and rpc.idmapd 
daemons up when the service is started, but only 
brings rpc.mountd down when the service is stopped. 

I'm assuming that was done because the client was 
using  rpc.idmapd to do its id mapping, but that is no 
longer the case with some clients. They use the 
key rings via nfsidmap command to do the id mapping

So I'm thinking the nfs-server service should bring 
both daemons up and down when the server is started 
and stopped since the server is the only service using 
the rpc.idmapd.

My attempted at doing this is to change the 
nfs-idmap service to do the following:

[Unit]
Description=NFSv4 ID-name mapping service
Requires=var-lib-nfs-rpc_pipefs.mount
After=var-lib-nfs-rpc_pipefs.mount
After=network.target
PartOf=nfs-server.service
PartOf=nfs-utils.service

Wants=nfs-config.service
After=nfs-config.service

[Service]
EnvironmentFile=-/run/sysconfig/nfs-utils
Type=forking
ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS

Almost exactly what the  rpc-mountd service does. 

Now I thought the "PartOf=nfs-server.service" would cause
rpc.idmapd to come down when the server came down, but that 
does not seem to be the case... The only way I can get 
nfs-idmap service to come down is to explicitly stop it... 
What am I missing?

Secondly, in all of the services where rpcbind is needed you 
reference the rpcbind.target instead of the rpcbind.service. 
Why is that?

The reason I'm ask is,  I'm seeing a problem  where rpc.statd fails 
to start because nfs_svc_create() fails. Meaning it was unable to
either create UPD/TCP sockets or the registrations to rpcbind fails.

I'm thinking its the later due a race between rpcbind and statd 
starting. I've seen races like before in with systemd services... 

So I'm thinking that race would not exist if the rpc-statd service
would use rpcbind.service in the "Requires=" and "After=" 
statements instead of rpcbind.target. Right?? 

tia,

steved.

             reply	other threads:[~2015-01-11 15:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-11 15:24 Steve Dickson [this message]
2015-01-11 19:51 ` A couple systemd questions NeilBrown
2015-01-12 12:27   ` Steve Dickson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54B295B7.9070509@RedHat.com \
    --to=steved@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox