Hi, thanks for your interest in the project. Can you elaborate on "gets confused without networks"? gssproxy doesn't open any network connections on start (just unix domain socket(s)), so I'm worried this is hiding a deeper issue we should address.

As I understand it, gssproxy just sets up a unix domain socket at start. But once it is done starting it should be ready for use immediately. However, if the network is not running (or not finished setting up) the daemon doesn't actually work. The daemon is running, but non-functional.

The thing I think I hit (that I've not been able to easily replicate) seems to link up to : dhcp completing, changing my hostname, and then kerberos mounting an NFS share. Somewhere in that soupy mess, gssproxy started saying I had an invalid credential cache. It was a fresh boot that instantly went into that state. When I stopped gssproxy and restarted it everything just worked again.

Service ordering was my best guess for why restarting gssproxy without making any other system changes fixed my system.

Thanks for clarifying. I dug into this a bit more and it seems that systemd just named these things really poorly: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Specifically, the thing one might naïvely expect "network.target" to be is in fact "network-online.target". However, there's basically no documentation I can find for what "network.target" actually guarantees beyond "network functionality is available". Given that, it makes sense that we could have a problem here with our socket; however, I'm not wholly confident in that guess since I can't find any more information on what network.target actually does even after perusing the source.

@simo, I don't think this will break anything. Are you okay with it being merged?

Gss Proxy is basically useless without network anyway, so I do not see a huge issue in doing this.
If something breaks we'll revert.

Commit 153b2ed5 fixes this pull-request