Antoine Pitrou <solipsis@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