6

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
1
  • 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. May 9, 2010 at 14:36

2 Answers 2

6

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.

4
  • 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, 2010 at 17:17
  • Thanks, James. I thought that was the case, but I wasn't sure. May 9, 2010 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, 2010 at 18:51
  • The Hudson documentation has a suggestion on running it as a daemon here: wiki.hudson-ci.org/display/HUDSON/… May 11, 2010 at 1:09
0

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.

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .