Comment 10 for bug 264711

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 264711] Re: init: expect fork/daemon do not work as expected

On Thu, 2009-06-18 at 20:20 +0000, Jeff Oliver wrote:

> I don't know. Once i had figured out that the process had to be a
> session leader in order to get the fork tracking to work, I ended up
> changing my job files to ensure that it did what it was supposed to. My
> environment is very controlled, so I don't have to deal with anyone
> messing with writing job files that don't ultimately work.
>
I suspect I simply never tested it - one of the problems with the test
suite is that, because it's not pid 1, it actually has to run all the
tests as "session leader"!

In theory, pid 1 can ptrace() any process it feels like, but it might be
failing to follow the double-fork that init does itself to fork
non-session-leaders.

The rationale for why init double-forks its children where sysvinit
doesn't is to make processes more comfortable about staying in the
foreground. Without the double-fork, the process would be a session
leader, so if it opened any tty it would control it.

This is a side-effect of bad daemon support.

Now, both problems can be killed with a nice stone - dropping the
ptrace() madness and instead switching to use the netlink proc connector
as planned.

This means Upstart can freely supervise any process on the system
without tracing, and it also means the test suite can do so as well
(albeit with a setuid() helper right now).

Plus this code branch would mean that there would be no hassle with any
process becoming a daemon, Upstart would follow anyway. This means that
we wouldn't need to enforce "stay in the foreground", and it'd make
sense again for the default to be services being session leaders.

> I figure I could do some more testing. Also, is there some unit test
> code that deals with this section of the code? Maybe updating the unit
> test code would be in order. I haven't looked at this stuff in many
> months...i'll have to get my head wrapped around it again.
>
There's a lot of unit tests for this section of code, I try and keep
Upstart as near to 100% coverage as possible. See
init/tests/test_job_process.c test_handler()

Scott
--
Scott James Remnant
<email address hidden>