81–90 of 458 posts
Earlier quoted context omitted.
To answer your question: remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) - there is no screen session because it was killed by systemd immediately after log out. (syslog entry: May 3 09:01:25 $HOSTNAME systemd[1]: session-6.scope: Killing process 3290 (screen) with signal SIGTERM. ) But that's hardly the point, the point is the toxic "you're doing it wrong" mentality that infest…
> remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) I just tried it on a fully up-to-date CentOS 8 box (which uses systemd), and it worked perfectly fine: after logging back in through ssh, `screen -r` restored the screen session as expected. From what I have read, that screen session would only be killed if I had set KillUserProcesses=yes on /etc/systemd/logind.conf, which is not…
This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes".
https://github.com/systemd/systemd/blob/2d4f8cf467b6825c9127...
Earlier quoted context omitted.
This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user sess…
I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back. Help me..
Earlier quoted context omitted.
This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think un…
Why exactly should students not be able to use CPU cycles while not logged in? I certainly did this as a student and would probably not have complained if it decided to kill my processes when doing so.
It’s a scenario that might make sense here. But then again, having a watchdog script just kill leftover processes has been doing this same job for forever. Including this use case in systemd seems like overreach.
Earlier quoted context omitted.
This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user sess…
I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back. Help me..
One problem is that a number of reinventions were poorly made.
E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas.
Another problem is the "I know better" attitude.
Are user processes allowed to run after logout? Which DNS to use during startup? What logging in should look like? In each such case, existing behavior which was widely considered as not broken was replaced by a different behavior, often even without an escape hatch. The new behavior(s) in such cases should be made possible, but the default should be the old behavior.
No wonder I don't run systemd on my desktops / laptops.
Earlier quoted context omitted.
This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user sess…
I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back. Help me..
Earlier quoted context omitted.
> remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) I just tried it on a fully up-to-date CentOS 8 box (which uses systemd), and it worked perfectly fine: after logging back in through ssh, `screen -r` restored the screen session as expected. From what I have read, that screen session would only be killed if I had set KillUserProcesses=yes on /etc/systemd/logind.conf, which is not…
It is the default. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes". https://github.com/systemd/systemd/blob/2d4f8cf467b6825c9127...
The upstream default has changed, but CentOS still uses the old default.
Earlier quoted context omitted.
But systemd-resolved is such an odd complaint since it’s only connection to systemd is the name and that it’s in the same repo. It’s not connected to the init system at all.
The entire repo is a big ball of mud. No one knows which parts can be removed without breaking things. Heck, the author of this article couldn’t even find a design doc or adequate manual for the init part of the train wreck, and it’s been in development for ten years .