Possibility to tell explicitly what PID to track

Registered by Leonty

Upstart's feature to track PIDs requires very presice tuning since modern applications are no more single process applications and often do not follow the "daemonizing" pattern which implies double forking. Given options (first PID of exec/script, expect fork, expect daemon) do not cover all use-cases and the only fallback for a system administer is using usual rc-scripts with manual PID tracking (which makes no use of Upstart and elevates the complexity of the system configuration). While there's a way to know the desired PID, there's no way to inform Upstart to track exactly this PID.

The application bootstrap process does more than two forks and returns after the application had started.
In this case Upstart is wrongly tracking the bootstrap's PID (first or second, depending on "expect" stanza, but still incorrect PID). There is a way to retrieve the application PID by calling the application bootstrap command with a special parameter or by ps|grep-ing the PID. But there's no way to pass the found PID to Upstart.
(This is a real use-case for the Glassfish JavaEE application server. The utility programm "asadmin" is used to start the server.)

If the application startup process is not simple, it's essential to use pre-start/script/post-post stanzas. The application can be started in <pre-start> or <script> followed by pgrep-ing its PID. The last action to do is to inform Upstart about that PID. It can be done by using extended syntax of "exec" or using a new keyword.
asadmin start-domain
PID=`ps U $GFUSER | grep $NAME | awk '{ print $1}'`
# extended syntax: the exclamation sign tells Upstart to treat the COMMAND as PID to track
exec ! $PID


# new stanza: the argument is the PID to track
execpid $PID

This makes .conf files very flexible and is easy to implement, since it's more about syntax than about Upstart startup algorithms.

Blueprint information

Not started
Needs approval
Series goal:
Proposed for 1.x
Milestone target:

Related branches



No review? No comments? Please

This functionality is really needed. There are many service daemons that would be great to control using upstart but cannot work at all with the limited fork/daemon stanzas. This seems trivial to add, will this be available soon?


Another option on implementation that might be simpler:

define a new "special" variable CONTROLPID, can be set in a "script/end script" or "pre-start" block, but ignored unless the "expect controlpid" stanza is present.

new stanza in addition to expect fork, expect daemon: expect controlpid

In this way the script/end script block or prestart whatever is necessary to come up with "the" process to control, and then save the value to the variable CONTROLPID. I think this pretty much covers anything including the common case of daemons that write their main pid in a pidfile.



Work Items

This blueprint contains Public information 
Everyone can see this information.