Re: PEP 3143: Standard daemon process library (was: Writing awell-behaved daemon)
On Mar 20, 9:58*am, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> Ben Finney <b...@benfinney.id.au> writes:
> > Writing a Python program to become a Unix daemon is relatively
> > well-documented: there's a recipe for detaching the process and
> > running in its own process group. However, there's much more to a
> > Unix daemon than simply detaching.
> > My searches for such functionality haven't borne much fruit though.
> > Apart from scattered recipes, none of which cover all the essentials
> > (let alone the optional features) of 'daemon', I can't find anything
> > that could be relied upon. This is surprising, since I'd expect this
> > in Python's standard library.
> I've submitted PEP 3143 <URL:http://www.python.org/dev/peps/pep-3143/>
> to meet this need, and have re-worked an existing library into a new
> ‘python-daemon’ <URL:http://pypi.python.org/pypi/python-daemon/>
> library, the reference implementation.
> Now I need wider testing and scrutiny of the implementation and
Had a quick look at the PEP and it looks very nice IMHO.
One of the things that might be interesting is keeping file
descriptors from the logging module open by default. So that you can
setup your loggers before you daemonise --I do this so that I can
complain on stdout if that gives trouble-- and are still able to use
them once you've daemonised. I haven't looked at how feasable this is
yet so it might be difficult, but useful anyway.
Re: PEP 3143: Standard daemon process library
On Mar 21, 11:06*pm, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> Floris Bruynooghe <floris.bruynoo...@gmail.com> writes:
> > Had a quick look at the PEP and it looks very nice IMHO.
> Thank you. I hope you can try the implementation and report feedback
> on that too.
> > One of the things that might be interesting is keeping file
> > descriptors from the logging module open by default.
> Hmm. I see that this would be a good idea. but it raises the question
> of how to manage the set of file handles that should not be closed on
> becoming a daemon.
> So far, the logic of closing the file descriptors is a little complex:
> * * * Close all open file descriptors. This excludes those listed in
> * * * the `files_preserve` attribute, and those that correspond to the
> * * * `stdin`, `stdout`, or `stderr` attributes.
> Extending that by saying “… and also any file descriptors for
> ``logging.FileHandler`` objects” starts to make the description too
> complex. I have a strong instinct that it the description is complex,
> the design might be bad.
> Can you suggest an alternative API that will ensure that all file
> descriptors get closed *except* those that should not be closed?
Not an answer yet, but I'll try to find time in the next few days to
play with this and tell you what I think. logging.FileHandler would
be too narrow in any case I think.
|All times are GMT. The time now is 07:19 AM.|
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.