Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: elogind is killing user processes by default (Read 2305 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

elogind is killing user processes by default

Hello,

I'd like to suggest changing default configuration of elogind package. Currently shipped config has KillUserProcesses value set to yes. That causes logind to kill background stuff when user logs out or even closes SSH connection, rendering tools like screen unusable.

I strongly believe this behaviour is
1. Annoying as hell
2. Quite surprising even for someone who happens to remember systemd tends to do this.
3. Hard to disable and debug, as there is no indication what causes screen sessions to disappear.

I can even prepare pull request, assuming such one-liner change is even considered PR-worthy.

---
On related note, how impossible is to run Artix without that elogind mess in first place?

Re: elogind is killing user processes by default

Reply #1 –
I concur. Checking Arch, they build systemd with this switch to disable KillUserProcesses
Code: [Select]
-Ddefault-kill-user-processes=false
I'm sure elogind has that switch too. It would be a saner default to disable this behavior.

Re: elogind is killing user processes by default

Reply #2 –
Thanks for the info. (and ouch)

Re: elogind is killing user processes by default

Reply #3 –
elogind-234.4-2 compiled with '-Ddefault-kill-user-processes=false'  is in [system] since yesterday.

Re: elogind is killing user processes by default

Reply #4 –
Wasn't this one of the primary complaints people had from systemd that it killed all unfinished user processes?
It seems as reverse engineering to get other init systems to inherit this "feature".

And that is why we are here.  I wonder if Debian has gone back to wheezy to change the defaults to be systemd-like.

Re: elogind is killing user processes by default

Reply #5 –
For a regular desktop user, would this option be a good or a bad thing? What are the pros and cons of it?

Re: elogind is killing user processes by default

Reply #7 –
Quote from: physkets – on
For a regular desktop user, would this option be a good or a bad thing? What are the pros and cons of it?

Sometimes you need to rub processes that take some time, first you may want to log into another account to do different work and sometimes you may forget something is running and log-off.  On a network of machines you may want to log in remotely and run a process leaving your own machine's processing power for other tasks and log off and let it run till it finishes.  Compiling large pieces of software may take time.  For example building a kernel from source in my machine takes 6-10hrs.  It would be sad to have it terminate and start from 0 because I forgot it was running.

Re: elogind is killing user processes by default

Reply #8 –
for just about anything the user would want to run in the background in the first place, having the process get killed on logout makes very little sense.

tying background processes to logins at all makes very little sense.

ultimately you login to use foreground processes, and this default (while no longer a problem for artix) reeks of "lets take everything gnu/linux does and make it more like some other operating system we like." fine, for one distro-- absolutely terrible, for an effort to take over all distros.

that said, i dont think this is a mac default-- except for the sort of windows powerusers that spend all day one arbitrary tweaks like this: http://www.interrupt19.com/2009/05/21/speed-up-your-mac-eliminate-background-processes/ and i cant find evidence that its the windows default either.

per-process, you can apparently start processes that are killed on logout using huponexit: https://askubuntu.com/questions/685281/why-my-process-is-still-running-after-i-log-out i almost think someone in freedesktopland read something like that and thought: "too complicated! lets just make it default" (and break everything, so what?) every day, systemd authors try to screw up 6 reliable things before breakfast. has anyone considered the possibility that they are luddites in disguise? throwing wrenches into everything and then claiming everyone else was too stuck in their ways not to do it sooner...