[RFE] add a way to run in a new systemd scope automatically

[keszybz]

With systemd 230 we switched to a default in which user processes started as part of a login session are terminated when the session exists (KillUserProcesses=yes). See https://github.com/systemd/systemd/blob/master/NEWS#L3, the commit that made the change: systemd/systemd@97e5530cf20, and bug reports which gave the impetus for the change: https://bugs.freedesktop.org/show_bug.cgi?id=94508, systemd/systemd#2900.

Unfortunately this means starting tmux in the usual way is not effective, because it will be killed upon logout. There are a few option to avoid that, the best being:

systemd-run --scope --user tmux

This starts tmux as a scope unit under the systemd --user instance. It would be great if tmux could do this automatically. Probably the best way to do this would be to make the dbus call to org.freedesktop.systemd1.Manager.StartTransientUnit directly from tmux. See https://github.com/systemd/systemd/blob/master/src/run/run.c#L907 for how systemd-run does it, and https://www.freedesktop.org/wiki/Software/systemd/dbus/ for the description of the API.

[nicm]

tmux is not going to use dbus. It sounds like this should be done as part of daemon(3).

[keszybz]

daemon(3) is an old BSD interface, I'm afraid it's infeasible to change it.

I think tmux is the the right place to add such functionality, because it's one of the mechanisms that people use to starts long-running processes from a user session. daemon(3) is called from daemons, which certainly should not start their own scope.

In case it wasn't clear, this dbus call should be compile time and run time optional, i.e. it should probably be only compiled in on Linux systems, and should be disableable with a switch (assuming that the default would be yes).

[nicm]

I am not suggesting you change the daemon(3) API, and I don't see why you would need to. tmux wants to leave itself running in the background - daemon() does that, in a way that is vaguely portable and works similarly on all platforms. If you want to change how processes daemonize, why don't you change how daemon() is implemented instead of adding a new API?

[keszybz]

Because I don't want to change how processes daemonize in general, just a few specific processes: tmux, screen, x2go was also mentioned.

There has been a request to add a library function to wrap the dbus call. So far I haven't considered that, but indeed it would make things easier. Would that work for you?

[nicm]

Well, tmux uses daemon() so if it needs to change so will everything else that uses daemon() (or does fork/setsid itself) and expects to stay running in the background.

An alternative libc function would be simpler, then we could just use it instead of daemon() on Linux.

[rfrancoise]

FWIW, speaking as the Debian maintainer I'm okay with adding a dependency on libsystemd to the package, but the code needs to be upstream in tmux. There's a precedent with the utempter support.

[nicm]

Well, I wouldn't say utempter is a precedent. We have it because there is no way to achieve the same functionality without making tmux setgid. I don't think we should use it as an excuse to add other dependencies.

My concern is that we have a little function, daemon(), that does a simple little procedure to make a daemon that has worked basically unchanged across multiple platforms for maybe, what, 30 years? Now to do the same thing we need to add 150 lines of new, Linux-only code AND a library dependency.

Sure, maybe the fork/setsid procedure needs to change for whatever reason. But why not make daemon() do all the new stuff for us? That's what it's there for, to hide these details.

If that won't fly, then a similar new API would be a sensible addition.

[mathstuf]

I think there is, alternatively, a way to start a new session through PAM so that systemd knows to leave tmux alone. I had a thread on the ML a few years ago about it, but PAM calls were deemed as not suitable to be in touch itself (similar to the D-Bus calls requested here). I also don't know if the PAM dance is still a valid way to do this though.

[mathstuf]

Here's the thread: http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/1849/focus=1856

[nicm]

The PAM API is certainly more compact.

Anyway, if we need to do this, the way to do it is to add osdep_daemon to all the osdep*.c files (like we have osdep_event_init) and call it instead of daemon (for most platforms it can just forward directly to daemon() itself).

[nicm]

OS X could probably also use it too. It seems they did fiddle with daemon(3) but caused a different class of problems, that needs some other code to fix.

[joshtriplett]

This is not something that all daemons should do; most daemons should not run in a new scope, but as part of the existing user scope. For instance, gpg-daemon and ssh-agent should not do this.

This is only something that programs like tmux, screen, a VNC or remote desktop daemon, or some other program that represents a distinct "interactive user session" from the program that launches it should do. (And they should only do so when starting the background service, not in the client process that connects to an existing server.)

I do think PAM sessions are the correct mechanism to use here. tmux should start a new user session using PAM, which will do the right thing not only with logind but also with any other PAM session modules that the admin might configure.

[rain-1]

@keszybv
why don't you fix systemd instead of forcing other programs to add systemd specific code?

[mathstuf]

How would systemd know that tmux is supposed to be special? And tmux and screen are different than your normal daemons (since they are essentially nested login sessions).

[lmachucab]

FWIW, speaking as the Debian maintainer I'm okay with adding a dependency on libsystemd to the package,

Why? Why should something like tmux depend on systemd? Should stuff like wget too?

Adding a Suggests, yeah, maybe. A hard Depends, no reason to.