Having read NFS mount through ConnectTCP delays shutdown · Issue #5911 · QubesOS/qubes-issues · GitHub, I’m asking myself:
What is the difference between just putting qvm-connect-tcp in /rw/config/rclocal
qvm-connect-tcp ::2049
and creating full fledged systemd service and socket, as described in Firewall | Qubes OS, point 4?
Former works fine for me and is easier to implement. Though docs describe latter as reference.
Till now, I have not experienced any race conditions, as described in the issue.
Thanks!
To answer my own question: There is a difference.
The generic cause is a race condition between qrexec agent and a client depending on it
- which curiously ends in a loop and no hard error, until global timeout kicks in.
With systemd you can explicitly set dependencies between qrexec and other depending units (like mount), which is not the case for qvm-connect-tcp placed in /rw/config/rc.local.
Speaking of NFS, I got similar “hanging” problems as in linked issue with a qube having an NFS network share and which is to be shutdown.
Possible explanation:
qubes-qrexec-agent.service might get shutdown first, as there is no “before - after” order without systemd. At this point in time, NFS client still needs response from the server, which now isn’t reachable via qrexec anymore and idles.
(tried certain NFS client optimization options for eager abort, but these did not help.)