Skip to main content ↑ ↓
Topic: Kill user services on true logout (Read 1850 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Kill user services on true logout

I've scoured the web/wikis for a solution to this issue, but haven't found one.

I've created user-specific services for my account in /home/<my-user>/service , but when I end my X session or logout of the tty, those user services stay running. One approach would be to have a script that takes the services down when I quit my window manager, but I'd still like to be able to access those services from the tty ideally.  What I'm essentially wanting is:

User services down by default on startup (maybe through use of a default "down" file in the service directory)
User logs in -> user-services launched (scripted through .bashrc or ~/.profile)
User logs-out (actual, not just ending an X session or closing a terminal) -> user-services terminated (scripted through ???)

Ideas?

Re: Kill user services on true logout

Reply #1 –
You could edit /etc/elogind/logind.conf, uncomment #KillUserProcesses=no, and change that to yes. That would kill all user processes though and not just what services you have setup.

Re: Kill user services on true logout

Reply #2 –
Quote from: Dudemanguy – on
You could edit /etc/elogind/logind.conf, uncomment #KillUserProcesses=no, and change that to yes. That would kill all user processes though and not just what services you have setup.

I tried this out, and it doesn't work for the user-specific runsvdir processes.

Interestingly, the wiki page on elogind says: "Every user process is killed at logout, including screen/tmux sessions!: This "feature" was introduced and made default in systemd 230, without much warning, changing an age-old UNIX behaviour. It's disabled in Artix at compile time, but you can control it in /etc/elogind/logind.conf by changing the value of KillUserProcesses to your liking. "

I'm not a systemd fan, but not knowing a lot of UNIX history, this raises on interesting question: If the age-old UNIX behaviour was to keep user processes running, wouldn't scarce system resources eventually become used up on a multi-user machine?

Re: Kill user services on true logout

Reply #3 –
Quote from: introspect – on
I'm not a systemd fan, but not knowing a lot of UNIX history, this raises on interesting question: If the age-old UNIX behaviour was to keep user processes running, wouldn't scarce system resources eventually become used up on a multi-user machine?
By definition, the purpose of multi-user machines is to be kept as busy as possible or they'd be wasting resources. Being (a little) older, I fondly remember my university years, using green terminals to such multi-user machines running some UNIX flavour, on the early days of the Internet. Back then Linux was not even born yet, but those machines performed remarkably well with hundreds of students logged in, running pine, mutt, lynx, gopher, ftp and - of course - playing some MUD like Shadowdale. Most of them used a terminal multiplexer called screen(1) to keep their sessions alive and, thanks to the shared libraries model and the ample 20MB swap space, everybody got their share of that pioneer feeling.
It never ceases to amaze me how badly Linux behaves once it hits the swap space, having used Mosaic on HP9000/200s and Sun SPARCstations with as little as 4 MBs of RAM and barely a hiccup...

On you issue though, perhaps runit is intervening?

Re: Kill user services on true logout

Reply #4 –
Quote from: nous – on
By definition, the purpose of multi-user machines is to be kept as busy as possible or they'd be wasting resources. Being (a little) older, I fondly remember my university years, using green terminals to such multi-user machines running some UNIX flavour, on the early days of the Internet. Back then Linux was not even born yet, but those machines performed remarkably well with hundreds of students logged in, running pine, mutt, lynx, gopher, ftp and - of course - playing some MUD like Shadowdale. Most of them used a terminal multiplexer called screen(1) to keep their sessions alive and, thanks to the shared libraries model and the ample 20MB swap space, everybody got their share of that pioneer feeling.
It never ceases to amaze me how badly Linux behaves once it hits the swap space, having used Mosaic on HP9000/200s and Sun SPARCstations with as little as 4 MBs of RAM and barely a hiccup...

This definitely gives me some perspective; thanks. If I'm hearing you correctly, with the UNIX philosophy, the purpose of keeping user processes alive would be that users would not have to reload every program to its previous state every time they logged-in, but resume where they left off.

Quote from: nous – on
On your issue though, perhaps runit is intervening?

I'm thinking it is, because every non-runit user process gets killed. I was thinking of asking the elogind maintainers how the "KillUserProcesses" option sends signals to the processes, but I'm sure they are very busy. I tried putting a "down" file in those services directories so that if elogind killed them they would not restart, but somehow that doesn't work.

 

Re: Kill user services on true logout

Reply #5 –
According to http://smarden.org/runit/runsvdir.8.html
Code: [Select]
If runsvdir receives a TERM signal, it exits with 0 immediately.
If runsvdir receives a HUP signal, it sends a TERM signal to each runsv(8) process it is monitoring and then exits with 111.
so if you want to end the runit processes the runsvdir needs to be started so that it will receive the HUP signal when the logout happens. The nohup process runner was designed to keep user processes alive across logout so HUP is the standard signal that should be sent when logout happens. If this is all well understood please accept my apologies for the noise.

Re: Kill user services on true logout

Reply #6 –
No matter; my attempts to get runsvdir to start a service from inside say openbox startup fail to obey logout. It seems runsvdir does the right thing regarding kill -HUP, but if started as a background process from openbox autostart it doesn't receive a HUP when I logout with openbox --exit.

Re: Kill user services on true logout

Reply #7 –
Quote from: replabrobin – on
No matter; my attempts to get runsvdir to start a service from inside say openbox startup fail to obey logout. It seems runsvdir does the right thing regarding kill -HUP, but if started as a background process from openbox autostart it doesn't receive a HUP when I logout with openbox --exit.

I've found the same thing. If I issue "sv hup runsvdir-user" and also keep a "down" file in the directories of the individual services, they won't restart, but I if logout on the TTY the services do not go down. To me, it would seem that elogind is not sending a TERM or a HUP upon logout because when I check "sv status runsvdir-user" immediately after logout, the timer would suggest that that process was never ended, or else runit ignores those signals from elogind.

Quote from: replabrobin – on
According to http://smarden.org/runit/runsvdir.8.html
Code: [Select]
If runsvdir receives a TERM signal, it exits with 0 immediately.
If runsvdir receives a HUP signal, it sends a TERM signal to each runsv(8) process it is monitoring and then exits with 111.
so if you want to end the runit processes the runsvdir needs to be started so that it will receive the HUP signal when the logout happens. The nohup process runner was designed to keep user processes alive across logout so HUP is the standard signal that should be sent when logout happens. If this is all well understood please accept my apologies for the noise.

Those behaviours, for me, work exactly as you quoted them when I send the signal with sv. Again, not sure what elogind is doing.

Re: Kill user services on true logout

Reply #8 –
I managed to make my user runsvdir behave properly by making openbox run as a proper session. I already was using dbus-launch --exit-with-session openbox in my .xinitrc, but openbox --exit did not cause HUP to be sent to the runsvdir started in autostart.sh. If I use
Code: [Select]
setsid dbus-launch --exit-with-session openbox
then the runsvdir does receive a HUP signal and dies properly. I see no runsvdir remaining until I log in again.  I suppose my simplistic attempt at using slim with a
Code: [Select]
login_cmd = bash --login ~/.xinitrc %session
is too simple. There is a slim sessionstart_cmd, but I have never used it.

Re: Kill user services on true logout

Reply #9 –
I added the following to my slim.conf

Code: [Select]
sessionstart_cmd /bin/sessreg -a -l $DISPLAY %user
sessionstop_cmd /bin/sessreg -d -l $DISPLAY %user
and using sessreg from pkg xorg-sessreg I now get the wtmp log updated properly.

Re: Kill user services on true logout

Reply #10 –
Quote from: replabrobin – on
I managed to make my user runsvdir behave properly by making openbox run as a proper session. I already was using dbus-launch --exit-with-session openbox in my .xinitrc, but openbox --exit did not cause HUP to be sent to the runsvdir started in autostart.sh. If I use
Code: [Select]
setsid dbus-launch --exit-with-session openbox
then the runsvdir does receive a HUP signal and dies properly. I see no runsvdir remaining until I log in again.  I suppose my simplistic attempt at using slim with a
Code: [Select]
login_cmd = bash --login ~/.xinitrc %session
is too simple. There is a slim sessionstart_cmd, but I have never used it.

I still want my processes to be running when I'm logged into the TTY but not the window manager. I did a bit more testing, and if I put a ./finish script with 'sv down ~/service/<name-of-service>' in my runsvdir and manually send it a TERM, KILL, or HUP, it does not restart. That means that elogind is not getting the signal to these services.