[Nottingham] TMPDIR weirdness with X logins

[Robert Davies]

On Friday 12 Sep 2003 11:45, Robert Postill wrote:

> Sorry, I don't think I answered your question, the why is that the
> xterms run in subshells so that they never have the same priority as
> your original login shell becasue that could jepordise the system
> resources (see my comment about daemons in the last e-mail).  Certainly

In *nix systems, process priority is dynamically calculated unless it's an RT 
task, your usual way of influencing priority is with nice values.  Process 
priority has nothing to do with login/non-login shell status, whether it's a 
process group leader or not, or anything like that.

> I had a user once who started up numerous shells that automatically sent
> e-mails (due to his human virus status :) which he picked up from
> outlook.  He did this with a book resting on the keyboard (over his
> eterm shortcut F7 key if I remember right) and ended up slowing the
> exchange server to a crawl.  So I can see why you would want a once-only
> type of environment and then a seperate environment for subshells.

This sort of thing is why you sneak ulimit into luser's startup through 
/etc/profile, I've tended to use groups, as easy way to split luser's into 
classes, so they get defined what they need, and I guess you can have  a 
special 'human virus' section, for those non-amenable to LART-ing.

> I have been bitten before and ended up doing the following:
> 1. Stick the stuff I want all the time in .bashrc
> 2. Use source .bashrc in your .bash_profile to pull in the settings from
> c.bashrc.  They will be executued at the same level as those in your
> bash_profile and therefore not lost.

It's fine, only sometimes for remote shells say, it'd be really nice if 
.bashrc was run like .cshrc, precisely because you do need to set something 
up (system specific), possibly to work round breakage, even though it's not 
an interactive shell.


The once only, is to allow sub-processes to inherit characteristics from their 
parents.  It's why fork(2) was such a bl**dy f*rking good idea, solved so 
many problems well, like i/o redirection (inheritance of open file 
descriptors) etc.  That allows the login shell to set up stuff, but each 
process may alter environment to suit their own children.

This breaks if you end up using, every time semantics, as you have no way of 
knowing that the parent did actually know better after all.

The problem is that xterm/konsole etc are not knowing better, just using, I'll 
stomp on this just to be on the safe side and am too lazy to put it right 
semantics...  which then tends to pollute the system with ppl working round 
with the 'every time' stuff.

Rob