3 ms·

I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of

I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?

kaba0 4y ago
How is systemd not under the user’s control? It is an init and service management system and long-running processes are services. Where else should it be managed? Systemd is the only component that knows whether you are logged in/out, whether you still have another seat open, etc. And its responsibility is to properly close resources, and not let unannounced processes to linger needlessly in the background.
- erik_seaberg 4y ago
  init belongs to root. Only sysadmins can choose it (or not) and configure it, so only they should have reasons to interact with it or understand its UI.
- effie 4y ago
  systemd is usually a root process, regular user does not control it. Whether user being logged off means no such user processes should run is a policy question that has different answer on different systems and depends on the user as well. Systemd "unified solution" - killing user processes on logout - is not working well for many people especially on shared machines.
teddyh 4y ago
systemd-logind(1) manages user sessions. If you want to replicate the functionality of what “nohup” used to give you, I am reliably informed that “systemd-run --scope --user $command” does the right thing. Or, you can enable it permanently for your user with “loginctl enable-linger”.
- erik_seaberg 4y ago
  When I see “manages user sessions,” I don’t know what that phrase means. What is a “session” (again assuming not a POSIX session leader) and what are we concretely doing to “manage” it? Is there a guide that explains the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? I would never expect a non-sysadmin to have read the “systemd-run” or “loginctl” manpages or know how to find them. I’m a nerd and even I don’t know how to get to the point of understanding what https://man7.org/linux/man-pages/man1/systemd-run.1.html https://man7.org/linux/man-pages/man1/systemd-run.1.html is trying to tell me.
  - teddyh 4y ago
    I mentioned systemd-logind. Its manual page systemd-logind(8) states¹: “See sd-login(3)² for information about the basic concepts of logind such as users, sessions and seats.”. 1. https://manpages.debian.org/stable/systemd/systemd-logind.8.en.html https://manpages.debian.org/stable/systemd/systemd-logind.8.... 2. https://manpages.debian.org/bullseye/libsystemd-dev/sd-login.3.en.html https://manpages.debian.org/bullseye/libsystemd-dev/sd-login...
  - effie 4y ago
    > the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? That is bound to be a losing strategy. Systemd development (of breaking changes) is not stopping anytime soon. The simplest solution is to switch to an OS without systemd, like Devuan or Alpine or BSD.

kaba0 4y ago

How is systemd not under the user’s control? It is an init and service management system and long-running processes are services. Where else should it be managed? Systemd is the only component that knows whether you are logged in/out, whether you still have another seat open, etc. And its responsibility is to properly close resources, and not let unannounced processes to linger needlessly in the background.

erik_seaberg 4y ago
init belongs to root. Only sysadmins can choose it (or not) and configure it, so only they should have reasons to interact with it or understand its UI.
effie 4y ago
systemd is usually a root process, regular user does not control it. Whether user being logged off means no such user processes should run is a policy question that has different answer on different systems and depends on the user as well. Systemd "unified solution" - killing user processes on logout - is not working well for many people especially on shared machines.

teddyh 4y ago

systemd-logind(1) manages user sessions. If you want to replicate the functionality of what “nohup” used to give you, I am reliably informed that “systemd-run --scope --user $command” does the right thing. Or, you can enable it permanently for your user with “loginctl enable-linger”.

erik_seaberg 4y ago
When I see “manages user sessions,” I don’t know what that phrase means. What is a “session” (again assuming not a POSIX session leader) and what are we concretely doing to “manage” it? Is there a guide that explains the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? I would never expect a non-sysadmin to have read the “systemd-run” or “loginctl” manpages or know how to find them. I’m a nerd and even I don’t know how to get to the point of understanding what https://man7.org/linux/man-pages/man1/systemd-run.1.html https://man7.org/linux/man-pages/man1/systemd-run.1.html is trying to tell me.
- teddyh 4y ago
  I mentioned systemd-logind. Its manual page systemd-logind(8) states¹: “See sd-login(3)² for information about the basic concepts of logind such as users, sessions and seats.”. 1. https://manpages.debian.org/stable/systemd/systemd-logind.8.en.html https://manpages.debian.org/stable/systemd/systemd-logind.8.... 2. https://manpages.debian.org/bullseye/libsystemd-dev/sd-login.3.en.html https://manpages.debian.org/bullseye/libsystemd-dev/sd-login...
- effie 4y ago
  > the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? That is bound to be a losing strategy. Systemd development (of breaking changes) is not stopping anytime soon. The simplest solution is to switch to an OS without systemd, like Devuan or Alpine or BSD.