switch user/user upstart jobs ? - su -c and expect fork

[Steffen Barszus]

On Tue, 17 May 2011 15:59:54 -0700
Clint Byrum <clint at ubuntu.com> wrote:

> Excerpts from Steffen Barszus's message of Tue May 17 13:01:59 -0700
> 2011:
> > Hi !
> > 
> > I'm working on an upstart job starting an application as a different
> > user. Until now i have used su -c doing that, but started
> > recognizing now that upstart can not follow the pid properly like
> > that. 
> > 
> > It is also recomended way in upstart cookbook. 
> > 
> > From my analysis i understand the following:
> > 
> > Lets assume i use script/end script to start in the end:
> > 
> > ....
> > exec su -c "some daemon " someuser
> > end script 
> > 
> > the exec replaces the shell with the su command which itself starts
> > a shell which start the daemon. Now upstart can get the PID of the
> > su command but not of the shell it starts or even the daemon. The
> > best one can get is that the su shell gets killed and hope and pray
> > that the daemon started in the shell will die from that in time. 
> > 
> > So this doesnt seem to be a perfect solution. Any comments ? 
> > 
> > Will there be a user keyword anytime soon ? (it might do the same
> > as su, but if it can track the PID properly it might be worth it ?)
> 
> That would be cool for the case where you have something simple that
> fully daemonizes. For many cases, just running in the foreground
> seems ok.

actually the problem in my case is that the ressources are not free
yet, sometimes letting the "daemon" fail. 

Lets look at an example:
test.conf:

script
SLEEP=5000
exec su -c "sleep $SLEEP" steffen
end script

# start test
test start/running, process 8426

steffen   8426     1  0 07:17 ?        00:00:00 su -c sleep 5000 steffen
steffen   8433  8426  0 07:17 ?        00:00:00  \_ sleep 5000



In order to properly handle it, upstart should "know" the PID 8433, but
just uses 8426. 

> If your daemon runs in the foreground the su method works without
> problems.

No. The sleep will die from the su being stopped (eventually), but thats
not safe. 

I continued on this example in the meantime. I guess start-stop-daemon
can be (ab)used for this:
test.conf:
script 
SLEEP=5000
exec start-stop-daemon --start --exec /bin/sleep --user steffen --chuid steffen -- $SLEEP
end script 

# start test
test start/running, process 8446

ps -ef:
steffen   8446     1  0 07:18 ?        00:00:00 /bin/sleep 5000

on the long run i would wish for a solution like:

user steffen
 
script
SLEEP=5000
exec sleep $SLEEP
end script 

Just for the sake of simplicity and being more upstart-like. For the
time being, maybe upstart cookbook should be amended accordingly.