(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