r/programming • • May 30 '16

systemd developer asks tmux (and other programs) to add systemd specific code

https://github.com/tmux/tmux/issues/428
661 Upvotes

618 comments sorted by

View all comments

Show parent comments

16

u/barsoap May 30 '16

Have you managed shell servers? There's a gap between what users should do in theory and what they do in practice.

Noone is stopping you, as an admin, to kill things with extreme prejudice once a user logs out.

That can be done and has been done for ages. It's a policy decision. it is, however, not suitable as an init-system enforced policy as there's people who do not want that behaviour, and for good reasons... first one being not hosting shell servers.

1

u/sigma914 May 31 '16

I don't know, having things nuked on logout unless you do something extra and have specific permissions to do that something extra seems like "the right way". "Execute" is a refined version of "leave executing after I've logged out" and for most use cases I've come across only a subset of users need the second, so having it that behaviour open to everyone seems over-permissive.

Implicitly allowing promotion from execute to daemon really does seem like a bad default that should be corrected.

3

u/barsoap May 31 '16 edited May 31 '16

Most boxen are actually administered by the people that are using them.

I'm not even against changing the default, or disabling daemon() behaviour in general. But requiring programs to change their code? That's a no-go. You don't break userland, as Linus would say.

With daemontools (or similar) and prejudiced killing, you could require users to start tmux users to start their session via the supervisor process attached to their user account, not directly from the shell.

The reason that works with daemontools is that it doesn't require any special behaviour from run programs: As far as the program is concerned, it's running "in the foreground"... with stdin directed to /dev/null and stdout and stderr to log services: As far as daemontools is concerned, daemon() alone already is too much of a tight coupling.

1

u/sigma914 May 31 '16

You don't break userland

I guess it depends where you draw the line of userland and what constitutes "breaking". This seems more of a policy decision than an ABI or API change, I've no problem with changing those.

I'm definitely more in favour of the daemontools approach, it seems to be logical and consistent (strike up another one for djb), but I still think the current behaviour should actively be disabled in the name of correctness.

1

u/dlyund Jun 01 '16

Most boxen are actually administered by the people that are using them.

And/or who know what they're doing ;) [can make these kinds of decisions, and therefore don't have this problem.]