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 _______________________________________________ python-daemon-devel mailing list python-daemon-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-daemon-devel
