Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to run a service that uses $HOME and $USER environment variables. I could set them in service itself, but that would only be a temporary solution.

Let's say I have a script test.sh with following content:

echo $USER

And I run it with start-stop-daemon to see my results:

$ start-stop-daemon --start --exec `pwd`/test.sh --user guest --group guest --chuid -guest
root

Seems like it does not update environment, maybe that should be reported as a bug?

I have found a nasty hacky solution, which only works (for unknown reason) on my this simple use case:

$ start-stop-daemon --exec /usr/bin/sudo --start -- -u guest -i 'echo $USER'
guest

I'm sure someone else stumbled upon this, I'm interested in clean solution.

$ start-stop-daemon --version
start-stop-daemon 1.13.11+gentoo
share|improve this question
    
It's clearly changing the UID. If you add mktemp to the script, the file it creates /tmp/tmp.* is owned by guest. Mysterious. And I get "root" as output, too. I tried various combinations of switches -i and -l in the shebang: #!/bin/bash -il and that didn't help. –  Dennis Williamson May 9 '10 at 14:36

2 Answers 2

up vote 4 down vote accepted

This might be the intended behavior. The manual page shows an --env option for start-stop-daemon:

   -e|--env env-name
          Set an environment variable whose name  and  value  is  env-name
          before   starting  executable.   Example:  -e  HOME="/home/user"
          exports an environment variable whose name is  HOME  with  value
          "/home/user".   Note,  only  one  --env  option is suppoted, use
          /usr/bin/env if you need more.

The author used $HOME in the example, which I take to mean that it wouldn't normally set it. I don't see any other options for updating the environment of the process you're starting.

Try running start-stop-daemon like this:

USER=guest HOME=~guest start-stop-daemon --start --exec /path/to/prog ...

Another alternative would be to run the script under sudo:

start-stop-daemon --start --exec /usr/bin/sudo -- -H -u guest /path/to/prog

sudo will automatically set $USER, and the -H option tells it to set $HOME as well. I ran both of these with my own test.sh that prints the value of thse variables, and both updated them as desired. I'm partial to the first because it doens't add another program to the mix, but that's just me.

share|improve this answer
1  
+1 - $HOME and $USER are typically set by login, not by the shell. So you have to use something like this to make it work as the OP wants. The $USER and $HOME variables that the OP is seeing are most likely being inherited from the shell in which he is running start-stop-dameon. –  James May 9 '10 at 17:17
    
Thanks, James. I thought that was the case, but I wasn't sure. –  James Sneeringer May 9 '10 at 23:30
    
yeah, sudo seems to know better about environments. I can not get hudson runing with this method, but I guess that's the way. I'll come back when I get hudson daemon working. Cheers James! –  iElectric May 10 '10 at 18:51
    
The Hudson documentation has a suggestion on running it as a daemon here: wiki.hudson-ci.org/display/HUDSON/… –  James Sneeringer May 11 '10 at 1:09

It's possible that the shell is different for the script than for the environment in which start-stop-daemon is running. Try specifying the shell in your script using a shebang line:

#!/bin/bash

On my system, sh is Dash which doesn't set $USER but will inherit it from a parent's environment.

share|improve this answer
    
Even setting the shebang, root is still printed. –  iElectric May 9 '10 at 8:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.