@furycd001@nutbutter Technically, it’s broken. If you run screen/tmux built without systemd support, it will be killed on logout. Systemd requires every program that needs daemonize link libsystemd0 only to notify systemd to keep it running. So it’s broken, but worked-around in every software which need daemonize
If you run screen/tmux built without systemd support, it will be killed on logout.
Actually, if you run anything and logout, it will be killed after a timeout. The way to prevent this in systemd land is to enable-linger for that user.
IMO this is a pretty sane default and it’s easy enough to disable for users
@InnerScientist This might be good behaviour (especially on shared multiuser system)
But how often you using shared multiuser systems in 2025? In 2015? In 2010 this might be useful, but now we are using containers instead.
When you have single root user, single unpriveleged user and few service users, such behaviour is just useless. If interactive user left some services running, it’s usually intentional. And systemd requires notify about this intention every time. Why? It’s just useless complexity.
Systemd requires every program that needs daemonize link libsystemd0
No, that’s only if you want the health check feature, so that systemd can distinguish between e.g. “The process is started” and “The HTTP server is bound and listening”
You can run hello world and a sleep() loop as a systemd daemon. You can run a Bash script as a systemd daemon.
I’m pretty sure that notification is also like 5 lines of code. You read an env var and that tells you a pipe to send a single character on.
You are not obligated to use libsystemd. And if you were you could certainly layer another init system inside of it
@furycd001 @nutbutter Technically, it’s broken. If you run screen/tmux built without systemd support, it will be killed on logout. Systemd requires every program that needs daemonize link libsystemd0 only to notify systemd to keep it running. So it’s broken, but worked-around in every software which need daemonize
Actually, if you run anything and logout, it will be killed after a timeout. The way to prevent this in systemd land is to enable-linger for that user.
IMO this is a pretty sane default and it’s easy enough to disable for users
EDIT: For non-root users
@InnerScientist This might be good behaviour (especially on shared multiuser system)
But how often you using shared multiuser systems in 2025? In 2015? In 2010 this might be useful, but now we are using containers instead.
When you have single root user, single unpriveleged user and few service users, such behaviour is just useless. If interactive user left some services running, it’s usually intentional. And systemd requires notify about this intention every time. Why? It’s just useless complexity.
No, that’s only if you want the health check feature, so that systemd can distinguish between e.g. “The process is started” and “The HTTP server is bound and listening”
You can run hello world and a
sleep()loop as a systemd daemon. You can run a Bash script as a systemd daemon.I’m pretty sure that notification is also like 5 lines of code. You read an env var and that tells you a pipe to send a single character on.
You are not obligated to use libsystemd. And if you were you could certainly layer another init system inside of it
So, running a program incompatible with a particular system leads to incompatibilities?
Wow, who’d have thought…
That sounds like a design decision (not saying it’s good or bad here), not something broken.