Re: PEP 3143: Standard daemon process library (was: Writing awell-behaved daemon)

Discussion in 'Python' started by Floris Bruynooghe, Mar 20, 2009.

  1. On Mar 20, 9:58 am, Ben Finney <> wrote:
    > Ben Finney <> 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:>
    > to meet this need, and have re-worked an existing library into a new
    > ‘python-daemon’ <URL:>
    > library, the reference implementation.
    > Now I need wider testing and scrutiny of the implementation and
    > specification.

    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.

    Floris Bruynooghe, Mar 20, 2009
    1. Advertising

  2. Re: PEP 3143: Standard daemon process library

    On Mar 21, 11:06 pm, Ben Finney <> wrote:
    > Floris Bruynooghe <> 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.

    Floris Bruynooghe, Mar 24, 2009
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Muddy Coder

    Why WTK behaved weirdly?

    Muddy Coder, Jul 29, 2008, in forum: Java
    Muddy Coder
    Jul 29, 2008
  2. Sean DiZazzo

    Re: Writing a well-behaved daemon

    Sean DiZazzo, Sep 26, 2008, in forum: Python
    Sean DiZazzo
    Sep 26, 2008
  3. Jean-Paul Calderone
    Jean-Paul Calderone
    Mar 20, 2009
  4. Replies:
    Eric Hodel
    Nov 11, 2005
  5. Jan Pokorný
    Jan Pokorný
    Mar 11, 2012

Share This Page