PEP 3143 and daemon process

[Alfredo Deza]

On Mon, Apr 13, 2009 at 8:33 PM, Ben Finney
<ben+python at benfinney.id.au<ben%2Bpython at benfinney.id.au>
> wrote:

> On 13-Apr-2009, Alfredo Deza wrote:
> > By "compliant", I do mean to reference PEP 3143 for building the app.
>
> I'm still not sure what you mean by this. I can only assume you mean
> that your program will assume the existence of a PEP 3143
> implementation (like the ‘python-daemon’ library), and your program
> will use its API.


Correct.

>
> > I am not sure how to continue now though, is weird, I can swear I
> > searched for a while for libraries on how to daemonize correctly a
> > Python application and could not find anything quite like it.
>
> Note that, as described in PEP 3143, “daemonize a program” means
> nothing more than making the *current program* become a daemon
> process. It implies nothing special about external interaction with
> that process; having a service channel for controlling a separate
> process isn't part of becoming a daemon.
>


>
> > And now I know of python-daemon, python-ll-core (has a daemon
> > module) and daemon.py
> > <http://www.clapper.org/software/python/daemon/>
> >
> > Do you think I am going in the right direction?
>
> I'm still not clear on what your current direction is :-) As its
> champion, I think using PEP 3143 as a basis is the right direction,
> and have provided ‘python-daemon’ to help people get there.
>

> > The initial idea was to be able to build something I saw was not
> > available (or not fully available) but much needed. I have several
> > projects that would benefit from a Daemonizing Module that is able
> > to offer functionality like reload, restart, stop, start, logs,
> > force quit etc...
>
> You're asking, then, for what is commonly called a “service” process
> model. When implemented on Unix, this makes use of a daemon, but does
> something significantly more; PEP 3143 explicitly doesn't cover it,
> but is designed to be a good basis for it.
>

Ok, I wasn't aware of this. Always thought of 'service' as something not
Unix but more Win32.
Again, I apologize for the mix-up, I thought a Daemon was not only a
detached  process, but something that was able to act upon commands.

>
> What you want is someone to develop and champion a “service” PEP
> <URL:
> http://mail.python.org/pipermail/python-ideas/2009-January/002606.html>
> and implementation library. That person is not going to be me, but I
> encourage use of the daemon library API as a basis for implementing
> the Unix platform specifics of a service API.
>

I read your proposal and it now makes sense the difference between 'service'
and 'daemon'. Thanks for taking the time to explain further, this will help
me out and avoid further confusion.

-Alfredo

>
> --
>  \       “One of the most important things you learn from the internet |
>  `\   is that there is no ‘them’ out there. It's just an awful lot of |
> _o__)                                            ‘us’.” —Douglas Adams |
> Ben Finney <ben at benfinney.id.au>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAknj2d4ACgkQIiYF7H0aG3nJ2gCg2BVUX5mJXXS6IgKjlf+76zaP
> eOQAoKBcO/xEjoKzrjPYjG7lQHt6tGC9
> =i+du
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090413/e6c429bf/attachment-0001.html>