Distributors ponder a systemd change

Posted Jun 8, 2016 8:01 UTC (Wed) by peter-b (guest, #66996)
Parent article: Distributors ponder a systemd change

This change in default configuration options seems like a really good and long-overdue improvement, and I really don't see what all the fuss is about.

Distributors ponder a systemd change

Posted Jun 8, 2016 8:28 UTC (Wed) by ovitters (guest, #27950) [Link] (6 responses)

They attempted to make the change after ensuring the affected programs (tmux, screen, nohup) are updated. Once those programs are fixed, nobody should notice. Unfortunately tmux bugreport became unreadable with lots of non-developer comments. Initially it seemed they were ok with the patch, then changed their minds. Might misunderstand things.

So current status is that people would notice. Then I can understand. Unfortunately various times maintainers reject anything to do with systemd. Leading to no other solution than to force things. Systemd developers seem to be a bit aggressive to start pushing things, but on the other hand, there's not been too many changes.

This is part of the user sessions, which Lennart talked+blogged about for many years.

Distributors ponder a systemd change

Posted Jun 8, 2016 8:52 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

Why not leave existing interfaces as they are, and make the *new* behaviour the opt-in "requires changes to programmes" behaviour?

It's much easier to update the programmes you know want the new behaviour, than find all the programmes that don't want it. If you miss programmes using the first approach, they just continue with the behaviour they're already running with anyway. For the latter approach, you don't even know if you can find all such programmes - people and organisations have private and internal code.You can't just scan code in free software distro repositories and hope to catch everything.

Distributors ponder a systemd change

Posted Jun 8, 2016 9:02 UTC (Wed) by matthias (subscriber, #94967) [Link] (2 responses)

This will not work. For more than 99% of the processes, there should be the new behaviour: getting killed if normal shutdown fails. E.g. the firefox instance that fails to shutdown when it gets SIGHUP but uses 100% CPU time instead. Problem of the old interface is that a process tells that it does not want to get terminated by intercepting SIGHUP. Unfortunately every nontrivial process (even those that do not want to survive) has to intercept SIGHUP to do a clean shutdown. If this shutdown fails the process is left running.

The old behaviour is only useful to very few programs (I always see screen, tmux, nohup mentioned), which could easily be fixed.

Distributors ponder a systemd change

Posted Jun 8, 2016 14:29 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

So many processes trap shutdown to do cleanup, but cleanup may fail.

Pray tell, how does the systemd change to just kill them outright help with that?

Distributors ponder a systemd change

Posted Jun 8, 2016 15:33 UTC (Wed) by anselm (subscriber, #2796) [Link]

Programs that want to clean up after themselves must already trap SIGTERM (which is the signal that kill(1) and friends send by default). If their cleanup process fails such that they hang or loop rather than exit, or otherwise takes longer than systemd – or for that matter shutdown(8), which follows exactly the same approach as systemd – lets them have, they get bopped on the head with a SIGKILL. This is not exactly breaking new ground.

Distributors ponder a systemd change

Posted Jun 8, 2016 11:20 UTC (Wed) by nowster (subscriber, #67) [Link]

It's not just screen and tmux -- mosh is also affected.

Distributors ponder a systemd change

Posted Jun 8, 2016 22:21 UTC (Wed) by error27 (subscriber, #8346) [Link]

"They attempted to make the change after ensuring the affected programs (tmux, screen, nohup) are updated."

That's not true. They made the change first then tried to fix tmux after everyone got enraged already. Read the tmux RFE from the article and look at the date on it. The tmux RFE was from May 27 and the Debian bug was filed on May 26.

That's the way it should have been done, but it's not the way it happened.