What does happen when we logout?

olive · 2016-10-31 07:49:26

The question may seem simple but I am confused. Sometimes background processes may remain after we logout. From a few experiments:

With lightdm, any process launched by hand and disowned from the terminal remain after we logout (and if this is the case, several other processes remains too and loginctl think that there is still a session).
With lxdm any processes launched from the session is killed. But if I switch to the console and launch a process from there, quiting the X session does not terminate this process which remain.

I am totally confused, what does happens when we logout? How lxdm can know which process belong to the Xsession? Would it be possible to completely detach a process from the X session?

Last edited by olive (2016-10-31 08:17:59)

berbae · 2016-10-31 08:59:30

You could study the manual entries:

systemd
systemd-logind
logind.conf
systemd-cgls
systemd.scope

The command systemd-cgls is useful to show how processes are grouped in the user session scope and the user-1000.slice, for example.

And the 'KillUserProcesses=' parameter of /etc/systemd/logind.conf controls how the user processes are killed when logging out.

Last edited by berbae (2016-10-31 09:01:57)

Trilby · 2016-10-31 11:52:01

olive wrote:

Would it be possible to completely detach a process ~~from the X session?~~

X really has nothing to do with this question. You'll find you'll figure it out a lot quicker if you don't think of X as special, it's not. It's just a program that happens to spawn many other programs. But so are most shell scripts, so is every terminal (gui or tty) session, so is your init system, etc.

Is it possible to completely detach a process? Yes, read `man setsid` (there are other ways too).

olive · 2016-10-31 13:07:56

Trilby wrote:

X really has nothing to do with this question. You'll find you'll figure it out a lot quicker if you don't think of X as special, it's not. It's just a program that happens to spawn many other programs. But so are most shell scripts, so is every terminal (gui or tty) session, so is your init system, etc.
Is it possible to completely detach a process? Yes, read `man setsid` (there are other ways too).

You are right that X itself has nothing to do. But I think the display manager (or the agetty command on a terminal) has something to do, probably with an interaction with systemd. There is a notion of session that is not clear. setsid does not work. Just make that experiment: launch a background process, for example "setsid sleep 1000" ; then list your session with loginctl and kill your session with "loginctl kill-session c1" (with c1 is the number you have seen previously). Now login as root and check that the "sleep 1000" has been killed. So there is a notion of session that does not rely on the setsid. berbae gives some hints about how it works but is not yet clear for me. I wonder if it is possible to launch a process that does not get killed with "loginctl kill-session" i.e. a process that is completely detached from the session as systemd understand it.

Last edited by olive (2016-10-31 13:09:31)

seth · 2016-10-31 13:44:58

Trilby wrote:

X really has nothing to do with this question.

Yesno.
Most X11 clients will terminate (or crash ;-) when loosing the connection to the X server, so if you terminate X11, stuff you ran on that server (ie. linking libX11/xcb and talking X11) will typically not survive that.

Trilby · 2016-10-31 16:30:25

Yes seth but that's not unique to X. If you remove a resource used by any process, that process may crash or behave erradically.

Background any process that reads/writes to a pipe or fifo, then delete the pipe or fifo: crash, error, or worst case it will eat 100% of the CPU.

drcouzelis · 2016-10-31 16:39:16

...now I'm confused.

If I log in, start X, open a terminal window, start tmux, Ctrl+B - D to detach, then log out completely, the shell session started in tmux is still running, correct?

Is there any setting that would cause this NOT to be the case? (and tmux would instead close on log out?)

Last edited by drcouzelis (2016-10-31 17:29:32)

Trilby · 2016-10-31 17:13:33

Good example drcouzelis, but why does that lead to confusion? The tmux process does not depend on any of the resources of the parent process (It doesn't need X, it doesn't need any X-opened pipes or fifos). So when "detached" or given other settings so tmux is not the child of an X-related process there is no reason for it to close when X closes.

An illustration from my current pstree output:

systemd─┬─2*[agetty]
        ├─dbus-daemon
        ├─dhcpcd
        ├─login───xinit─┬─Xorg
        │               └─tmuxwm───urxvt───tmux: client
        ├─systemd─** trimmed **
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-udevd
        ├─tmux: server─┬─bash───pstree
        │              └─2*[bash]
        └─wpa_supplicant

Tmux was launched from a terminal within X as noted on the 4th line. But it runs as it's own process as can be seen in the third from last line.

All of these processes are under systemd though, so if systemd stops, so do they. Also there is a qutebrowser process and all of it's child processes that I also removed from the tree. The qutebrowser process*is* under xinit, so when xinit ends, so does qutebrowser (unless setsid'ed disowned, or otherwise protected from that).

Agian this has absolutely nothing to do with X. This is just *nix process management. Certain changes lead to signals being sent to all child processes of a given process. Some child processes listen to these signals, some don't.

seth · 2016-10-31 17:19:47

Trilby wrote:

If you remove a resource used by any process

Which is not the case here. Technically it's more like your browser quits because it can no longer access the network, ie. there's no hard dep on the X server as a resource and the situation could be handled gracefully to the degree of handing the client to another server (or waiting until the server re-appears)

The clients are not child processes of X11, do not hard rely on any resources (accessing a gone drawable or server will simply get you an error) and do not hiccup for a closed pipe/socket either. The just don't get responses anymore and the reaction to is completely in their hands.

Otoh, the typical behaviour (and that's the point) will prevent X11 clients from surviving X11 terminations, no matter whether they're detach'd, nohup'd or what KillUserProcesses says.

@drcouzelis, afaiu KillUserProcesses would control this but otherwise that's pretty much the idea behind tmux.

Trilby · 2016-10-31 17:26:07

That's complete nonsense. The browser can still access the network when X finishes. The network is still up. The problem is precisely the bad drawable or similar. The program may not crash specifically due to trying to access a no-longer existent drawable (meaning yes it will just get an error), but most X clients will not continue after getting such an error: some will close gracefully, some will crash poorly, but a vast majority of X11 clients will close when the x server is no longer available. It's certainly possible to make X11 clients that will stick around and wait for the X server to restart - I've actually made such tools - they are just not common.

Such a program, if launched from a WM but not detacted or setsid'ed or something similar will still exit when X exists as it's a child of the xinit process (or startx, or whatever).

olive · 2016-10-31 17:28:13

@Trilby. Although I agree that X does not play a role, your explanation is not completely true. Start a process with setsid: "setsid sleep 10000 &". Check with pstree that the parent of the sleep process is init (in modern system init is systemd, use the pstree -p command to see that the parent process is indeed the systemd launched as init i.e. init id 1). Now kill your session with "loginctl kill-session" and check that the sleep has been killed. Of course the init program has not exited. If instead we launch the sleep 1000 in the console instead of a terminal, then the sleep command remain. There is a notion of session that is completely independent with what you see with pstree.

Trilby · 2016-10-31 17:32:31

Olive, you're comparing apples and organges. I did just do the *actual* test of whether X is relevant: I ran `setsid sleep 10000` (not no ampersand, that can do weird things with setsid). I launched this sleep from urxvt, a terminal emulator in X. Then I ran `killall xinit` - this ended my x session, and because I start X with `exec xinit` it also logged me out. Guess what, sleep was still running. I logged back in, restarted X, and sleep was still running.

"loginctl kill-session" is not simply ending your X session. So again, this is not about Xorg/X11 - that's a red herring. Loginctl kill-session specifically sends a kill signal to all of your users processes.

olive wrote:

There is a notion of session that is completely independent with what you see with pstree.

This is certainly true. I never said otherwise. I was using pstree output as a useful illustration - I did not mean to imply that all information to be had could be viewed in that illustration.

seth · 2016-10-31 17:35:46

Trilby wrote:

The browser can still access the network when X finishes.

The browser was meant as analog and not related to the actual X11 thing at all.

Trilby wrote:

but most X clients will not continue after getting such an error

What is *precisely* what I said?

Trilby wrote:

Such a program, if [...] not detacted [...]

True, but unrelated likewise. I guess we're talking past each other?

seth · 2016-10-31 17:37:21

Trilby wrote:

All of these processes are under systemd though, so if systemd stops, so do they.

Not exactly - tmux will have PPID 1, so when "systemd" stops, everything stops ;-)

Systemd gained the habit to kill all processes of "a session" (ie in the cgroup), see https://wiki.archlinux.org/index.php/Sy … _on_logout
It's not the default behavior on Arch though (and was pretty much objected)

Arch Linux

#1 2016-10-31 07:49:26

What does happen when we logout?

#2 2016-10-31 08:59:30

Re: What does happen when we logout?

#3 2016-10-31 11:52:01

Re: What does happen when we logout?

#4 2016-10-31 13:07:56

Re: What does happen when we logout?

#5 2016-10-31 13:44:58

Re: What does happen when we logout?

#6 2016-10-31 16:30:25

Re: What does happen when we logout?

#7 2016-10-31 16:39:16

Re: What does happen when we logout?

#8 2016-10-31 17:13:33

Re: What does happen when we logout?

#9 2016-10-31 17:19:47

Re: What does happen when we logout?

#10 2016-10-31 17:26:07

Re: What does happen when we logout?

#11 2016-10-31 17:28:13

Re: What does happen when we logout?

#12 2016-10-31 17:32:31

Re: What does happen when we logout?

#13 2016-10-31 17:35:46

Re: What does happen when we logout?

#14 2016-10-31 17:37:21

Re: What does happen when we logout?

Board footer