Why may any user leave background processes running at will?

the_isz · 2010-03-10 17:21:10

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!

JohannesSM64 · 2010-03-10 17:27:17

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.

pseudonomous · 2010-03-10 17:45:27

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.

the_isz · 2010-03-10 18:09:10

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?

fsckd · 2010-03-10 19:01:03

I don't know, but this seems to be the philosophy behind it:

The handles of a craftsman's tools bespeak an absolute simplicity, the
plainest forms affording the greatest range of possibilities for the user's
hand. That which is overdesigned, too highly specific, anticipates outcome;
the anticipation of outcome guarantees, if not failure, the absence of
grace.
-- William Gibson, "All Tomorrow's Parties"

Regarding your original problem, why not:

offlineimap &
wm
pkill offlineimap

fwiw, fish kills background processes it starts directly when it quits. I don't know if it does that when running a script but I do know it does that when in interactive mode.

the_isz · 2010-03-10 19:22:00

fsckd wrote:

I don't know, but this seems to be the philosophy behind it:
The handles of a craftsman's tools bespeak an absolute simplicity, the
plainest forms affording the greatest range of possibilities for the user's
hand. That which is overdesigned, too highly specific, anticipates outcome;
the anticipation of outcome guarantees, if not failure, the absence of
grace.
-- William Gibson, "All Tomorrow's Parties"

Nice quote. Now if only that was a 'linux core designer' speaking

fsckd wrote:

Regarding your original problem, why not:
offlineimap &
wm
pkill offlineimap
fwiw, fish kills background processes it starts directly when it quits. I don't know if it does that when running a script but I do know it does that when in interactive mode.

I got that idea already when talking to the other guys on #archlinux, but it
doesn't work for me. The lines I put after my wm execution are never reached.
I'll post my .xinitrc, maybe you can see the problem:

#!/bin/sh
# map caps lock to the ESC key (for vi)
xmodmap -e 'clear Lock' -e 'keycode 0x42 = Escape'

/usr/bin/pgrep -u $USER -x offlineimap || ( offlineimap >> /dev/null 2>&1 ) &
/usr/bin/numlockx on

# This helps Qt apps finding the gtk theme files.
# Might be a bug, though. See http://bugreports.qt.nokia.com/browse/QTBUG-5545
export GTK2_RC_FILES=~/.gtkrc-2.0

# exec ck-launch-session openbox-session
# exec ck-launch-session wmii
exec ck-launch-session awesome

# I don't know why, but these statements are never reached...
echo 1 >> ~/testxyz

# offlineimap is not an X application, so it won't get killed automatically when
# this script ends. Therefore...
kill -15 $(head -n1 ~/.offlineimap/pid)

t

Daenyth · 2010-03-10 19:43:09

Running "help exec" should answer your questions

the_isz · 2010-03-10 20:26:56

Daenyth wrote:

Running "help exec" should answer your questions

If I understand it right, "help exec" only answers the question why the
statements after "exec" aren't executed.

Edit:

Removing the "exec" before the wm call will have the commands after it run
properly. Why haven't I tried that before? Why is it even standard to do so? Is
the "exec" important for anything?

Well, at least now I have a proper (even wm-agnostic!) way of killing that
program, even though that was not really the intention of the thread

Thanks, guys!

Last edited by the_isz (2010-03-10 20:50:21)

brisbin33 · 2010-03-10 20:31:08

simply put, i believe linux is a "do what i tell it" system and i appreciate that. if i say "send this process to background". it will go, to background, and run, forever, disconnected from the foreground in any way. this includes my logging in and out. any sort of "danger" to the system by this is totally handled by any user limits on file access, processing power/time, etc.

all that said, i have the following in a three minute cron job:

#!/bin/bash

logger() { echo "$(date +'[ %d %b %Y %H:%M ]') :: $*" | tee -a "$log"; }

kill_it() {
  local pid="$1"

  logger "killing $pid..."
  kill -9 $pid || exit 1
}

be_patient() {
  logger "will try again later."
  exit 1
}

check_running() {
  local pid=$(pgrep "${sync%% *}")

  if [ -n "$pid" ]; then
    logger "running offlineimap found."

    #be_patient
    kill_it "$pid"
  fi
}

# where to log
log="$HOME/.logs/mailrun.log"

# sync command
sync='offlineimap -o -u Noninteractive.Quiet'

# main
check_running
$sync &>/dev/null &

leaving offlinemap on all the time has never worked for me.

fsckd · 2010-03-10 22:18:44

the_isz wrote:

Removing the "exec" before the wm call will have the commands after it run
properly. Why haven't I tried that before? Why is it even standard to do so? Is
the "exec" important for anything?

Yes, it has a variety of uses. In the context of your script it's akin to wm & exit.

the_isz wrote:

Thanks, guys!

Np, I guess.

Anikom15 · 2010-03-10 23:24:18

Why is every user allowed to leave background processes on the machine
just as he pleases, even if he logs out?

Well, you see, let's say look at this from a business perspective, let's say I don't have root access, so I can't control deamons, but I still need to run some kind of program overnight or something. I run my task in the background and then logout. Quite simple.

pauldonnelly · 2010-03-11 07:03:58

It would be pretty annoying otherwise. I don't want my screen session dying when I log out, do I? The same goes for any number of programs.

the_isz · 2010-03-11 07:40:45

Ok, I think I start understanding now... The "being logged in" isn't the central
aspect that the state of a linux machine evolves around... Users such as root,
apache or ftp don't need to be logged in to have processes running, either. Some
of them don't even have a login shell. Why should it be any different with
'ordinary' users?

So on scientific machines, the tasks of a system administrator not only include
keeping the machine running, up-to-date and supporting the required programs,
but also managing the cpu time between user processes.

Which means, if I - as the system administrator of my desktop machine - wanted
to prevent processes of 'ordinary' users from running after they log out, I'd
have to set up a system-wide daemon or cron job which checks for and kills such
jobs.

And me, as a diligent user of my machine, am responsible for killing any jobs I
don't need running after I log out. Simple as that.

Thanks for your explanations, guys, I think I still have enough to learn about
linux. Which is good, because otherwise I might get bored with it. I haven't had
so little to get frustrated about back in the days I used window$

Cdh · 2010-03-11 19:48:38

At the server at my university there are sometimes processes like mathematica that run for weeks at 100% CPU on 4 cores. I don't know what they are doing there but I bet they would not be pleased to have to be logged in for weeks to be able to run it...

pseudonomous · 2010-03-12 04:52:54

pseudonomous wrote:

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?

I'm not expert on this stuff, but I suspect because this either didn't occur to the original unix developers when they 1st wrote the OS and/or was considered to be too complicated to implement at the time. It was then, in turn, either considered too complicated to implement by linux developers, or they didn't/don't care.

It strikes me as plausible that something like SELinux might be usable to prevent this sort of behavior; for security reasons as opposed to convenience reasons. I don't know enough about it.

Arch Linux

#1 2010-03-10 17:21:10

Why may any user leave background processes running at will?

#2 2010-03-10 17:27:17

Re: Why may any user leave background processes running at will?

#3 2010-03-10 17:45:27

Re: Why may any user leave background processes running at will?

#4 2010-03-10 18:09:10

Re: Why may any user leave background processes running at will?

#5 2010-03-10 19:01:03

Re: Why may any user leave background processes running at will?

#6 2010-03-10 19:22:00

Re: Why may any user leave background processes running at will?

#7 2010-03-10 19:43:09

Re: Why may any user leave background processes running at will?

#8 2010-03-10 20:26:56

Re: Why may any user leave background processes running at will?

#9 2010-03-10 20:31:08

Re: Why may any user leave background processes running at will?

#10 2010-03-10 22:18:44

Re: Why may any user leave background processes running at will?

#11 2010-03-10 23:24:18

Re: Why may any user leave background processes running at will?

#12 2010-03-11 07:03:58

Re: Why may any user leave background processes running at will?

#13 2010-03-11 07:40:45

Re: Why may any user leave background processes running at will?

#14 2010-03-11 19:48:38

Re: Why may any user leave background processes running at will?

#15 2010-03-12 04:52:54

Re: Why may any user leave background processes running at will?

Board footer