Making a Unix daemon process (was: Forking into the background (Linux))
Hans Mulder han...@xs4all.nl writes: On 24/12/12 01:50:24, Olive wrote: My goal is to write a script that 1) write something to stdout; then fork into the background, closing the stdout (and stderr, stdin) pipe. I have found this answer (forking - setsid - forking) http://stackoverflow.com/a/3356154 You're following a path that leads to the desire for a “daemon” URL:http://stackoverflow.com/questions/473620/how-do-you-create-a-daemon-in-python/688448#688448. You may want to look at the python-daemon module on Pypy, which appears to do what you need, including some features you haven't asked for, yet. It's even better when you look at it on PyPI URL:http://pypi.python.org/pypi/python-daemon/ (note that PyPy is a Python implementation, PyPI is an index of Python packages). The discussion forum for ‘python-daemon’ development is at URL:http://lists.alioth.debian.org/mailman/listinfo/python-daemon-devel. -- \ “Faith may be defined briefly as an illogical belief in the | `\ occurrence of the improbable.” —Henry L. Mencken | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Daemon process
On Wednesday 02 September 2009 05:57:02 Shan wrote: I have XML RPC Server listening on a port. This XML RPC Server works fine when i run it as foreground process. All the clients are able to connect with the XML RPC Server. But when i run it as daemon(not using . I am doing it in python way only), then no clients are able to connect with the Server. I didnt got any clue where i may be wrong. Can any help me with this? I am using python 2.4 on Redhat 5.2 64 X86_64 What does: (not using . I am doing it in python way only) mean? How are you doing it? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Daemon process
En Wed, 02 Sep 2009 00:57:02 -0300, Shan m.shanmugara...@gmail.com escribió: I have XML RPC Server listening on a port. This XML RPC Server works fine when i run it as foreground process. All the clients are able to connect with the XML RPC Server. But when i run it as daemon(not using . I am doing it in python way only), then no clients are able to connect with the Server. I didnt got any clue where i may be wrong. Can any help me with this? I am using python 2.4 on Redhat 5.2 64 X86_64 In what whay no clients are able to connect with the Server? What error(s) do the clients report? Can you see the process running (ps)? Can you see the port open (netstat)? Can you connect to the server using telnet, from the same host? -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Daemon process
I have XML RPC Server listening on a port. This XML RPC Server works fine when i run it as foreground process. All the clients are able to connect with the XML RPC Server. But when i run it as daemon(not using . I am doing it in python way only), then no clients are able to connect with the Server. I didnt got any clue where i may be wrong. Can any help me with this? I am using python 2.4 on Redhat 5.2 64 X86_64 Thanks, Shan -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143 and daemon process
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. 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. 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. -- \ “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 b...@benfinney.id.au signature.asc Description: Digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143 and daemon process
On Mon, Apr 13, 2009 at 8:33 PM, Ben Finney ben+pyt...@benfinney.id.auben%2bpyt...@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 b...@benfinney.id.au -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknj2d4ACgkQIiYF7H0aG3nJ2gCg2BVUX5mJXXS6IgKjlf+76zaP eOQAoKBcO/xEjoKzrjPYjG7lQHt6tGC9 =i+du -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: PID lockfile (was: PEP 3143: Standard daemon process library)
(replying in ‘comp.lang.python’ for wider feedback on this issue) On 26-Mar-2009, Francis Irving wrote: On Thu, Mar 26, 2009 at 12:51:06AM +1100, Ben Finney wrote: The ‘python-daemon’ distribution includes a module, ‘daemon.pidlockfile’. The ‘daemon.pidlockfile.PIDLockFile’ class is intended to be used for this purpose. I am working with the developer of ‘lockfile’ to incorporate the ‘PIDLockFile’ class into that library. Ah! I didn't know about that! Can you update: a) The example in the PEP to use it. No, PEP 3143 is deliberately not tied to that implementation. PID file handling is purely an interface from the point of view of that PEP. When I said “the PIDLockFile class is intended to be used for this purpose”, that's strictly one-way. PEP 3143 is not meant to refer to the PIDLockFile class, only to a generic interface (context manager) for a ‘pidfile’ object. If the ‘pidlockfile’ module improves enough, and the ‘lockfile’ maintainer gets my changes into a release in time, I may update the PEP to recommend that; but so far, it's outside the scope. b) In the documentation, give a list of different classes that might be appropriate to use here. Recommending that one, but pointing to the ones in lockfile also. I don't have one to recommend yet: c) Its own documentation (maybe some doctests in the source? or some help?) which show how it works. I'm still not having much luck with it though :( This is part of why it's not recommended in the PEP; it's not really ready. Thank you for testing it :-) It doesn't seem to have a constructor which sets its path, so do I do: ourlockfile = daemon.pidlockfile.PIDLockFile Presuming you mean ‘daemon.pidlockfile.PIDLockFile()’ here (that is, get the return value of the class constructor, not the class itself). ourlockfile.path = '/tmp/mydaemon.pid' context = daemon.DaemonContext( pidfile=ourlockfile, stdout=logout, stderr=logout ) If so, it doesn't work, it just exits without an error. Can you please provide the full traceback? Another thing: I've noticed there are some ^L characters in daemon.py, e.g. just before class DaemonError, def change_working_directory etc. Yes. That is a page break (ASCII FF), useful for printing the file or navigating the text file by “page”. Python, like most languages, treats them like any other whitespace in the source. So, I think that PIDLockFile will leave the lockfile there if the daemon is killed abruptly (say with kill -9 or due to some bug). Certainly, all the lock classes in lockfile.py have the problem that it stays locked int hat circumstance. I have my programs delete the lockfile on start-up if it's stale (i.e. check for the existence of the file on start-up and delete it if the referenced PID is not running). Perhaps there are better ways. This page (which seems pretty good anyway, and I'm sure you've seen!) section 6) suggests using lockf, although I believe from elsewhere that fcntl will do also. http://www.enderunix.org/docs/eng/daemon.php No, I've not seen that, but I have seen others; they tend to differ in the details. I have looked for a more canonical reference for the intricacies of PID file handling, but it seems to be much more ad hoc than the definition of the daemonisation procedure. My impression is that the lockf is linked to the process, so if the process is killed the kernel will automatically free it. So my suggestion would be to store the pid in a pidfile, and lockf it. Not sure that is the exact convention used by most daemons on Debian, but it might be. On Linux at least, ‘lockf’ is not defined to alter the file at all; it doesn't cause it to be created nor removed. It is purely for a lock on an existing file. It wouldn't be cross platform though. I imagine Windows code for this should be very different from Unix, however - making a service. Explicitly outside the scope of PEP 3143; though it is hoped that the described functionality will make a good basis on which to *build* such a service, on Unix. Would be lovely to have something that provided one interface to both eventually, but probably too wild for now! There is a skeletal PEP on the ‘python-ideas’ list for this purpose URL:http://mail.python.org/pipermail/python-ideas/2009-January/002606.html. Anyone should feel free to develop it further. Thank you for your testing and feedback! And thank you! Your project is well worth doing, Unix daemons are so arcane, and to make them more Pythonic is lovely. -- \ “When we talk to God, we're praying. When God talks to us, | `\ we're schizophrenic.” —Jane Wagner, via Lily Tomlin, 1985 | _o__) | Ben Finney b...@benfinney.id.au -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143: Standard daemon process library
Ben Finney ben+pyt...@benfinney.id.au writes: 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 specification. Thank you to those who have submitted bug reports so far. I have addressed some bugs and uploaded version 1.4.4 of ‘python-daemon’ to PyPI. Changes include: * Catch and report some OSError exceptions thrown by various steps. * Wait until later in the daemonisation process to cloase all open file descriptors. This gives a chance to see errors reported earlier in the process! * Redirect standard streams to the null device if no stream specified. Testing and feedback is still welcome, I want to knock this PEP and implementation into better shape. -- \ “I have never imputed to Nature a purpose or a goal, or | `\anything that could be understood as anthropomorphic.” —Albert | _o__)Einstein, unsent letter, 1955 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143: Standard daemon process library
On Tue, 24 Mar 2009 15:42:46 +1100, Ben Finney bignose+hates-s...@benfinney.id.au wrote: Jean-Paul Calderone exar...@divmod.com writes: [snip] An additional feature which would be useful for the library to provide, however, would be the setting of euid and egid instead of uid and gid. This is necessary, for example, to write an SSH daemon which gives out user shells. That sounds rather more specific than is needed for the generic library being proposed here. I'm wary of adding features to an API that is already quite complex. Isn't setting the EUID and EGID something that is just as easily done *after* the program achieves a daemon process? That depends. If you mean that one can ignore the uid and gid setting features of the proposed library so that they are not changed during daemonization and then make the appropriate calls from the application afterwards, then yes. Otherwise, no. Since this means all of your daemon startup code is forced to run as a privileged process when it might otherwise have run without those privileges, I think it's worth the tiny additional complexity it will bring to the API (and it really is pretty tiny, something on the order of a new `set_effective=True´ flag). Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
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. Regards Floris -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143: Standard daemon process library
Jean-Paul Calderone exar...@divmod.com writes: On Tue, 24 Mar 2009 15:42:46 +1100, Ben Finney bignose+hates-s...@benfinney.id.au wrote: That sounds rather more specific than is needed for the generic library being proposed here. I'm wary of adding features to an API that is already quite complex. Isn't setting the EUID and EGID something that is just as easily done *after* the program achieves a daemon process? That depends. If you mean that one can ignore the uid and gid setting features of the proposed library so that they are not changed during daemonization and then make the appropriate calls from the application afterwards, then yes. Yes, that's what I meant. Otherwise, no. Since this means all of your daemon startup code is forced to run as a privileged process when it might otherwise have run without those privileges Er? You can still set the real UID and GID via the DaemonContext API, and then also set the EUID and EGID. I think it's worth the tiny additional complexity it will bring to the API (and it really is pretty tiny, something on the order of a new `set_effective=True´ flag). It leads immediately to the request to set *both* real UID/GID *and* effective UID/GID to separate values. Can you describe the use case more, so I can understand better how common it might be? In what circumstances must one not change the real UID/GID but instead change the effective UID/GID, *and* must change them during daemonisation? -- \ “One thing vampire children have to be taught early on is, | `\ don't run with a wooden stake.” —Jack Handey | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143: Standard daemon process library
Jean-Paul Calderone exar...@divmod.com writes: Here is a demonstration of the problem: # python -c ' from __future__ import with_statement import sys, daemon, os with daemon.DaemonContext(stdout=sys.stdout, stdin=sys.stdin, stderr=sys.stderr, uid=1, gid=1) as c: pass ' Traceback (most recent call last): File string, line 5, in module File daemon/daemon.py, line 342, in __enter__ File daemon/daemon.py, line 325, in open OSError: [Errno 1] Operation not permitted This hadn't occurred during my testing, but I can see the logic of it. I've now added a test and fixed this; it will be in the next release. Thank you! An additional feature which would be useful for the library to provide, however, would be the setting of euid and egid instead of uid and gid. This is necessary, for example, to write an SSH daemon which gives out user shells. That sounds rather more specific than is needed for the generic library being proposed here. I'm wary of adding features to an API that is already quite complex. Isn't setting the EUID and EGID something that is just as easily done *after* the program achieves a daemon process? -- \“If it ain't bust don't fix it is a very sound principle and | `\ remains so despite the fact that I have slavishly ignored it | _o__) all my life.” —Douglas Adams | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143: Standard daemon process library
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? -- \“The Bermuda Triangle got tired of warm weather. It moved to | `\ Alaska. Now Santa Claus is missing.” —Steven Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143: Standard daemon process library
Jean-Paul Calderone exar...@divmod.com writes: The biggest shortcoming seems to be a complete lack of unit tests. A full unit test suite is in the source distribution's ‘tests/’ directory. You can run it with ‘python ./setup.py test’. A quick skim of the code suggests that part of it don't even work at all and have never been tested, even interactively, since they must surely fail. For example, uid/gid setting is broken. This doesn't help identify the problem. Can you explain what you see as broken, preferably after running the code to observe its behaviour? -- \ “Science shows that belief in God is not only obsolete. It is | `\also incoherent.” —Victor J. Stenger, 2001 | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143: Standard daemon process library
On Sun, 22 Mar 2009 10:19:58 +1100, Ben Finney ben+pyt...@benfinney.id.au wrote: Jean-Paul Calderone exar...@divmod.com writes: The biggest shortcoming seems to be a complete lack of unit tests. A full unit test suite is in the source distribution's ‘tests/’ directory. You can run it with ‘python ./setup.py test’. Of course this is correct. My apologizes for my incorrect statement. I was probably looking for the tests in the daemon directory, not used to seeing them outside the package they are testing. In my hurry I didn't see them. A quick skim of the code suggests that part of it don't even work at all and have never been tested, even interactively, since they must surely fail. For example, uid/gid setting is broken. This doesn't help identify the problem. Can you explain what you see as broken, preferably after running the code to observe its behaviour? Here is a demonstration of the problem: # python -c ' from __future__ import with_statement import sys, daemon, os with daemon.DaemonContext(stdout=sys.stdout, stdin=sys.stdin, stderr=sys.stderr, uid=1, gid=1) as c: pass ' Traceback (most recent call last): File string, line 5, in module File daemon/daemon.py, line 342, in __enter__ File daemon/daemon.py, line 325, in open OSError: [Errno 1] Operation not permitted This happens because setuid is called before setgid. This means that by the time setgid is called, it is no longer allowed. Reversing the order is a simple fix. An additional feature which would be useful for the library to provide, however, would be the setting of euid and egid instead of uid and gid. This is necessary, for example, to write an SSH daemon which gives out user shells. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
PEP 3143: Standard daemon process library (was: Writing a well-behaved daemon)
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 specification. One point to note: This is only intended to address the task of a program transforming *itself* into a daemon process. If you want to spawn off *extra* processes and manage them through a “service” channel, you want something this spec was never meant to cover. You may be interested in discussing that further on a separate thread at URL:http://mail.python.org/pipermail/python-ideas/2009-January/002606.html. If you want to turn your program into a well-behaved daemon process, I'd like to know how well PEP 3143 works for you. Please try it out for your daemon programs and discuss! -- \“The whole area of [treating source code as intellectual | `\property] is almost assuring a customer that you are not going | _o__) to do any innovation in the future.” —Gary Barnett | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143: Standard daemon process library
Ben Finney ben+pyt...@benfinney.id.au writes:
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
specification.
PEP: 3143
Title: Standard daemon process library
Version: $Revision: 1.1 $
Last-Modified: $Date: 2009-03-19 12:51 $
Author:Ben Finney ben+pyt...@benfinney.id.au
Status:Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2009-01-26
Python-Version:3.2
Post-History:
Abstract
Writing a program to become a well-behaved Unix daemon is somewhat
complex and tricky to get right, yet the steps are largely similar for
any daemon regardless of what else the program may need to do.
This PEP introduces a package to the Python standard library that
provides a simple interface to the task of becoming a daemon process.
.. contents::
..
Table of Contents:
Abstract
Specification
Example usage
Interface
``DaemonContext`` objects
Motivation
Rationale
Correct daemon behaviour
A daemon is not a service
Reference Implementation
Other daemon implementations
References
Copyright
=
Specification
=
Example usage
=
Simple example of direct `DaemonContext` usage::
import daemon
from spam import do_main_program
with daemon.DaemonContext() as daemon_context:
do_main_program()
More complex example usage::
import os
import grp
import signal
import daemon
import lockfile
from spam import (
initial_program_setup,
do_main_program,
program_cleanup,
reload_program_config,
)
context = daemon.DaemonContext(
working_directory='/var/lib/foo',
umask=0o002,
pidfile=lockfile.FileLock('/var/run/spam.pid'),
)
context.signal_map = {
signal.SIGTERM: program_cleanup,
signal.SIGHUP: 'terminate',
signal.SIGUSR1: reload_program_config,
}
mail_gid = grp.getgrnam('mail').gr_gid
context.gid = mail_gid
important_file = open('spam.data', 'w')
interesting_file = open('eggs.data', 'w')
context.files_preserve = [important_file, interesting_file]
initial_program_setup()
with context:
do_main_program()
Interface
=
A new package, `daemon`, is added to the standard library.
A class, `DaemonContext`, is defined to represent the settings and
process context for the program running as a daemon process.
``DaemonContext`` objects
=
A `DaemonContext` instance represents the behaviour settings and
process context for the program when it becomes a daemon. The
behaviour and environment is customised by setting options on the
instance, before calling the `open` method.
Each option can be passed as a keyword argument to the `DaemonContext`
constructor, or subsequently altered by assigning to an attribute on
the instance at any time prior to calling `open`. That is, for
options named `wibble` and `wubble`, the following invocation::
foo = daemon.DaemonContext(wibble=bar, wubble=baz)
foo.open()
is equivalent to::
foo = daemon.DaemonContext()
foo.wibble = bar
foo.wubble = baz
foo.open()
The following options are defined.
`files_preserve`
:Default: ``None``
List of files that should *not* be closed when starting the
daemon. If ``None``, all open file descriptors will be closed.
Elements of the list are file descriptors (as returned by a file
object's `fileno()` method) or Python `file` objects. Each
specifies a file that is not to be closed during daemon start.
`chroot_directory`
:Default: ``None``
Full path to a directory to set as the effective root directory of
the process. If ``None``, specifies that the root directory is not
to be changed.
`working_directory`
:Default: ``'/'``
Full path of the working directory to which the process should
change on daemon start.
Since a filesystem cannot be unmounted if a process has its
current working directory on that filesystem, this should either
be left at default or set to a directory that is a sensible “home
directory” for the daemon while it is running.
`umask`
:Default: ``0``
File access creation mask (“umask”) to set for the process on
daemon start.
Since a process inherits its umask from its parent process,
starting the daemon will reset the umask to this value so that
files are created by the daemon with access modes as it expects.
`pidfile`
:Default: ``None``
Context manager for a PID lock file. When the daemon context opens
and closes, it enters
Re: PEP 3143: Standard daemon process library (was: Writing a well-behaved daemon)
On Fri, 20 Mar 2009 20:58:58 +1100, 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 specification. The biggest shortcoming seems to be a complete lack of unit tests. A quick skim of the code suggests that part of it don't even work at all and have never been tested, even interactively, since they must surely fail. For example, uid/gid setting is broken. I'd recommend adding an automated test suite, fixing all the issues that come up during that process, and then asking for scrutiny again. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143: Standard daemon process library
On Fri, 20 Mar 2009 21:47:00 +1100, Ben Finney bignose+hates-s...@benfinney.id.au wrote: [snip] Somewhat by accident I noticed this other part of the PEP: Other Python daemon implementations that differ from this PEP: [snip] * Twisted [twisted]_ includes, perhaps unsurprisingly, an implementation of a process daemonisation API that is integrated with the rest of the Twisted framework; it differs significantly from the API in this PEP. What do you mean be integrated? Twisted's daemonization code is in a free function which depends only on the os module. It's basically as un-integrated as could be (it's also only 14 lines long). Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3143: Standard daemon process library (was: Writing a well-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 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. Regards Floris -- http://mail.python.org/mailman/listinfo/python-list
writing a message to the terminal in a daemon process
hi, i created a daemon process using the following code import os import sys # Default daemon parameters. # File mode creation mask of the daemon. UMASK = 0 # Default working directory for the daemon. WORKDIR = / # Default maximum for the number of available file descriptors. MAXFD = 1024 # The standard I/O file descriptors are redirected to /dev/null by default. if (hasattr(os, devnull)): REDIRECT_TO = os.devnull else: REDIRECT_TO = /dev/null def goDaemon(): try: pid = os.fork() except OSError, e: raise Exception, %s [%d] % (e.strerror, e.errno) if (pid == 0): # The first child. os.setsid() try: pid = os.fork()# Fork a second child. except OSError, e: raise Exception, %s [%d] % (e.strerror, e.errno) if (pid == 0):# The second child. #os.chdir(WORKDIR) os.umask(UMASK) else: os._exit(0) else: os._exit(0) # Exit parent of the first child. import resource maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1] if (maxfd == resource.RLIM_INFINITY): maxfd = MAXFD for fd in range(0, maxfd): try: os.close(fd) except OSError: # ERROR, fd wasn't open to begin with (ignored) pass os.open(REDIRECT_TO, os.O_RDWR) # standard input (0) os.dup2(0, 1)# standard output (1) os.dup2(0, 2)# standard error (2) return(0) it can be seen that the standard output and standard error are redirected to null terminal now after the process is made daemon i.e after closing all the resources and redirecting the standard output and standard error to null terminal now I want to print some initial msg on the console(terminal) in which the program was started . *NOTE*:I realize that initial msg can be printed before closing all the resources and redirecting the standard output and standard error to null terminal but it necessary to print the msg after the process is made daemon i.e when the process actually starts doing some processing. I tried with following code: fd=os.open(/dev/tty,os.O_WRONLY) os.write(fd,msg) os.close(fd) but this worked fine before closing all the resources and redirecting the standard output and standard error to null terminal and after doing all these even it didn't help it didn't print any thing on the terminal pls can anyone how this can be done -- http://mail.python.org/mailman/listinfo/python-list
Re: pySerial in a daemon process
In message [EMAIL PROTECTED], paul wrote: Before I had posted this question first thing I did was to look at / dev/ttyS0, and indeed the group is dialout (gid=20)... What are the full protections on the serial port? That is, can you post the output of ls -l /dev/ttyS0 please? -- http://mail.python.org/mailman/listinfo/python-list
pySerial in a daemon process
I am writing a daemon process that reads data from the serial port / dev/ttyS0. I am using pyserial the method for setting up a daemon described in Chris' Python Page (http://homepage.hispeed.ch/py430/ python/) on an Ubuntu linux pc. Everything works great EXCEPT... in the daemon script, there are two lines to change the uid gid that the script runs as: os.setegid(10) os.seteuid(1000) If I comment these out, so that the daemon runs as root, then everything works fine. I can also manually run the script that the daemon process kicks off from my own id just fine. If I put these back in and try to run the daemon, the script fails when I try to connect to the serial port, with this error: serial.serialutil.SerialException: Could not open port: [Errno 13] Permission denied: '/dev/ttyS0' In my debugging I have tried setting the uid to my own uid, and the gid to a variety of different groups that I belong to. None of them work. I could certainly run the daemon as root, but I would rather not. What really confuses me is that if I manually run the script as myself (without using the daemon script), it connects fine, but when root uses os.seteuid() to my uid, it fails. What do I need to do to get this to work? Many thanks, Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: pySerial in a daemon process
paul wrote: If I put these back in and try to run the daemon, the script fails when I try to connect to the serial port, with this error: serial.serialutil.SerialException: Could not open port: [Errno 13] Permission denied: '/dev/ttyS0' Did you check the permissions on this file? Often you have to be member of a dialout group or similar to get access. Regards, Björn -- BOFH excuse #172: pseudo-user on a pseudo-terminal -- http://mail.python.org/mailman/listinfo/python-list
Re: pySerial in a daemon process
On Aug 26, 5:20 pm, Bjoern Schliessmann usenet- [EMAIL PROTECTED] wrote: paul wrote: If I put these back in and try to run the daemon, the script fails when I try to connect to the serial port, with this error: serial.serialutil.SerialException: Could not open port: [Errno 13] Permission denied: '/dev/ttyS0' Did you check the permissions on this file? Often you have to be member of a dialout group or similar to get access. Regards, Björn -- BOFH excuse #172: pseudo-user on a pseudo-terminal THANKS! That did it, but perhaps can you explain to me why... Before I had posted this question first thing I did was to look at / dev/ttyS0, and indeed the group is dialout (gid=20), so I tried a couple of things: 1. checked my id to see if I was a member of dialout, and indeed I am. So, I edited the daemon script to use my id and set the gid to dialout (ie: os.setegid(20) os.seteuid(1000)) and it still failed. 2. made the id I really want to use (pydaemon, uid=110) a member of dialout, and set the daemon script to use those (ie: os.setegid(20) os.seteuid(110)) and it still failed... After reading your comment, I went and did a chgrp to set the various script file groups to dialout, and indeed it now works. What confuses me is that if the script needed that group, why doesn't the setegid or seteuid fail? Why does the script keep running okay until the connect, and fail then? Thanks! Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a non-root daemon process
Ben Finney [EMAIL PROTECTED] writes: Hmm. I typed the example program in as a simplified version of what I'm doing; but didn't actually *run* it. When I do run it, I get no exception, as you say. Now I'll have to find out what significant difference there is between my failing code and this example, and report back in this thread. It turns out that, in re-typing the algorithm in the newsgroup message, I got all the branches correct; but in the code that wasn't working, I had reversed one of them :-) All fine now. We return you to your regularly scheduled programming. -- \ My aunt gave me a walkie-talkie for my birthday. She says if | `\ I'm good, she'll give me the other one next year. -- Steven | _o__) Wright | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a non-root daemon process
On Mar 22, 11:19 pm, Ben Finney [EMAIL PROTECTED] wrote: Howdy all, For making a Python program calve off an independent daemon process of itself, I found Carl J. Schroeder's recipe in the ASPN Python Cookbook. URL:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278731 This is a thorough approach, and I'm cribbing a simpler process from this example. One thing that strikes me is that the algorithm seems to depend on running the program as the root user. import os def become_daemon(): pid = os.fork() if pid == 0: # This is the child of the fork # Become a process leader of a new process group os.setsid() # Fork again and exit this parent pid = os.fork() if pid == 0: # This is the child of the second fork -- the running process. pass else: # This is the parent of the second fork # Exit to prevent zombie process os._exit(0) else: # This is the parent of the fork os._exit(0) become_daemon() # Continue with the program The double-fork seems to be to: - Allow the first forked child to start a new process group - Allow the second forked child to be orphaned immediately The problem I'm having is that 'os.setsid()' fails with 'OSError: [Errno 1] Operation not permitted' unless I run the program as the root user. This isn't a program that I want necessarily running as root. It works for me. I mean your program above produces no exceptions for me on Debian 3.1 python2.4 What does the 'os.setsid()' gain me? It dettaches you from terminal. It means you won't receive signals from terminal for sure. Like SIGINT and SIGHUP, but there are maybe other. How can I get that without being the root user? Maybe you can go over the list of all possible signals from the terminal and notify kernel that you want to ignore them. Sounds similar to dettaching from the terminal, but maybe there some differences. But the fact that os.setsid fails for you is weird anyway. -- Leo. -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a non-root daemon process
Leo Kislov [EMAIL PROTECTED] writes: On Mar 22, 11:19 pm, Ben Finney [EMAIL PROTECTED] wrote: The problem I'm having is that 'os.setsid()' fails with 'OSError: [Errno 1] Operation not permitted' unless I run the program as the root user. This isn't a program that I want necessarily running as root. It works for me. I mean your program above produces no exceptions for me on Debian 3.1 python2.4 Hmm. I typed the example program in as a simplified version of what I'm doing; but didn't actually *run* it. When I do run it, I get no exception, as you say. Now I'll have to find out what significant difference there is between my failing code and this example, and report back in this thread. Thanks for showing me this far :-) -- \Some people, when confronted with a problem, think 'I know, | `\ I'll use regular expressions'. Now they have two problems. -- | _o__)Jamie Zawinski, in alt.religion.emacs | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Making a non-root daemon process
Howdy all, For making a Python program calve off an independent daemon process of itself, I found Carl J. Schroeder's recipe in the ASPN Python Cookbook. URL:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278731 This is a thorough approach, and I'm cribbing a simpler process from this example. One thing that strikes me is that the algorithm seems to depend on running the program as the root user. import os def become_daemon(): pid = os.fork() if pid == 0: # This is the child of the fork # Become a process leader of a new process group os.setsid() # Fork again and exit this parent pid = os.fork() if pid == 0: # This is the child of the second fork -- the running process. pass else: # This is the parent of the second fork # Exit to prevent zombie process os._exit(0) else: # This is the parent of the fork os._exit(0) become_daemon() # Continue with the program The double-fork seems to be to: - Allow the first forked child to start a new process group - Allow the second forked child to be orphaned immediately The problem I'm having is that 'os.setsid()' fails with 'OSError: [Errno 1] Operation not permitted' unless I run the program as the root user. This isn't a program that I want necessarily running as root. What does the 'os.setsid()' gain me? How can I get that without being the root user? -- \ I went to a general store. They wouldn't let me buy anything | `\ specifically. -- Steven Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
Eirikur Hallgrimsson [EMAIL PROTECTED] wrote: def daemonize(): if (not os.fork()): # get our own session and fixup std[in,out,err] os.setsid() sys.stdin.close() sys.stdout = NullDevice() sys.stderr = NullDevice() That doesn't close the underlying file descriptors... Here is another method which does :- null = os.open(os.devnull, os.O_RDWR) os.dup2(null, sys.stdin.fileno()) os.dup2(null, sys.stdout.fileno()) os.dup2(null, sys.stderr.fileno()) os.close(null) if (not os.fork()): # hang around till adopted by init ppid = os.getppid() while (ppid != 1): time.sleep(0.5) ppid = os.getppid() Why do you need hang around until adopted by init? I've never see that in a daemonize recipe before? else: # time for child to die os._exit(0) else: # wait for child to die and then bail os.wait() sys.exit() -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
On Fri, 23 Feb 2007 08:30:07 -0600, Nick Craig-Wood [EMAIL PROTECTED] wrote: Eirikur Hallgrimsson [EMAIL PROTECTED] wrote: [snip] if (not os.fork()): # hang around till adopted by init ppid = os.getppid() while (ppid != 1): time.sleep(0.5) ppid = os.getppid() Why do you need hang around until adopted by init? I've never see that in a daemonize recipe before? I think it simplifies some signal handling logic. I'd never seen it before in a deamonizer either, but it caught my eye in this one. I haven't had time to investigate further though. I hope Eirikur will explain. :) Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
I didn't actually write this module. I believe I found it in a discussion in ASPN at Active State. Thanks for the input, and when I get a chance I will try these alternate approaches. This module has been working fine for me as is--so far. Eirikur -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
Thanks all, I understood there is no shortcut function like BSD daemon(). I'll do it manually using examples from cookbook... On 2月22日, 午前1:41, Benjamin Niemann [EMAIL PROTECTED] wrote: Hello, Sakagami Hiroki wrote: What is the easiest way to create a daemon process in Python? Google says I should call fork() and other system calls manually, but is there no os.daemon() and the like? You could try http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278731 HTH -- Benjamin Niemann Email: pink at odahoda dot de WWW:http://pink.odahoda.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
On 2007-02-22, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I understood there is no shortcut function like BSD daemon(). I'll do it manually using examples from cookbook... Sure would be nice if somebody posted one. ;) -- Grant Edwards grante Yow! Oh, I get it!! The at BEACH goes on, huh, visi.comSONNY?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
Benjamin Niemann wrote: What is the easiest way to create a daemon process in Python? Google says I should call fork() and other system calls manually, but is there no os.daemon() and the like? You could try http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278731 Also, more discussion on the topic here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012 j -- Joshua Kugler Lead System Admin -- Senior Programmer http://www.eeinternet.com PGP Key: http://pgp.mit.edu/ ID 0xDB26D7CE -- Posted via a free Usenet account from http://www.teranews.com -- http://mail.python.org/mailman/listinfo/python-list
Creating a daemon process in Python
Hi, What is the easiest way to create a daemon process in Python? Google says I should call fork() and other system calls manually, but is there no os.daemon() and the like? Regards, -- Sakagami Hiroki -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
Hello, Sakagami Hiroki wrote: What is the easiest way to create a daemon process in Python? Google says I should call fork() and other system calls manually, but is there no os.daemon() and the like? You could try http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278731 HTH -- Benjamin Niemann Email: pink at odahoda dot de WWW: http://pink.odahoda.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
Sakagami Hiroki wrote: Hi, What is the easiest way to create a daemon process in Python? I find that this works great. I just pasted my copy, I think you can find it via Google. Eirikur # Daemon Module - basic facilities for becoming a daemon process # By Coy Krill # Combines ideas from Steinar Knutsens daemonize.py and # Jeff Kunces demonize.py Facilities for Creating Python Daemons import os import time import sys class NullDevice: def write(self, s): pass def daemonize(): if (not os.fork()): # get our own session and fixup std[in,out,err] os.setsid() sys.stdin.close() sys.stdout = NullDevice() sys.stderr = NullDevice() if (not os.fork()): # hang around till adopted by init ppid = os.getppid() while (ppid != 1): time.sleep(0.5) ppid = os.getppid() else: # time for child to die os._exit(0) else: # wait for child to die and then bail os.wait() sys.exit() -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
On Feb 21, 9:33 am, Eirikur Hallgrimsson [EMAIL PROTECTED] wrote: Sakagami Hiroki wrote: What is the easiest way to create a daemon process in Python? I've found it even easier to use the built in threading modules: import time t1 = time.time() print t_poc.py called at, t1 import threading def im_a_thread(): time.sleep(10) print This is your thread speaking at, time.time() thread = threading.Thread(target=im_a_thread) thread.setDaemon(True) thread.start() t2 = time.time() print Time elapsed in main thread:, t2 - t1 Of course, your mileage may vary. -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
[EMAIL PROTECTED] wrote: On Feb 21, 9:33 am, Eirikur Hallgrimsson [EMAIL PROTECTED] wrote: Sakagami Hiroki wrote: What is the easiest way to create a daemon process in Python? I've found it even easier to use the built in threading modules: import time t1 = time.time() print t_poc.py called at, t1 import threading def im_a_thread(): time.sleep(10) print This is your thread speaking at, time.time() thread = threading.Thread(target=im_a_thread) thread.setDaemon(True) thread.start() t2 = time.time() print Time elapsed in main thread:, t2 - t1 Of course, your mileage may vary. That's not a daemon process (which are used to execute 'background services' in UNIX environments). -- Benjamin Niemann Email: pink at odahoda dot de WWW: http://pink.odahoda.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a daemon process in Python
On Feb 21, 3:34 pm, Benjamin Niemann [EMAIL PROTECTED] wrote: That's not a daemon process (which are used to execute 'background services' in UNIX environments). I had not tested this by running the script directly, and in writing a response, I found out that the entire interpreter closed when the main thread exited (killing the daemonic thread in the process). This is different behavior from running the script interactively, and thus my confusion. Thanks! ~Garrick -- http://mail.python.org/mailman/listinfo/python-list
Re: Python daemon process
I might not have made myself very clear, since you both got me wrong. What I need, is not a method to terminate a process, but a way to terminate a process when the main process dies. From the atexit module info: Note: the functions registered via this module are not called when the program is killed by a signal, when a Python fatal internal error is detected, or when os._exit() is called. I belive that there is noway you can be sure to get a piece of code run, if the program crashes or something like that, therefor I ask for a way to run gnuchess as a kind of subprocess, that can only run when the parrentprocess is still running. I know this is called a daemon thread in java. 2006/8/26, Thomas Dybdahl Ahle [EMAIL PROTECTED]: Hi, I'm writing a program, using popen4(gnuchess), The problem is, that gnuchess keeps running after program exit. I know about the atexit module, but in java, you could make a process a daemon process, and it would only run as long as the real processes ran. I think this is a better way to stop gnuchess, as you are 100% sure, that it'll stop. Can you do this with popen? -- Thomas -- http://mail.python.org/mailman/listinfo/python-list You could send the quit (or close or wahtever) command to gnuchess when you want it to terminate. Supposing that gnuchess needs to do some stuff on exit, this is a better solution. PAolo -- Programmers should realize their critical importance and responsibility in a world gone digital. They are in many ways similar to the priests and monks of Europe's Dark Ages; they are the only ones with the training and insight to read and interpret the scripture of this age. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python daemon process
2006/8/26, Thomas Dybdahl Ahle [EMAIL PROTECTED]: Hi, I'm writing a program, using popen4(gnuchess), The problem is, that gnuchess keeps running after program exit. I know about the atexit module, but in java, you could make a process a daemon process, and it would only run as long as the real processes ran. I think this is a better way to stop gnuchess, as you are 100% sure, that it'll stop. Can you do this with popen? -- Thomas -- http://mail.python.org/mailman/listinfo/python-list You could send the quit (or close or wahtever) command to gnuchess when you want it to terminate. Supposing that gnuchess needs to do some stuff on exit, this is a better solution. PAolo -- if you have a minute to spend please visit my photogrphy site: http://mypic.co.nr -- http://mail.python.org/mailman/listinfo/python-list
Python daemon process
Hi, I'm writing a program, using popen4(gnuchess), The problem is, that gnuchess keeps running after program exit. I know about the atexit module, but in java, you could make a process a daemon process, and it would only run as long as the real processes ran. I think this is a better way to stop gnuchess, as you are 100% sure, that it'll stop. Can you do this with popen? -- Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Python daemon process
process = subprocess.Popen(gnuchess) ... os.kill(process.pid, signal.SIGKILL) Thomas Dybdahl Ahle wrote: Hi, I'm writing a program, using popen4(gnuchess), The problem is, that gnuchess keeps running after program exit. I know about the atexit module, but in java, you could make a process a daemon process, and it would only run as long as the real processes ran. I think this is a better way to stop gnuchess, as you are 100% sure, that it'll stop. Can you do this with popen? -- Thomas -- http://mail.python.org/mailman/listinfo/python-list
