From: Steve Dickson <steved@redhat.com>
To: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: [PATCH 0/2] nfs-utils: systemd units bug fixes and comments.
Date: Tue, 18 Feb 2014 03:48:47 -0500 [thread overview]
Message-ID: <1392713329-17979-1-git-send-email-steved@redhat.com> (raw)
Bug Fixes:
The /proc/net/rpc/use-gss-proxy file can not be used
as a start up trigger for rpc.svcsgssd since it always
exists, with or without gss-proxy installed.
Adding the Wants= to the nfs server unit cause a systemd ordering
cycle which caused reboots to take forever.
Comment One:
Even though nfs-client does conditionally start the rpc.gssd
service when /etc/krb5.keytab exists (which good), but that's
all it does. Meaning 'systemctl status' does not show that rpc.gssd
is running and 'systemctl restart' does not restart rpc.gssd
and 'systemctl stop' does not stop the daemon.
It just seems odd to me that we will be using one target unit
to enable a daemon then another service unit (rpc-gssd) to
control it.
I thinking we should have one service unit, when enabled, control
both the rpc.gssd and the rpc.svcgssd daemons. The start up trigger
for both daemons will be the existence of /etc/krb5.keytab and
rpc.svcgssd will only be started if the nfs server is
enabled (if that is possible).
Comment Two:
How about renaming the nfs-utils unit to nfs-services since a
'systemctl restart' of the unit start all the server and client
daemons (even when the server is not enabled, which is probably a bug).
Since a 'systemctl restart nfs-utils' starts all the daemons shouldn't
'systemctl stop nfs-utils' bring them all down as well?
Another oddity, going a 'systemctl restart nfs-utils' causes v3
mounts to go stale... Meaning going a ls on a v3 mount point
after the restart errors out with ESTALE... Not sure why...
Comment Three:
I'm not seeing how the nfs-utils_env.sh file, called by each unit,
is all that useful. The main reason is you can not tell which
unit its being called from so how do know what should be done?
I guess I'm just missing the concept on how and what it should
be used for.
Steve Dickson (2):
rpc-svcgssd.service: removed a the start up triggers
systemd: Removed the "ordering cycle" from nfs-server.service
systemd/nfs-server.service | 2 --
systemd/rpc-svcgssd.service | 1 -
2 files changed, 3 deletions(-)
--
1.8.5.3
next reply other threads:[~2014-02-18 8:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 8:48 Steve Dickson [this message]
2014-02-18 8:48 ` [PATCH 1/2] rpc-svcgssd.service: removed a the start up triggers Steve Dickson
2014-02-19 3:17 ` NeilBrown
2014-02-19 16:03 ` Simo Sorce
2014-02-19 22:19 ` NeilBrown
2014-02-18 8:48 ` [PATCH 2/2] systemd: Removed the "ordering cycle" from nfs-server.service Steve Dickson
2014-02-19 3:21 ` NeilBrown
2014-02-18 14:29 ` [PATCH 0/2] nfs-utils: systemd units bug fixes and comments Chuck Lever
2014-02-18 18:44 ` Steve Dickson
2014-02-18 19:36 ` Chuck Lever
2014-02-18 21:14 ` Steve Dickson
2014-02-19 6:57 ` NeilBrown
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=1392713329-17979-1-git-send-email-steved@redhat.com \
--to=steved@redhat.com \
--cc=linux-nfs@vger.kernel.org \
/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