You are not logged in.
Hi,
I'm pretty sure I'm just overlooking something obvious, but I simply can't find a solution to the following basic problem. I'm using a simple openbox session started from xdm (also tried lightdm with the same results). In case of xdm, I'm using a .xsession file to start openbox like this:
exec dbus-launch --exit-with-session openbox-sessionIn case of lightdm, it also works without a .xsession or .xinitrc file.
I'm using "~/.config/openbox/autostart" to start some tools upon login. Until now, I have only started programs which exit right away which worked fine. But now I'd like to use autostart to start a (non-X11) program which should continue to run until I log out. For testing this, I used a simple infinite loop script, let's call it "loop.sh". When I start loop.sh in autostart using "loop.sh &", this script continues to run even if I log out of openbox using the openbox menu. In fact, if I log out and log in multiple times, multiple instances will keep running forever. When I start loop.sh simply using "loop.sh", also the parent processes, namely "/bin/sh /usr/lib/openbox/openbox-autostart OPENBOX" and "sh /home/ochi/.config/openbox/autostart" continue to run.
What is the correct way to have all processes spawned during the X session killed upon logout?
For reference, this is the loop script I use:
#!/bin/bash
while true; do
# If you like, you can also play a sound for feedback.
#paplay /usr/share/sounds/freedesktop/stereo/complete.oga &
sleep 1
doneUpdate: Using gdm seems to "fix" the problem, i.e. all programs started by the autostart script seem to get killed correctly. However, gdm pulls a LOT of dependencies I don't want to have. I wonder what gdm does differently...
Last edited by Ochi (2015-04-18 23:38:21)
Offline
Hello,
I thought about this problem, and I was about to try an answer, but I see you found a workaround with gdm.
As this problem interests me, could you please post the openbox autostart script you use.
And, when launching openbox through gdm, could you post the output of this command:
$ ps f -eo pid,user,start,cgroup,args
I want to see what is different with gdm, from using startx.
Thanks.
Offline
Thanks for your reply. I used a slightly different formatting for ps since some columns are so wide; I used "ps f -eo pid:10,user,start,args:150,cgroup".
Here are the outputs for xdm, lightdm, and gdm, each after starting openbox (use the "raw" mode of pastebin for better formatting).
It's interesting to see that, in the gdm case, many processes seem to be children of "gdm-session-worker". The openbox "~/.config/openbox/autostart" script I used is really simple, it can be reduced to
tint2 &
nm-applet &
pulseaudio --start &
/home/ochi/loop.sh # The "persistent" test script that you can also see in the "ps" outputs.By the way, it seems to be worse than I thought: Any process I spawn using "whatever &" on some X terminal during an xdm (an probably lightdm) session keep running even if I log out from openbox.
Offline
Thanks for posting.
Normally everything in the openbox autostart script should be backgrounded, for the script to exit as soon as openbox has started.
In your case, you didn't backgrounded the last test script 'loop.sh', so the autostart script doesn't exit, and the 'openbox-autostart' script which runs it.
I'd prefer you post the 'ps f' output with the 'loop.sh' backgrounded, which is the normal way to use the openbox autostart.
So could you please post again the outputs in this way? Thanks.
But for what I see presently, the 'gdm-session-worker' process seems responsible for the ending of all the processes depending on it, graphical or not.
In the other cases, this is not so: apparently xdm only tells Xorg to end, which in turn terminates only all its graphical client processes, not the other non graphical processes running.
But to continue this subject; I will wait for your answer to my request above. It's better to be in the normal use of autostart exiting.
Have a good day.
Offline
Offline
I use startx to enter graphical environment, and all my session processes are killed when loging out of openbox,
even a non graphical one.
You could try also without a display manager, using startx, to see if your loop.sh script is killed at openbox exit time.
Presently I try to understand cgroups,slices and scopes in systemd, because I think this is linked to the ending of the processes running in the graphical session, when openbox exits.
As I don't use gdm, xdm or lightdm, I cannot test the differences between them.
But I read that gdm uses systemd-logind and its session scopes; this may explain why it cleanly exits openbox.
I don't know if xdm or lightdm are linked with systemd in some way or not.
Also could you be more affirmative about whether your script is really killed with gdm and stays alive with xdm/lightdm; because your 'seems to be killed' words are not convincing enough for me.
Last edited by berbae (2015-04-13 15:27:45)
Offline
Sorry for the vague formulation. Yes, I'm sure that the autostarted loop.sh process is gone when logging out of openbox after logging in through gdm, but it's still there when logging out after using lightdm or xdm. Also, I tried startx and can confirm that the autostarted loop.sh is killed properly after logging out of openbox.
However, I noticed something else. Both in case of gdm and startx (which both kill the loop.sh started from ~/.config/openbox/autostart), instances of loop.sh which I start backgrounded in a terminal during the openbox session are not killed even after logging out.
I have created a "ps f" while the openbox session is running (started from gdm) while the autostarted and the manually started (backgrounded) loop.sh are running: click. After logging out, PID 2316 is gone but PID 2356 continues to run for whatever reason...
Update: By the way, one could argue that this behavior is what one would expect, i.e. programs started by – in this case – openbox are killed, but manually backgrounded tasks continue to run. But first, I don't know if this really is how it's supposed to be, and second, I don't understand why it is this way.
Last edited by Ochi (2015-04-13 17:36:47)
Offline
I continued to study this subject, and here is what I found at this time.
First I precise again that I use openbox launched by startx at login in tty.
When I exit openbox, I return to a -bash prompt, and I then can log out of tty.
After logging in into openbox, I have:
└─user.slice
└─user-1000.slice
├─user@1000.service
│ ├─1421 /usr/lib/systemd/systemd --user
│ └─1422 (sd-pam)
└─session-c1.scope
├─1414 login -- berbae
├─1425 -bash
├─1432 /bin/sh /usr/bin/startx
├─1454 xinit /home/berbae/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -auth /tmp/serverauth.xxxxxxxxxx
├─1455 /usr/lib/xorg-server/Xorg -nolisten tcp :0 vt1 -auth /tmp/serverauth.xxxxxxxxxx
├─1459 /usr/bin/openbox --startup /usr/lib/openbox/openbox-autostart OPENBOX
├─1464 dbus-launch --sh-syntax --exit-with-session
├─1465 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
etc...When I exit openbox, without logging out, I have:
└─user.slice
└─user-1000.slice
├─user@1000.service
│ ├─1421 /usr/lib/systemd/systemd --user
│ └─1422 (sd-pam)
└─session-c1.scope
├─1414 login -- berbae
└─1425 -bashIf I ran something in background from konsole, when in openbox, this is not killed:
└─user.slice
└─user-1000.slice
├─user@1000.service
│ ├─1421 /usr/lib/systemd/systemd --user
│ └─1422 (sd-pam)
└─session-c1.scope
├─1414 login -- berbae
├─1425 -bash
├─1296 /bin/bash /home/berbae/bin/loop.sh
└─1338 sleep 60If I log out, the process is still not killed!
└─user.slice
├─user-1000.slice
│ ├─user@1000.service
│ │ ├─517 /usr/lib/systemd/systemd --user
│ │ └─519 (sd-pam)
│ └─session-c1.scope
│ ├─1296 /bin/bash /home/berbae/bin/loop.sh
│ └─1338 sleep 60As seen the 'user@1000.service' with the 'systemd --user' process is not ended too, even after logging out.
Edit: This is due to the session c1 still active; see next post.
I don't know if this is intentional, maybe it is a feature.
Now I found and propose a way to change this apparently default behavior, if it is not wanted.
First to end the 'systemd --user' process at logout, it is easy; just run:
$ systemctl --user enable exit.target
Edit: This is useless, sorry; see next post
Then to run a process in background, which should end when logging out, just launch it like this:
$ systemd-run --user loop.sh
This will launch the command 'loop.sh' as a service in the 'systemd --user' manager, instead of the 'session-c1.scope';
and it will be ended at logout, because the manager is now ended at logout, with the normal end of the manager.
Edit: see next post
I will continue studying this matter, to see if something else interesting can be found.
Edit: See the 'Edit:' lines above for the modifications, before the explanations in the next post.
Last edited by berbae (2015-04-16 14:38:35)
Offline
After reading again the wiki about systemd/user, I saw:
On the first login of a user, systemd automatically launches a systemd --user instance, responsible to manage user services. This process will survive as long as there is some session for that user, and will be killed as soon as the last session for the user is closed.
After testing, I see that is right, and so I was wrong in my preceding post.
The command 'systemctl --user enable exit.target' is not at all necessary, because this target is automatically started when the systemd user manager is ended when the last session scope of the user is empty.
So the 'systemd --user' process was still there only because there was yet something in the session-c1 scope.
But this is still valid:
To run a process in background, which should end when logging out, just launch it like this:
$ systemd-run --user --unit=loop loop.sh
This will launch the command 'loop.sh' as a service named 'loop.service' in the 'systemd --user' manager, instead of the 'session-c1.scope';
and it will be ended at logout with the normal end of the manager due to the end to the session c1 of the user.
As the wiki warns, the script should not require to be run in the active session of the user.
If that is not the case, I will search another way of doing this...
Sorry for the error.
Last edited by berbae (2015-04-16 15:02:59)
Offline
In fact there is a very simple/stupid way (as in KISS) to solve this, for processes running inside the active session of the user:
changing only one option of the file '/etc/systemd/logind.conf'
from
#KillUserProcesses=no
to
KillUserProcesses=yes
I was surprised that a process launched in background from a terminal in the graphical environment, was not killed even at logout;
but this is the default of systemd-logind, as shown in 'man logind.conf':
KillUserProcesses=
Takes a boolean argument. Configures whether the processes of a user should be killed when the user completely logs out
(i.e. after the user's last session ended). Defaults to "no".
I tested this on my machine, and this is it!
For the change to be applied, I rebooted my machine first (it is simpler like that).
The other way proposed in my preceding post also works, but is more complicated;
it can be used when not wanting to change the option in logind.conf, and for processes not requiring to be run in the active user session.
@Ochi: I hope I didn't afraid you with my posts, and that you could now find an answer to your questions; I also learned myself by studying this subject.
Last edited by berbae (2015-04-17 14:39:05)
Offline
Thank you very much for your extensive and insightful input. I just tried the proposed change in "logind.conf" and it seems to work beautifully, for backgrounded processed from the openbox autostart as well as processes started from terminals. This seems to me like a very elegant solution. I think this issue is solved for me; I just hope there are no negative side effects from this change, but in general killing all processes spawned within the graphical sessions seems right to me (or more generally, killing processes spawned by a user after (s)he logged out completely).
Thank you!
Offline