I found the answer using some slightly different search terms: expect stop
Unfortunately, this means Upstart detects the first invocation of sed as the first PID
Additionally the answer for a workaround is nearby, pre-start
, which is exactly designed for such purpose. Didn't thought about that, even though I've read it before in the docs...
I've found an interesting proposal as well: Possibility to tell explicitly what PID to track
Because of some problems with one of my services I had another look in how it behaves with Upstart and found the following: My "script" stanza is still calling binaries like "dirname", "readlink" and "ls", to not need to hard code some working dir, build some Java classpath and such. The important part is that those are no shell built-ins and therefore should be tracked by Upstart, because "readlink" is the first binary executed in "start". But this is not the case, those PIDs seem to be ignored and Upstart instead tracks the PID of the "exec java ..." command I really want to see tracked. I verified that by calling "service ... status" and comparing the output to "ps axf | grep ..." and both PIDs match. I can properly restart the service and the former found PID is removed and start the service and ps and service ... status report the same PID again.
Two possible explanations: Because "dirname" and Co. are used as command substitution, Upstart recognizes the created subshells by it's own created shell for the "script" stanza and ignores those PIDs by purpose. Else "exec" may return a PID which overrides any former recognized PID. I doubt the latter and think subshells are simply ignored, which is a very nice feature then.