Agreed, at work we use nohup / screen for many important tasks. These tasks are items like doing an upgrade, or migration, or a long running script that you wan

Agreed, at work we use nohup / screen for many important tasks. These tasks are items like doing an upgrade, or migration, or a long running script that you want to protect from a dropped ssh connection. Networks are unreliable, your local system may be unreliable, and the last thing we want to happen is for a script or program to die while making changes to the system that leave it in an inconsistent state. In my limited understanding, nohup was a very simple mechanism to achieve this. So to me, when you logoff or drop a connection, the system will send a HUP to all the processes in the tree belonging to that session. If the process doesn't accept the HUP, well then it doesn't want to die right now, which is what nohup allowed you to do by intercepting / wrapping the HUP. I assume screen worked on a similar principle and just ignores the HUP since it knows you may want to re-attach later. Now it sounds like they are working on or have another way to achieve the same result in SystemD, I'm just very curious what the thoughts or reasoning is that this should be a thing. Anyways, all I can say is that to me, changing this behaviour if I didn't see the release notes or this bug, would cause some very unexpected behaviour for me interacting with a SystemD system, where some of the basic mechanisms I use and encourage for change safety would no longer work. I suspect many others also use screen/nohup, and will be in for a big surprise.