On 16.04.2015 04:15, Les Mikesell wrote: > On Wed, Apr 15, 2015 at 9:00 PM, John R Pierce <pierce at hogranch.com> wrote: >> On 4/15/2015 6:52 PM, Les Mikesell wrote: >>> >>> 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? >> >> >> you sure this had nothing to do with selinux not letting perl running as the >> http user write there? >> > > No, systemd actually remaps /tmp from apache - and apparently most > other daemons - to private directories below /tmp with configs as > shipped. The command line tool wrote the file to /tmp as expected. > The perl code running under httpd reading what it thought was /tmp was > actually looking under /tmp/systemd-private-something. I'm beginning > to see why so much of EPEL isn't included in epel7 yet. The issue here really isn't systemd or the PrivateTmp feature but the fact that some applications don't properly distinguish between temporary files and data files. Temporary files are files the application generates temporarily for internal processing and that are not to be touched by anybody else. If as in the twiki backup case the files generated are to be used by somebody else after twiki is done generating them then these are regular data files and not temporary files. The application should have a configuration option to set its data directory and it should default to /var/lib/<application-name>. In cases where this option is not available and the application "abuses" the tmp directory as data directory there is probably no other option than to the set PrivateTmp=false in the service file. Regards, Dennis