[Python-ideas] Draft PEP: Standard daemon process library

Ben Finney ben+python at benfinney.id.au
Wed Jan 28 04:24:27 CET 2009

(I'm only addressing commentary on the current PEP here. Comparisons
to MS Windows services have been addressed in other messages.)

Trent Nelson writes:

> On Wed, Jan 28, 2009 at 01:15:41PM +1100, Ben Finney wrote:
> > `prevent_core`
> >    :Default: ``True``
> >
> >        If true, prevents the generation of core files, in order to
> >        avoid leaking sensitive information from daemons run as
> >        `root`.
>     I was going to suggest service.set_secure(True)

That name implies something emphatically not true: that a program's
security is a binary toggle, and it can be turned on or off.

> but then I wondered what is this actually achieving? Won't the
> resulting .core will be owned by root?

Yes. Which is less secure than never creating the core file at all.

> >`lockfile_directory`
> >    :Default: ``'/var/run'``
> >
> >    Absolute directory path to contain the daemon's lockfile. If
> >    ``None``, the lockfile behaviour for this daemon is skipped.
> >
> >`lockfile_name`
> >    :Default: ``None``
> >
> >    Base name of the lockfile for this daemon, without directory or
> >    suffix. If ``None``, the name is derived from the process command
> >    line.
>     All you're doing is ensuring multiple instances of the daemon
>     don't run.

Also allowing the location and name of the lock file to be customised.

>  On Windows, you'd use a mutex, on Unix, sure, lockfile makes sense.
>  A cross-platform interface wouldn't bother exposing this
>  implementation detail.

The details are exposed precisely so that they can be customised by
programs that need it. This is common, for example, to allow for
differing conventions or standards of filesystem layout.

 \         “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\    Brain, but I find scratching just makes it worse.” —_Pinky and |
_o__)                                                       The Brain_ |
Ben Finney

More information about the Python-ideas mailing list