PEP 3143 and customizations

[Helmut Grohne]

Thanks for the working on the daemonizing problem.

Please CC me in reply, because I am not subscribed to the list.

I figured that the interface suggested makes it very hard (or impossible)
to customize the process beyond the explicitly mentioned objects (such as
chroot_directory). For instance the daemon might be splitting up its work
to multiple child processes (think multiprocessing). If this is the case
the initialization can only take place in the daemon context, because
otherwise there is no way to wait for the workers later. This means that
some initialization has to be pushed in the daemon context as well. The
latter may fail, but there is no way to report failures anymore, because
the parent's parent process already exited immediately after the fork.

The desired behavior would be to do all the setup steps possible, then
daemonize, do the remaining steps and then tell the parent to exit with
or without an error. Technically this can be achieved by opening a pipe
before forking. The process in daemon context can then signal its
startup completion by closing the pipe or signal a failure by writing a
message to the pipe. The parent would read all data from the pipe and 
only then exit.

A library has to limit itself to common cases, so I can understand that
the daemon module does not cover this case. Unfortunately there is no way
(beyond monkey patching) to extend the library in this way as a user.

Adding more knobs for different resource limits also seems like a useful
addition. Yet adding more attributes for every possible case seems
unreasonable. Instead some kind of hooking mechanism seems in order.
Another use case for such hooks would be some method to set up a Linux
seccomp filter or configure a Linux control group.

Helmut