Detach a daemon using sudo?

Question

I noticed that sudo continues to run after executing any of the following lines. Is there any way to detach the daemon completely so sudo does not continue running?

sudo -u user daemon &
sudo -u user -b daemon

Solution 1

You can background it in one shot like this:

sudo -u user sh -c "daemon & disown %1"

Looking with ps will show that daemon is running as user. There will be no sudo associated with it.

Solution 2

sudo does not remain running after it executes the program you ask it to; in fact, it uses the exec() system call to replace itself with the program you specify so that program has the same PID that sudo did. You can verify this by running the following commands:

sudo -u user -b sleep 60
ps aux | grep sudo
ps aux | grep sleep

You will see that sleep is still running, but sudo is not.

If you ask the shell to background sudo with the & operator, then sudo will block and wait there in the background indefinitely if it must prompt you for your password. If it does not prompt you for your password, then the program you specify is run and sudo is no longer running. Because of the potential to block, the -b switch to sudo is the preferred method, so it can prompt you for your password if needed, and then it will fork into the background to run the requested program.

Solution 3

Sorry, this isn't really an answer, more of an additional comment.

Despite psusi's response, it appears that some versions of sudo will always fork() (and wait for the child process if -b is not specified).

The problem with using -b is that then $! does not contain the PID of the daemon; the problem with using daemonize is that it's not shipped with all distributions; the problem with using sudo sh -c 'run_my_daemon arg1 arg2 arg3... & save_pid $!' is that passing args in to run_my_daemon is quite contorted; getting away from such contortions is a major reason to use sudo in the first place.

Worrying about waiting for a password only applies if you're not root to begin with; in particular consider the case of using sudo -u $run_as_uid prog "${args[@]}" inside a script which is already running as root.

Solution 4

If you have the daemonize program, you can use sudo daemonize PATH_TO_DAEMON.

View more solutions

Comments

[Nathan Hangen]

Do you mean you want to kill it?

[museofwater]

@quanta Why is sudo still running when it has aleady executed the program ? Shouldn't sudo terminate by itself without needing to kill it ?

[Nathan Hangen]

Because you put a & or -b (background) option when running it.

[museofwater]

@quanta If i omit the "&" or "-b", then it will not detach from the terminal.

[Sirex]

sudo is the program you have called, and sudo is calling "program". you have put sudo into the background, so sudo is still running. I think you're believing "program" is using sudo, when in reality its the other way around ?

[museofwater]

@Sirex Ok, so how do I run a program using sudo and let sudo exit gracefully after having executed the program ?

[Sirex]

thats the default, if i understand you right. sudo will exit when "program" exits. i.e: sudo ls & , sudo will end when the ls ends - usually almost instantly.

[museofwater]

@Sirex What if "program" is a daemon and will therefore not exit. I will then have sudo in the background forever ?

[Sirex]

yup. but you should just launch those as root (usually) anyhow, with su. personally i tend to do sudo bash -l to go root and just launch them from there. Also, why is sudo being in the background an issue anyway ?

[museofwater]

@Sirex I just feel it is unnecessary for sudo to run indefinitely. Thanks.

[codeshot]

I'm not sure this is correct. there is a pam session created for the program and that's maintained by sudo and closed when sudo exits (sudo.ws/pipermail/sudo-users/2010-August/004461.html) You need to daemonise your program (linux.die.net/man/1/daemonize) and you need to keep its pam session going for the whole lifetime (maybe avoid sudo except for running administrative commands until this is fixed and sudo starts to "exec" again - thus not adding an incompatible feature onto the side of the unix process model)

[codeshot]

sudo.ws/pipermail/sudo-users/2010-August/004461.html says some pam modules don't work correctly if sudo doesn't stay running when those pam modules are used. I think this is a pam design issue.