Re: [PATCH 0/2] nfs-utils: systemd units bug fixes and comments.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Feb 18, 2014, at 3:48 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote:

> 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),

No, that's bad.  rpc.gssd has to run in cases where there is no /etc/krb5.ktab.  See

 http://www.spinics.net/lists/linux-nfs/msg41585.html

The existence of /etc/krb5.conf is a better choice.

> 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(-)

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com




--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux