Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Using CentOs, I want to run a script as user 'training' as a system service. I use daemontools to monitor the process, which needs a launcher script that is run as root and has no tty standard in.

Below I give my five different attempts which all fail.

  1. :

    exec >> /var/log/training_service.log 2>&1
    setuidgid training training_command

    This last line is not good enough since for training_command, we need environment for trqaining user to be set.

  2. :

    su - training -c 'training_command' 

    This looks like it ( but gives 'standard in must be tty' as su making sure tty is present to potentially accept password. I know I could make this disappear by modifying /etc/sudoers (a la but i am reluctant and unsure of consequences.

  3. :

    sudo -u training -i bash -c 'source $HOME/.bashrc; training_command'

    A variation on the same theme: 'sudo: sorry, you must have a tty to run sudo'

  4. :

    runuser - training -c 'training_command'  

    This one gives runuser: cannot set groups: Connection refused. I found no sense or resolution to this error.

  5. :

    ssh -p100 training@localhost 'source $HOME/.bashrc; training_command'

    This one is more of a joke to show desparation. Even this one fails with Host key verification failed. (the host key IS in known_hosts, etc).

Note: all of 2,3,4 work as they should if I run the wrapper script from a root shell. problems only occur if the system service monitor (daemontools) launches it (no tty terminal I guess).

I am stuck. Is this something so hard to achieve?

I appreciate all insight and guidance to best practice.

(this has also been posted on superuser:

share|improve this question

You will need to disable the requiretty setting in /etc/sudoers for root. Add the following line via visudo:

Defaults:root !requiretty

You will also need the following line in /etc/sudoers so root can do everything (this should be enabled by default, but check to be sure):

root ALL=(ALL) ALL

Then you can do the following:

sudo -u training /path/to/training_command
share|improve this answer

This seems to be essentially a special case of this question; we can use script -c to fake a tty. The only problem is that I can't get that trick to work directly with su for some reason, and sudo is a bit ugly if you really have to source ~/.bashrc before training_command. Try:

echo password | script -c "sudo su - training -c training_command" 
share|improve this answer
I use script -c "su username" with success with a user that does not need a password to su to another user – Jonathan Drapeau Feb 17 at 15:55

Choose the first one and set the environment variables you need.

If you already use daemontools then you do not create or mess with the log files manually. Daemontools does that job for you.

This is the script for the applicatoin run script

exec 2>&1
exec setuidgid training sh -c 'YOURVARIABLE=yourvalue exec training_command'

Then you create a log directory run script with its own runscript.

Refer to this entry for setting up a log:

share|improve this answer
Thanks Tamas. But. Setuidgid only sets the owner of the process not the environment. I really do need to be training user with its environment to run the command. your solution of putting 'YOURVARIABLE=yourvalue' does not do justice to this. I need to replicate exactly what a login shell sets and do not want to rely on knowing anything about the command beyond that. I can't believe there is no solution to this simple problem and how come noone ever ran into it. I think I am missing something... – Viktor Trón Jun 12 '12 at 18:48
@ViktorTrón: Log in as training. Execute the command set >training.set Log out. edit cstamas' script above to insert the line . /home/training/training.set right before the last line. It should set every environment variable that was set by the login process to the same value it had when you logged in manually. You may need to edit that file and remove one or two variables that might mislead your program, but you probably don't even need to do that. – Monty Harder Jul 15 '13 at 14:06
You want to also unset variables that are not part of the training environment. I'd use "su training /bin/sh -c ". <set up environment>; runcommand". That works for me for setting up system services. – mpez0 Aug 12 '13 at 20:21

Plagiarising my answer here: Starting a script as another user

You could use start-stop-daemon something like this:

/sbin/start-stop-daemon --background --start --exec /path/to/ --user training --pidfile=/path/to/ --make-pidfile

where is something like this:

exec >> /var/log/training_service.log 2>&1
source /home/training/.bashrc
share|improve this answer

Under SSH, you can run command in normal user:

$ ssh normal_user@ bash /path/to/

if one of's command need root privilege, for example, netstat, wrap it within su command like this (replace original raw netstat -tunple):

su -c "netstat -tunpl" root

and run like this:

$ ssh -t normal_user@ bash /path/to/

This will prompt tow password, the first is for normal_user, and the second is for root.

share|improve this answer

Run your command with SSH.

  1. make ssh key configuration to login without password for other user. Here is a tutorial for this purpose:

  2. Run the command with ssh: ssh -l training -i key_file "training_command"

share|improve this answer

Try this:

sudo -u training training_command > /var/log/training_service.log 2>&1

If this fails, please post the output of /var/log/training_service.log.

share|improve this answer
thanks Alex. Alas, sudo does not set the environment only if used with -i option. plus it still complains about missing tty if invoked by supervise. see my edited question including a variant of this. – Viktor Trón Jun 9 '12 at 11:34
You are right. Then su - training --session-command=training_command >> /var/log/training_service.log 2>&1 should do it. – AlexT Jun 9 '12 at 17:47
Thanks Alex but as said su gives 'standard in must be a tty' if called from script. – Viktor Trón Jun 12 '12 at 18:38
I tried the above on a RHEL 6.2 box (before recommending it) as a cron script, and it worked perfectly. You tried it and it didn't work? – AlexT Jun 13 '12 at 2:49

Your Answer


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.