6 ms·

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 kil

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 infests the systemd project and its adherents. I've run into this in so many ways since ceding defeat and allowing it onto my systems. This is just the latest in a long line of examples.

cesarb 6y ago
> 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 the default.
- deleted 6y ago
  [deleted]
- ttctciyf 6y ago
  Switching to CentOS in order to use screen is not an appealing option, and the config appears not to work on my current distro (that might be my poor testing, but it's certainly not the default anyhow.) I understand Slackware still lacks systemd, so maybe that's a better choice for me :)
  - fsh 6y ago
    Please submit a bug report if the option doesn't work for you.
- tyingq 6y ago
  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/2d4f8cf467b6825c91276808250823a29ab461fe/NEWS#L4356 https://github.com/systemd/systemd/blob/2d4f8cf467b6825c9127...
  - frio 6y ago
    This is one of those fun situations where everyone's right. The upstream default has changed, but CentOS still uses the old default.
    - m45t3r 6y ago
      Almost every distro I know turns this option off by default, including Arch, NixOS and Debian (the last one I am not sure).
      - fsh 6y ago
        It defaults to "no" on Debian 10. Maybe Fedora changed the default?
        Conan_Kudo 6y ago
        Fedora does not have this feature on: https://src.fedoraproject.org/rpms/systemd/blob/265d91aff516c0e0a13da9ed7613cd0cbfba9e9c/f/systemd.spec#_369 https://src.fedoraproject.org/rpms/systemd/blob/265d91aff516...
        dTal 6y ago
        That's most interesting, given that both systemd and Fedora are Red Hat products. If there's one distro that would use the systemd defaults, I would expect it to be Fedora. Who exactly are these defaults for, then?
        6y ago
deleted 6y ago
[deleted]
hedora 6y ago
Based on one of the sibling comments, if you modify screen to add a runtime dependency on systemd, the problem will go away. I agree this is totally unacceptable, and that the inevitable tone deaf response to such complaints is also unacceptable.
- Spivak 6y ago
  Is it that weird that if you want to run a job in the background outside your session that ask your service manager to spawn the job? I mean all of this is just a difference of opinion between, "I want a process supervisor to manage all my background jobs" and "I just want to double fork and throw processes at init."
anon102010 6y ago
I'm not getting this at all - so this is a can't duplicate. What distro are you using?
- ttctciyf 6y ago
  The box in question is in use as a media server, but reloading logind logs out the X session, so it wasn't really possible to test properly until today. Having the opportunity to restart the machine (probably I just needed to systemctl daemon-reload?) the "don't kill my processes bro" options are working. The distro is kde neon. The point isn't that I can't (or the distro maintainers can't) get it to work, the point is that the aggressive systemd default breaks established practice, and that this is typical systemd behaviour: arrogant and uncaring. IOW user-hostile in the fullest sense of the term. It's not like this is an isolated example.
yrro 6y ago
Which distro is this?

cesarb 6y ago

> 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 the default.

deleted 6y ago
[deleted]
ttctciyf 6y ago
Switching to CentOS in order to use screen is not an appealing option, and the config appears not to work on my current distro (that might be my poor testing, but it's certainly not the default anyhow.) I understand Slackware still lacks systemd, so maybe that's a better choice for me :)
- fsh 6y ago
  Please submit a bug report if the option doesn't work for you.
tyingq 6y ago
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/2d4f8cf467b6825c91276808250823a29ab461fe/NEWS#L4356 https://github.com/systemd/systemd/blob/2d4f8cf467b6825c9127...
- frio 6y ago
  This is one of those fun situations where everyone's right. The upstream default has changed, but CentOS still uses the old default.
  - m45t3r 6y ago
    Almost every distro I know turns this option off by default, including Arch, NixOS and Debian (the last one I am not sure).
    - fsh 6y ago
      It defaults to "no" on Debian 10. Maybe Fedora changed the default?
      - Conan_Kudo 6y ago
        Fedora does not have this feature on: https://src.fedoraproject.org/rpms/systemd/blob/265d91aff516c0e0a13da9ed7613cd0cbfba9e9c/f/systemd.spec#_369 https://src.fedoraproject.org/rpms/systemd/blob/265d91aff516...
        dTal 6y ago
        That's most interesting, given that both systemd and Fedora are Red Hat products. If there's one distro that would use the systemd defaults, I would expect it to be Fedora. Who exactly are these defaults for, then?
        6y ago

deleted 6y ago

[deleted]

hedora 6y ago

Based on one of the sibling comments, if you modify screen to add a runtime dependency on systemd, the problem will go away. I agree this is totally unacceptable, and that the inevitable tone deaf response to such complaints is also unacceptable.

Spivak 6y ago
Is it that weird that if you want to run a job in the background outside your session that ask your service manager to spawn the job? I mean all of this is just a difference of opinion between, "I want a process supervisor to manage all my background jobs" and "I just want to double fork and throw processes at init."

anon102010 6y ago

I'm not getting this at all - so this is a can't duplicate. What distro are you using?

ttctciyf 6y ago
The box in question is in use as a media server, but reloading logind logs out the X session, so it wasn't really possible to test properly until today. Having the opportunity to restart the machine (probably I just needed to systemctl daemon-reload?) the "don't kill my processes bro" options are working. The distro is kde neon. The point isn't that I can't (or the distro maintainers can't) get it to work, the point is that the aggressive systemd default breaks established practice, and that this is typical systemd behaviour: arrogant and uncaring. IOW user-hostile in the fullest sense of the term. It's not like this is an isolated example.

yrro 6y ago

Which distro is this?