Hacker News new | past | comments | ask | show | jobs | submit login

Not sure if sarcastic, but the systemd default makes sense. Why should random processes linger in a background, with an ill defined “not answering a signal” hack? There is no distinction between a frozen process and tmux. They can easily register a user service and continue running there.



It wasn't respecting things that have been considered normal for a while. Even calling setsid(), which tmux does, didn't save it from being killed. Same for nohup.

When the systemd people say session, they mean you would have to specifically do some kind of dbus call I'm not familiar with.


> They can easily register a user service and continue running there.

Typically this was an issue on B) workstations, and B) servers, where you might log in as a regular user without super user access.

And this[1] (might?) now work as advertised in the documentation - but the discussion around the bug doesn't induce great confidence...

https://github.com/systemd/systemd/issues/3388

[1] example no 5 here: https://www.man7.org/linux/man-pages/man1/systemd-run.1.html...


Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack? That's a well defined, long established, normal way of doing things on UNIX and Linux systems. Also, that really isn't a good way of detecting frozen processes, since in your world, the only answers you'd ever get are "it's frozen" or "it wasn't frozen and now it's dead".

> They can easily register a user service and continue running there.

So systemd came in and broke the 50-year-old way of doing things, and now the programs that got broken should all have to add systemd-specific code to work again?


> Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack?

Yes. Just because it is 50-years-old doesn’t make it suddenly a valid approach. There are 4 states here - process running with usual semantics for closing, process running that would like to linger in the background, and the frozen version of this two. How should a service manager/resource handle — that is very much in-scope for systemd differentiate between a frozen process that should very much be cleaned up in the no-linger case, and any process wanting to linger? And there are well-established ways to determine whether a process is frozen — pinging it expecting a specific answer.

Systemd differentiates between no-linger/linger by introducing user services - one should only write a trivial alias/wrapper script for tmux and can continue to use it to their liking. Also, it has a compile time flag, as well as a runtime config one - it is up to the distro or the user to revert back to the old way.


What ways are there to tell if a process is frozen that only work if it registers a systemd user service?


Is setsid() also a hack?




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: