Re: mount.nfs4 and logging

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

 



On Mon, Sep 21, 2020 at 03:40:01PM +0100, Chris Hall wrote:
> On 20/09/2020 20:32, J. Bruce Fields wrote:
> >On Sun, Sep 20, 2020 at 10:56:28AM +0100, Chris Hall wrote:
> ...
> >>Where nfsdcld, rpc.idmapd and rpc.mountd have indeed been started
> >>but are not bound to any ports.
> 
> >That looks good.  (And rpc.mountd does still serve a purpose in the
> >NFSv4 case, answering requests from the kernel for information related
> >to exported filesystems.)
> 
> >>But rpc.statd and rpcbind have also been started, and various ports
> >>have been opened, including port 111 which is bound to systemd.  Is
> >>there a way to inhibit that for nfs4 only ?
> 
> >Unlike rpc.mountd, there's no reason for those to be running at all.
> >You can mask thoe corresponding systemd units.
> 
> I tried masking all of: rpcbind.socket, rpcbind.service,
> statd.service and statd-notify.service.  systemctl start
> nfs-server.service (eventually) gives, according to the logging:
> 
>  nfs-mountd.service: start operation timed out. Terminating.
>  nfs-mountd.service: State 'stop-sigterm' timed out. Killing.
>  nfs-mountd.service: Killing process x (rpc.mountd) with signal SIGKILL.
>  nfs-mountd.service: Control process exited, code=killed, status=9/KILL

Huh, that suggests rpc.mountd is trying to contact rpcbind, but if
you've got v2/v3 turned off in the configuration files, it shouldn't be
trying to register anything.

Looking at the code....  I wonder if the problem is the unregistration
added by 849b7072a049 "mountd: Clear mountd registrations at start up"?

> If I unmask rpcbind.service, I can start nfs-server.  It no longer
> starts rpc.statd.  But I still have rpcbind running and port 111
> open.
> 
> >It'd be nice if there was a way to make that happen automatically if v2
> >and v3 are configured out in the configuration files, but I don't know
> >how to make that happen.
> 
> It would and me neither.

I suppose they could check the configuration and exit on startup if they
see they're not needed.  Will systemd notice they died and try to
restart them or something?

--b.



[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