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

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'

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
  • 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

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.

  • 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:


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

  • Even setting the shebang, root is still printed. – iElectric May 9 '10 at 8:36

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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