4 ms·

Okay, then maybe the complexity doesn't come from the .service/.socket files but from the used mechanisms. A colleague of mine had the problem that one of his

by chme 10y ago

Okay, then maybe the complexity doesn't come from the .service/.socket files but from the used mechanisms. A colleague of mine had the problem that one of his applications was shut down because the user context which this service belonged to, logged out/disconnected (I think it was a system user). So he had to hack something together to ensure that the service is not affected by this.

ZZBop 10y ago
Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf.
- kuschku 10y ago
  And then logout and login again, and have 200 sessions of shitty daemons like megasync or dropbox in your process manager. No thanks.
  - ZZBop 10y ago
    Individual daemons can be tuned with systemd-run/loginctl linger - but I guess posting snarky comments on HN is way more constructive than RTFM.
    - kuschku 10y ago
      Yes, exactly. That’s how it’s supposed to be: Everything is killed by default, and you have to elevate it with systemd-run to make it work properly. Allowing any process to linger around by default is just stupid, which is why "Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf." is as horrible advice as "just add your own user to the root group".
      - digi_owl 10y ago
        In other words, systemd has reinvented nohup and crew...
        kuschku 10y ago
        Except, this time with a working permission system, and proper limits per user. That’s something no other competitor has provided before.
MertsA 10y ago
So what you're referring to is that he had some unit started within some user's scope and then killed the scope which promptly stopped his unit. This behavior was actually not the default on most distros until not too terribly long ago. Basically, the way this used to work was that on logout, all of the user's processes would get signaled that they need to close but it was up to the application to handle how to respond to that signal. Sometimes daemons would misbehave and there's nothing to differentiate "this app is supposed to end but hasn't" and "this app is choosing to ignore the signal because it needs to stay running". With systemd, there is an option to reap these processes so that when you log out, you never have to worry about some misbehaving process hanging around and causing problems when you log back in. The way to fix this without disabling the feature is by explicitly putting the process in it's own scope. That doesn't take special permissions to do, it's just that it needs to be done explicitly instead of just ignoring SIGHUP.
JdeBP 10y ago
Your colleague could always push for systemd to be fixed. The world knows the program and the function to fix. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221
- digi_owl 10y ago
  I may be reading it wrong, but it seems to me that Pitt it more interested in doubling down on the new default. https://lists.freedesktop.org/archives/systemd-devel/2016-July/037017.html https://lists.freedesktop.org/archives/systemd-devel/2016-Ju...

by chme 10y ago

ZZBop 10y ago

Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf.

kuschku 10y ago
And then logout and login again, and have 200 sessions of shitty daemons like megasync or dropbox in your process manager. No thanks.
- ZZBop 10y ago
  Individual daemons can be tuned with systemd-run/loginctl linger - but I guess posting snarky comments on HN is way more constructive than RTFM.
  - kuschku 10y ago
    Yes, exactly. That’s how it’s supposed to be: Everything is killed by default, and you have to elevate it with systemd-run to make it work properly. Allowing any process to linger around by default is just stupid, which is why "Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf." is as horrible advice as "just add your own user to the root group".
    - digi_owl 10y ago
      In other words, systemd has reinvented nohup and crew...
      - kuschku 10y ago
        Except, this time with a working permission system, and proper limits per user. That’s something no other competitor has provided before.

MertsA 10y ago

So what you're referring to is that he had some unit started within some user's scope and then killed the scope which promptly stopped his unit. This behavior was actually not the default on most distros until not too terribly long ago. Basically, the way this used to work was that on logout, all of the user's processes would get signaled that they need to close but it was up to the application to handle how to respond to that signal. Sometimes daemons would misbehave and there's nothing to differentiate "this app is supposed to end but hasn't" and "this app is choosing to ignore the signal because it needs to stay running". With systemd, there is an option to reap these processes so that when you log out, you never have to worry about some misbehaving process hanging around and causing problems when you log back in. The way to fix this without disabling the feature is by explicitly putting the process in it's own scope. That doesn't take special permissions to do, it's just that it needs to be done explicitly instead of just ignoring SIGHUP.

JdeBP 10y ago

Your colleague could always push for systemd to be fixed. The world knows the program and the function to fix. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221

digi_owl 10y ago
I may be reading it wrong, but it seems to me that Pitt it more interested in doubling down on the new default. https://lists.freedesktop.org/archives/systemd-devel/2016-July/037017.html https://lists.freedesktop.org/archives/systemd-devel/2016-Ju...