On Wed, Apr 15, 2015 at 6:48 PM, Matthew Miller mattdm@mattdm.org wrote:
On Wed, Apr 15, 2015 at 05:31:52PM -0500, Les Mikesell wrote:
Thanks - I can see how those would work once you understand what is broken on the target system and why, but is there a way that programs 'should' be written to run with/without systemd? That just happened to be the first thing I've tried to move over that wasn't already packaged and adapted - I expect to hit many more.
This isn't really a systemd thing. It's a standard Linux kernel feature, which could also be enabled with (for example) pam_namespace. Systemd happens to make it easy, so we started enabling it for services which would benefit on Fedora, and that was inherited into RHEL and CentOS. See the change page for this https://fedoraproject.org/wiki/Features/ServicesPrivateTmp.
If you're really interested in learning every possible thing about systemd, you could of course go through the author's blog post series "systemd for administrators" — see http://0pointer.de/blog/projects/systemd-for-admins-1.html. It's pretty useful.
Or, if you're mostly interested in packaging something up to run in a nice way in the Fedora/RHEL/CentOS-ecosystem, the Fedora packaging guidelines for systemd might help; those are at http://fedoraproject.org/wiki/Packaging:Systemd. I notice that private temp dirs aren't mentioned there (not a bad thing to add, really) but you'll find some other advice that might be helpful. (Take a look at private devices and networking for a related issue.)
Mostly I'm interested in avoiding surprises and having code that isn't married to the weirdness of any particular version of any particular distribution. And I found this to be pretty surprising, given that I could see the file in /tmp and could read the code that was looking there. So, from the point of view of writing portable code, how should something handle this to run on any unix-like system?