If a process doesn't set its own SIGHUP handler it dies. If it does in order to gracefully handle shutting down but it's deadlocked then there's no feedback as to whether or not the process actually finished handling the signal.
>So the answer to your hypothetical deadlock is to break everything else?
It's not a hypothetical situation, everyone on here has seen applications hang and have to be terminated. SIGHUP handlers are no different in this regard.
>What kind of complex and graceful shutdown does ssh-agent really need?
That's a straw man argument, and the whole point of SIGHUP in the first place instead of just some "persistence" bit set per process is because for real world applications it's not as simple as just kill -9 to stop a process. But for ssh-agent in particular it needs to go through and unlink the socket that it binds to on startup. More to the point it also has to go through and close every PKCS11 provider that is registered which means calling functions that aren't even in openssh to begin with so who knows if some PKCS11 provider will hang during that.
wasn't GP specifically mentioning user processes and not system daemons? e.g. for daemons it's perfectly expected behavior to not shut down on SIGHUP. Apache, and other system daemons would re-read configuration files when receiving SIGHUP (as a way to reduce downtime during config updates).
