[Python-ideas] Draft PEP (version 0.4): Standard daemon process library

[Ben Finney]

Antoine Pitrou <solipsis at pitrou.net> writes:

> Hello,
> 
> > `files_preserve`
> >     :Default: ``None``
> > 
> >     List of files that should *not* be closed when starting the
> >     daemon.
> 
> Why does it have to be explicit? If I have an open file lying
> around, it should be obvious that I don't want it closed. Otherwise
> I'd have closed it myself...

Is it so obvious? In Python programs, I far more often see files left
open simply because the programmer expects them to be cleaned up at
the appropriate time. By the references cited in this PEP, the time of
starting the daemon is such an appropriate time to close all open file
descriptors.

> > `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.
> 
> Why this behaviour?

Because the umask is inherited from the environment of the parent
process of the current program, which is good when the current program
is conceptually an extension of the parent program's environment, but
not in the case where one is intentionally disassociating from that
environment.

> It's easy enough to call os.umask() manually if you want it, but
> there are certainly situations where you don't want to change the
> umask (situations where the daemon is meant to act on behalf of the
> user who started it).

Those situations exist, but I would argue they are not the common
case.

> Or, perhaps, umask could be made [mandatory when the options ‘uid’
> or ‘gid’ are set.]

That diverges from the referenced “correct behaviour”, in particular
the Stevens reference. I think if this PEP is worth implementing, it's
for exactly the purpose of providing a Python implementation of
defined correct daemon behaviour; that definition includes re-setting
the umask.

> (regardless of which, 0 isn't a sensible umask default!)

The default umask ‘0’ is chosen in the references as the umask that
allows file access modes for files created by the daemon to work as
expected. Quoting Stevens:

    This prevents any files created by the daemon from having their
    access bits modified. For example, if a daemon specifically
    created a file with a mode of 0660, so that only the user and
    group could read and write the file, but the ``umask`` value was
    060, the group read and write permissions would be turned off. If
    the daemon required the group permissions to be on, so that some
    other process in that group could access the file, this ``umask``
    value prevents it.

-- 
 \        “I don't accept the currently fashionable assertion that any |
  `\       view is automatically as worthy of respect as any equal and |
_o__)                                   opposite view.” —Douglas Adams |
Ben Finney