Why may any user leave background processes running at will?

Question

Hi all,
yesterday, I encountered a rather strange problem with linux in common, at least
I think so.
In my .xinitrc, I'm starting offlineimap - a console-based mail synchronization
tool - in the background. Being naive, I expected it to be killed along with the
gui applications started in that file. Yet, that assumption proved wrong and I
started asking for help on how to kill that process on #archlinux.
The guys there (again, thanks for your help and patience!) all came up with
plenty of ideas on how to avoid starting more than once instance of the program,
but that wasn't really what I was looking for. The only usable option came from
anrxc, who suggested killing the program from awesome's logout hooks.
Not fully satisfied with the solutions, I started thinking and came up with the
following question:
Why is every user allowed to leave background processes on the machine
just as he pleases, even if he logs out?
I even tried this over ssh, where the launched commands have some sort of
"parent" process, but even in this circumstance it was possbible to leave
background processes behind after logging out.
I mean, on my desktop system, this is not a big issue... I shut it down once
every day at the least and there are no users on it besides my girlfriend and
me. But this seems like a fundamental problem to me. Why is this allowed at all?
Does it make sense to do it that way? What are the consequences?
Let's discuss!

Answer 1

JohannesSM64 wrote:Really, you need to find a better way to manage offlineimap than starting it in xinitrc. Automatically killing any background processes on any logout will not make linux better.
Hmm... to me, .xinitrc is the place to start apps which should live just as long
as the graphical user login lasts. On #archlinux, several other places were
discussed, but none of them were "the thing":
.bashrc
Doesn't work, because a) the process would only get started when I open a shell,
not when I log in and b) because finding a place to stop the process would be
even harder.
.bash-profile
Only gets executed for a login shell, which I wouldn't account for a graphical
login at all.
wm startup script (in this case awesome's rc.lua)
Possbile, but not much better. Would fork the process all the same, merely
moving the problem. If X got killed, not even awesome's logout hooks would
apply.
Also, this approach isn't wm-agnostic, so trying out / switching to another wm
would have the problem occur all over again.
So what do you suggest? Do you have a good idea?
pseudonomous wrote:
As to the question of "why" things act this way:
I believe this is linux display it's heritage as a mulit-user operating system that people used terminals to log into to run program on.  A big place where unix used to be (and is, to some degree, still used) was in universities where a professor or graduate student might have logged onto the system to run some program to process some large set of data.  You wouldn't want to sit around and wait for this program to finish; you'd want to run it in the background, leave, and come back and look at the results a week later, when the program finished running.  One of my friends doing applied math research still does this sort of thing.  I'd imagine it's relatively common.
Process management was largely handled be systems administrators, and commonly you were being billed for CPU time, so it was in your interest not to leave programs that you didn't want to run running when you logged out.
Hmmm... that seems like a rational explanation. But in the case that is the
reason for linux' behavior: Why isn't there some kind of a mode setting? Like
one which allows any user to keep processes alive and another one that doesn't?