On Sat, Jun 20, 2020 at 11:35:56AM +0000, Kraus, Sebastian wrote: > In consequence, about a week ago, I decided to investigate the problem > in a deep manner by stracing the rpc.gssd daemon while running. Since > then, the segementation violations were gone, but now lots of > complaints of the following type appear in the system log: > > Jun 19 11:14:00 all rpc.gssd[23620]: ERROR: can't open > nfsd4_cb/clnt3bb/info: No such file or directory Jun 19 11:14:00 all > rpc.gssd[23620]: ERROR: failed to parse nfsd4_cb/clnt3bb/info > > > This behaviour seems somehow strange to me. But, one possible > explanation could be: The execution speed of rpc.gssd slows down while > being straced and the "true" reason for the segmentation violations > pops up. I would argue, rpc.gssd trying to parse non-existing files > points anyway to an insane and defective behaviour of the RPC GSS user > space daemon implementation. Those files under rpc_pipefs come and go. rpc.gssd monitors directories under rpc_pipefs to learn about changes, and then tries to parse the files under any new directories. The thing is, if rpc.gssd is a little fast, I think it's possible that it could get the notification about clnt3bb/ being created, and try to look up "info", before "info" itself is actually created. Or alternatively, if clnt3bb/ is short-lived, it might not look up "info" until the directory's already been deleted again. Neither problem should be fatal--rpc.gssd will get another update and adjust to the new situation soon enough. So it may be that the reall error here is an unconditional log message in a case that's expected, not actually an error. Or I could be wrong and maybe something else is happening. But I think it'd be more useful to stay focused on the segfaults. --b.
