3 ms·

> There's NOTHING new or innovative about this! Processes are already reaped at logout, unless they're nohup'd. Changing the state of affairs to "processes are

> There's NOTHING new or innovative about this! Processes are already reaped at logout, unless they're nohup'd. Changing the state of affairs to "processes are reaped at logout, unless they use dbus to ask systemd to not reap them" is just a bunch of mechanism churn to get the same result The difference is that pre-systemd, there is no safe way to guarantee that all processes are reaped on logout if some of the processes are written maliciously to try and avoid being reaped. The new cgroup-based system makes it impossible to evade being reaped by playing games with fork. This mechanism is valuable, but it is possibly not the best default for most systems.

icebraining 10y ago
But isn't this mechanism they're asking tmux to use a way to evade being reaped?
- msbarnett 10y ago
  Essentially. You can't guarantee reaping while allowing for opt-out semantics for things like tmux. Everyone who thinks that's some innovation being achieved here is misunderstanding it. This is originally about some GNOME daemons sticking around when they shouldn't. GNOME should just fix that, of course, but it points to the hole of it being all-or-nothing when it comes to nohup'ing. There's no good mechanism for asking for more limited lifetimes. Of course, the Right way to solve that would be to leave the existing API alone for the all/infinite lifetime case, float a proposal for a new API for the limited case, raise consensus, implement it, and encourage devs like GNOME to move to the new limited case. But that might mean actually talking to the community and building an encapsulated API that could be reimplemented on other platforms. So much easier to break everything and demand the world keep up, with the added benefit of all those raw dbus calls and hard-coded end points making portability off of your 2 billion dollar cash-cow OS just a bit incrementally harder, again.
thwarted 10y ago
The difference is that pre-systemd, there is no safe way to guarantee that all processes are reaped on logout if some of the processes are written maliciously to try and avoid being reaped. And this is a red herring. If the process is malicious, it can just as well use this systemd method to keep from being killed and continue to do its dastardly deeds in the background. Logically, this "feature" can not be about controlling purposely malicious programs, because there's no way to determine if a process is malicious or not just by asking it or by having it assert that it is not. The only reason this exists is to paper over bugs in either the way these daemons are spawned (ssh-agent and pgp-agent, for example, work best when they appear in the execution inheritance hierarchy, rather than as separately spawned programs that run as siblings) or in the way they detect that a session has ended.

icebraining 10y ago

But isn't this mechanism they're asking tmux to use a way to evade being reaped?

msbarnett 10y ago
Essentially. You can't guarantee reaping while allowing for opt-out semantics for things like tmux. Everyone who thinks that's some innovation being achieved here is misunderstanding it. This is originally about some GNOME daemons sticking around when they shouldn't. GNOME should just fix that, of course, but it points to the hole of it being all-or-nothing when it comes to nohup'ing. There's no good mechanism for asking for more limited lifetimes. Of course, the Right way to solve that would be to leave the existing API alone for the all/infinite lifetime case, float a proposal for a new API for the limited case, raise consensus, implement it, and encourage devs like GNOME to move to the new limited case. But that might mean actually talking to the community and building an encapsulated API that could be reimplemented on other platforms. So much easier to break everything and demand the world keep up, with the added benefit of all those raw dbus calls and hard-coded end points making portability off of your 2 billion dollar cash-cow OS just a bit incrementally harder, again.

thwarted 10y ago

The difference is that pre-systemd, there is no safe way to guarantee that all processes are reaped on logout if some of the processes are written maliciously to try and avoid being reaped. And this is a red herring. If the process is malicious, it can just as well use this systemd method to keep from being killed and continue to do its dastardly deeds in the background. Logically, this "feature" can not be about controlling purposely malicious programs, because there's no way to determine if a process is malicious or not just by asking it or by having it assert that it is not. The only reason this exists is to paper over bugs in either the way these daemons are spawned (ssh-agent and pgp-agent, for example, work best when they appear in the execution inheritance hierarchy, rather than as separately spawned programs that run as siblings) or in the way they detect that a session has ended.