LOGNAME environment variable set incorrectly for subprocess started through 'cset shield' command

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create a 'system' cgroup per the 'shield' tutorial
2. launch a shell in the system cgroup: sudo cset -l shield.logfile shield 
--user andrew -- bash
3. echo $LOGNAME

What is the expected output? What do you see instead?
I would expect $LOGNAME to equal 'andrew'. Instead $LOGNAME is 'root'. Note 
that this happens for any subprocess, not just a shell. If I exec emacs in the 
system cgroup and ask emacs to getenv("LOGNAME") I get back 'root', not 
'andrew'.

However, using 'su' works:

sudo cset -l shield.logfile shield su andrew
$ echo $LOGNAME
andrew

so I guess the workaround is just to skip using the --user flag, and use 'su 
user -c <command>' as the command to shield instead.

What version of the product are you using? On what operating system?
cpuset 1.5.5 (built from source)
Ubuntu 11.04 x86_64

Please provide any additional information below

Also, $USER is set wrong, but USER is non-standard. It may be that on my system 
$USER is derived from $LOGNAME. 

I've attached a logfile from the broken run. Changing the command to ask bash 
for a login shell makes no difference.

$LOGNAME is a fairly important environment variable that many programs expect 
to exist 
http://www.google.com/codesearch?hl=en&lr=&q=getenv.*LOGNAME.*&sbtn=Search so 
having it wrong is a problem.

Also, thanks for writing cpuset: it going to save me a great deal of time 
getting cgroups up and useable. I noticed though that there haven't been any 
commits in nearly a year. Is cpuset still being actively maintained, or has 
development shifted elsewhere? Or is it just basically finished?

Original issue reported on code.google.com by andrew.c.morrow@gmail.com on 6 May 2011 at 8:55

Attachments:

• shield.logfile

[GoogleCodeExporter]

Hi Andrew, thanks for filing the bug, I'll take a look.

The cset utility is basically as finished as it's (probably) going to be; 
however, I do actively maintain it.  I had thought of adding more cgroups 
functionality to cset, but think the different functionality that cgroups 
offers warrants a different tool, rather than try to graft cgroups onto cset.

Original comment by tsariou...@gmail.com on 6 May 2011 at 9:07

[GoogleCodeExporter]

Change to accepted.

Original comment by tsariou...@gmail.com on 6 May 2011 at 9:10

• Changed state: Accepted

[GoogleCodeExporter]

Any update for this? I'd like to get cset deployed, but the su workaround is 
awkward for various reasons, and I'd much rather use the --user flag if it can 
be made to work. Unfortunately, the processes I need to launch depend on 
LOGNAME being properly set.

Thanks

Original comment by andrew.c.morrow@gmail.com on 9 Jun 2011 at 2:01

[GoogleCodeExporter]

Hi: finally got around to this.  I've release a new 1.5.6 version which fixes 
this problem (along with setting USER and USERNAME appropriately).  Since you 
build from source you can either get it from downloads or mercurial (tag is 
rel_1.5.6).  The build service will have updated packages shortly (however, 
note that I don't build for ubuntu/debian in the build service (yet...)).  
Thanks.

Original comment by tsariou...@gmail.com on 9 Jun 2011 at 7:38

• Changed state: Fixed

[GoogleCodeExporter]

Verified. Thank you very much for the fix.

Andrew

Original comment by andrew.c.morrow@gmail.com on 9 Jun 2011 at 7:46

[GoogleCodeExporter]

Thanks for checking it.

Original comment by tsariou...@gmail.com on 9 Jun 2011 at 8:04

• Changed state: Verified