0

On a client I see the following:

[root@redacted_local ~]# ss | grep -i syn                                   
SYN-SENT   0      1            redacted_local_ip:792             redacted_server_ip:nfs

This status has remained the same. I'm unable to actually track port 792/SYN_SENT statuses to a PID:

[root@redacted_local ~]# netstat -pnt | grep -i syn
tcp        0      1 redacted_local_ip:792            redacted_server_ip:2049             SYN_SENT    -

How can I tell what is actually holding this port open and what PID exists that needs to be killed? The client is using autofs to go to the NFS server and mount user directories, such that when a user logs into the client, they will have their home directory mounted from the NFS server. Is something even "stuck" in the first place that can be killed?

Improve this question
6
  • from the port value one can guess it's kernel's NFS client, which even if it started a thread (eg NFSv4 callback) wouldn't appear in resources because it doesn't use or show things like file descriptors etc: it's kernel code rather than userspace. – A.B Jul 28 '20 at 12:32
  • Thanks @A.B - yeah, I tried a number of things (like tracking down the inode and associating that to a PID) with no result. I think the only real solution here is to reboot the host. – Kahn Jul 28 '20 at 12:33
  • or resolve the routing issue, or force umount the NFS mount... – A.B Jul 28 '20 at 12:34
  • Yeah, problem is, there is no actual NFS mount. These servers are authenticating with IPA and then using autofs/automount to actually call out to the NFS server to automatically map their usernames and mount their homedir directly on the host. – Kahn Jul 28 '20 at 12:37
  • Then what is the mount type if not NFS in "mount their homedir directly on the host"? – A.B Jul 28 '20 at 12:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.