On 22-Jul-2014, Michael Hrivnak wrote: > With great respect to the Stevens reference, it should not be > followed blindly.
I don't wish anyone to follow anything blindly. Why do you say that? The Stevens reference gives a good rationale for setting umask to 0. If you know of a more authoritative reference for the details of how a program should become a well-behaved Unix daemon, I'm open to learn. Until then, meeting the promise of implementing a well-behaved Unix daemon entails following the specifics of the Stevens description, where feasible. I don't consider it acceptable to violate that promise. > I think Ian has nailed the important issue, that python's > limitations make safe behavior difficult to implement with a umask > of 0. The Stevens reference gives a good rationale. What alternative value has a better specific rationale? What is that rationale? > Running any python process with a umask of 0 makes common builtins > and parts of the standard library unsafe. Yes, this puts the onus on the implementor of the daemon to make a deliberate decision to set a specific umask value. For now I'm inclined to update the ‘python-daemon’ documentation on why and how to do that. > While everyone expects that writing in C requires you to think about > and manage every little detail of your application's behavior, > python has more of a culture where people expect things to "just > work". That's laudable. Where there is ambiguity, though, Python also has a strong culture of refusing the temptation to guess what is meant. -- \ “Repetition leads to boredom, boredom to horrifying mistakes, | `\ horrifying mistakes to God-I-wish-I-was-still-bored, and it | _o__) goes downhill from there.” —Will Larson, 2008-11-04 | Ben Finney <[email protected]>
signature.asc
Description: Digital signature
_______________________________________________ python-daemon-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-daemon-devel
