8 ms·

That comes down entirely to how systemd is configured. If you don't like what your chosen distro has picked as the default then complain to them. systemd didn't

by MertsA 8y ago

That comes down entirely to how systemd is configured. If you don't like what your chosen distro has picked as the default then complain to them. systemd didn't force anyone's hand on the subject, they just added the feature. It's a pretty natural design choice IMHO. When I want to log out, I don't want to let some hung up daemon keep running just because it wasn't able to process the SIGHUP sent to it. How else do you propose to make sure that when I log off my ssh-agent is really terminated and not just locked up with my keys still in memory? The POSIX approach is insufficient, there's no way to know if a process received a signal and chose to ignore it and keep running or if it received a signal but it was deadlocked and kept running.

inferiorhuman 8y ago
> How else do you propose to make sure that when I log off my ssh-agent is really terminated and not just locked up with my keys still in memory? Perhaps with a signal handler?
- pas 8y ago
  That was the nice and friendly POSIX way, turns out it's really convenient for malware to stick around that way. Now user session isolation and termination works (cgroups), but it of course breaks backward comp.
semi-extrinsic 8y ago
If only there was a way for the system init program to identify and keep a list of processes it has spawned, you could imagine like a unique numerical Process ID, and then if there was a program that could check the Process Status, and another that could kill the process identified by this... PID with increasing levels of aggressiveness...
- wbl 8y ago
  PIDs get reused so this doesn't work well.
  - MertsA 8y ago
    He's sarcastically alluding to systemd's approach at solving this.
zrm 8y ago
The problem is that you're breaking compatibility by changing the default. It's one thing to add a feature that can solve a problem. It's something else to break existing programs that don't use it. If you're not going evaluate each individual program to determine whether the new behavior is appropriate then it should be opt-in rather than opt-out. Then ssh-agent and anything else that knows it should be forcefully killed can opt-in without breaking other innocent programs.
- deno 8y ago
  So you think backwards compatibility is so important that we should keep old BROKEN and INSECURE behavior just for the sake of not inconveniencing few power users with technical knowledge to override it? Instead those few loudest complaining should be catered to and regular users left for the wolves… I think some people sometimes lack any perspective on the topic.
  - wokwokwok 8y ago
    Yes. I’m not being emotional about it, just irritated. Systemd has tangibly caused me to lose work with tmux; I appreciate there are root causes for this, but frankly, if some piece of someone’s code does that, for whatever reason that is beyond my control to immediately stop using it... ...it feels justified to be annoyed. How do you suggest an alternative meaningful response would look? Create my own distribution? What tangible and meaningful alternatives do I have other than encouraging people not to use systemd?
    - deno 8y ago
      > Create my own distribution? > What tangible and meaningful alternatives do I have other than encouraging people not to use systemd? Sure, if you think you can actually “test every single program and make everything opt-in.” I think you will however find that making everyone happy and having new features are just simply contradictory by the very definition. At some point you will want new stuff and you’ll have to break something. The best you could do is adopt BSD’s model and fork tmux and other userland and ship outdated/patched versions. It’s a ton of work, of course. I am not actually seriously suggesting you create your own distro, after all you can probably just fix the annoying issue with systemd and move on with your life, and Systemd actually makes it easy for your by making it a configuration switch and supporting the non-default workflow. I am simply suggesting you put yourself in the position of someone that has to make those decisions and really think about it from that perspective. Everything’s always a trade off.
wbl 8y ago
If a process doesn't handle SIGHUP it dies. So all the daemon has to do in that case is nothing.
- MertsA 8y ago
  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.
  - inferiorhuman 8y ago
    So the answer to your hypothetical deadlock is to break everything else? What kind of complex and graceful shutdown does ssh-agent really need?
    - MertsA 8y ago
      >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.
- DyslexicAtheist 8y ago
  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).

by MertsA 8y ago

inferiorhuman 8y ago

> How else do you propose to make sure that when I log off my ssh-agent is really terminated and not just locked up with my keys still in memory? Perhaps with a signal handler?

pas 8y ago
That was the nice and friendly POSIX way, turns out it's really convenient for malware to stick around that way. Now user session isolation and termination works (cgroups), but it of course breaks backward comp.

semi-extrinsic 8y ago

If only there was a way for the system init program to identify and keep a list of processes it has spawned, you could imagine like a unique numerical Process ID, and then if there was a program that could check the Process Status, and another that could kill the process identified by this... PID with increasing levels of aggressiveness...

wbl 8y ago
PIDs get reused so this doesn't work well.
- MertsA 8y ago
  He's sarcastically alluding to systemd's approach at solving this.

zrm 8y ago

The problem is that you're breaking compatibility by changing the default. It's one thing to add a feature that can solve a problem. It's something else to break existing programs that don't use it. If you're not going evaluate each individual program to determine whether the new behavior is appropriate then it should be opt-in rather than opt-out. Then ssh-agent and anything else that knows it should be forcefully killed can opt-in without breaking other innocent programs.

deno 8y ago
So you think backwards compatibility is so important that we should keep old BROKEN and INSECURE behavior just for the sake of not inconveniencing few power users with technical knowledge to override it? Instead those few loudest complaining should be catered to and regular users left for the wolves… I think some people sometimes lack any perspective on the topic.
- wokwokwok 8y ago
  Yes. I’m not being emotional about it, just irritated. Systemd has tangibly caused me to lose work with tmux; I appreciate there are root causes for this, but frankly, if some piece of someone’s code does that, for whatever reason that is beyond my control to immediately stop using it... ...it feels justified to be annoyed. How do you suggest an alternative meaningful response would look? Create my own distribution? What tangible and meaningful alternatives do I have other than encouraging people not to use systemd?
  - deno 8y ago
    > Create my own distribution? > What tangible and meaningful alternatives do I have other than encouraging people not to use systemd? Sure, if you think you can actually “test every single program and make everything opt-in.” I think you will however find that making everyone happy and having new features are just simply contradictory by the very definition. At some point you will want new stuff and you’ll have to break something. The best you could do is adopt BSD’s model and fork tmux and other userland and ship outdated/patched versions. It’s a ton of work, of course. I am not actually seriously suggesting you create your own distro, after all you can probably just fix the annoying issue with systemd and move on with your life, and Systemd actually makes it easy for your by making it a configuration switch and supporting the non-default workflow. I am simply suggesting you put yourself in the position of someone that has to make those decisions and really think about it from that perspective. Everything’s always a trade off.

wbl 8y ago

If a process doesn't handle SIGHUP it dies. So all the daemon has to do in that case is nothing.

MertsA 8y ago
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.
- inferiorhuman 8y ago
  So the answer to your hypothetical deadlock is to break everything else? What kind of complex and graceful shutdown does ssh-agent really need?
  - MertsA 8y ago
    >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.
DyslexicAtheist 8y ago
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).