New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFE] add a way to run in a new systemd scope automatically #428
Comments
tmux is not going to use dbus. It sounds like this should be done as part of daemon(3). |
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). |
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? |
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? |
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. |
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. |
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. |
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. |
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). |
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. |
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. |
@keszybv |
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). |
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. |
I have thought about it further and I don't think I will accept a
|
Would you mind me opening a PR with my patches here so that folks interested can easily find it to at least try out? |
Or somebody could go find the actual problem @keszybz saw here - systemd/systemd#3005 - which is:
fix that, and stop trying to make systemd break the world because somebody's gnome session doesn't currently exit cleanly. |
On Sat, May 28, 2016 at 01:37:50PM -0700, Nicholas Marriott wrote:
I certainly wouldn't suggest adding systemd-specific code; a systemd However, PAM is supposed to be the correct way to start a user session. If you're concerned about the overhead of PAM support, would you |
loginctl enable-linger |
There are probably a couple decent ways that systemd can be told these are 'special'. First way is to tell systemd these are special via a service file. Tell people that want to use tmux/screen/etc to start them then as 'systemctl --user start tmux'. Second way is by wrapping the tmux/etc commands in a simple shell script that runs 'systemd-run' in a way to indicate not to kill this process. I am hoping that there is a 'lingering' option that can be set per-user service file or 'systemd-run' to allow this to happen. Being able to set a 'linger' per-service rather then for all user's programs via 'loginctl' seems like a better solution because then it wouldn't be a 'all or nothing' choice. I feel this is better because it won't require software authors to code special PAM support just to deal with systemd + Linux. It can be used by distributions to maintain expected behavior for these classes of programs. And, finally, it will make life easier for users/developers that wish to make new programs of these types and have things 'just work' by providing a suitable service file in their source code. |
So then we get to the next iteration where the “tell systemd I want to stay running in the background” step has become part of everyone’s dæmonization recipe, and now you’re back to square 1 where a user exits their session but a bunch of unwanted processes stick around. Result: a long period of making everything in world depend on systemd, followed by nothing gained for all the pain. |
IMHO, This sounds more like there needs to be a Changing semantics of existing functionality however seems unwise. (And then maybe, people who have a foot-to-gun-ratio greater than 2 can tell systemd to prefer one instead of the other, instead of covering earth with a foot assassination squad) I half expected such a mechanism to already exist, but my reading of That seems to be why we're where we are now, because everyone who wants "exit on user vanishes" has to manually implement painful mechanics ... so they opt not to and just reach for a full daemon. |
Honestly, I don't see why processes should be able to decide that they should run forever. I'm completely fine with starting specific processes with systemd user scope. This is just something new for people who use systemd what they need to learn. |
I haven't had time to participate in open source for a few years. Now I'm coming back to it, I'm a bit shocked by this. Persistent screen and tmux sessions were common enough many years before systemd was released. If systemd won't make it easy for users to set up and manage these sessions, that's systemd's problem, not tmux's. |
See tmux/tmux#428 for more about the issue.
I've met this kind of problem already: I was using |
@lilydjwg That's a different problem. You need to have SSH configured to use PAM (typically the default), and have pam_systemd installed. That will then start a new user session for SSH, rather than leaving the logged-in user processes as part of the SSH socket unit's scope. |
Any chance you can shift this discussion elsewhere? It's not anything to do
|
@ThomasAdam @nicm |
Yeah, it's making the rounds on Twitter, as a "wtf systemd" sort of thing. Closing comments might be best. |
Hey, to anybody who say this because I tweeted it in a fit of aggravation - please use the thumbs up or whatever thing to add 1 to one of the numbers underneath my comment rather than making another comment that doesn't need to be here on an already-closed-as-reject-issue. (@wisq - more part 3 of 3 of a wtf systemd tweet stream of mine, I suspect, but that doesn't help, of course) |
Was a simple API ever added to allow applications to do this? I don't see anything obvious in the libsystemd source... something like On OS X we now do this which is rather inscrutable (if at least compact), if someone has a similar block of code for Linux we can do that too:
Probably best to email me or open a new issue if you have something. |
OK someone pointed me to some other code that does this a bit more concisely (thanks), so I have worked it out and it not that much more than the voodoo we already have for OS X. However I only have CentOS 7, Debian and Ubuntu VMs... CentOS 7 seems to be too old, both Debian and Ubuntu have a new systemd but both must have turned off or worked around this behaviour already because tmux stays around when I log out. On Debian the code doesn't seem to work at all ( Ubuntu the code runs but I haven't used systemd before and I can't figure out where to see this has worked ( Anyway, if anyone still has this problem, please try applying this against master and configuring with |
@nicm Your patch works. The tmux is indeed running inside a scope: $ systemctl --user list-units | grep scope
init.scope loaded active running System and Service Manager
tmux-142.scope loaded active running tmux-142.scope And when However it will still be killed by systemd some time (10s by default) after the user logs out completely if linger for the user isn't enabled (default). An interesting thing is that, by default on my system, when tmux isn't put into a scope and survives a ssh logout because of My system is Arch Linux with systemd 245.5-2 and I was testing with lxc. BTW this shouldn't need X installed since nothing about X involved (however I do have it installed with the test above). |
Thanks for testing.
I don't follow - so even with this change tmux will be killed after logout by default, or is that not the default? I don't mind it being killed if the user explicitly configured it.
It must be a problem in Debian I guess then. |
Yes, all processes created by the user's systemd instance (basically any processes not created by other users / services) will be killed after the user is completely logged out by default. Users who want to run daemons need to run There are chances that tmux without this change survives a ssh logout due to the |
Thanks. Does the same happen with tmux started with |
Yes, they are the same, just with a different scope name. |
OK thanks. So in summary:
Does this sound accurate? Unless there is also a way for tmux to turn off this I'll have a look and see if there is a way to do it later on. |
The "daemons started at boot" shouldn't be a big problem since users don't have any daemons by default so there will be only the user's systemd instance running. (It does keep user-activated services running, e.g. D-Bus.) On a server users probably want to enable linger so they can run their services. Yes I don't think this patch brings much benefit given the current situation and users can use Personally I use |
Yes I think you're right, although it is a little unfortunate - my concern at the moment is less people like you who understand what they are doing and more with new users for whom it would be better if tmux could just work out of the box without having to fiddle with additional configuration. But it does seem like many system maintainers or tmux packagers have already made the necessary changes, so perhaps those users are already served well enough. I'll leave this for the moment unless anything else comes up. |
On Tue, May 05, 2020 at 12:33:13AM -0700, Nicholas Marriott wrote:
Unless there is also a way for tmux to turn off this `linger` option itself it sounds like this change doesn't bring much benefit, especially since I expect most users or packagers have already solved this is some way.
It's technically possible for a program to set the `linger` option,
though I think that might be surprising behavior to do by default.
(Doing so with some explicit "auto-enable-linger" configuration option
seems reasonable, though.)
It would also be possible for tmux to *detect* the current state of the
`linger` option, and print a warning message for the user when they
detach, suggesting that they enable lingering.
|
I am not going to have tmux change options that affect other applications as well, that is a receipe for disaster.
I think this is neither one thing nor the other. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
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:
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.
The text was updated successfully, but these errors were encountered: