----- Original Message -----
> On Tue, 2012-11-20 at 23:01 -0500, Nathan Scott wrote:
> > Changes committed to git://oss.sgi.com/pcp/pcp.git dev
> >
> > ...
> >
> > commit 30912f0277d63c25035d79480ae508e77805bdc7
> > Author: Nathan Scott <nathans@xxxxxxxxxx>
> > Date: Wed Nov 21 14:53:10 2012 +1100
> >
> > Use new-world-order tmp dir scheme for deb packages too
>
> Why are we using --with-tmpdir=/var/lib/pcp/tmp in the package
> builds?
The initial patch for this arrived from David, so I'm going to
let him field this one too. :) My thinking below...
> I think the $PCP_TMP_DIR things all belong in /tmp or /var/tmp as per
> the historical status quo. I don't know of any other software that
> creates and deletes temporary files below /var/lib
>
There appear to be a few, e.g. MySQL does this ... googling finds
a few others.
And the official-looking:
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/var.html
says:
"...this hierarchy holds state information pertaining to an application or the
system.
State information is data that programs modify while they run, and that
pertains to
one specific host". ... which seems to cover it.
Certainly the description of /var/tmp (files that should exist even
after a reboot) does not cover our use of that.
My own thinking was along the lines "we need to create these dirs with
the correct permissions, in a race-free manner, unequivocally", and the
installation process seemed a good time. Since /var/tmp and /tmp are
also created explicitly by rpm/deb packages, it seemed a good option.
The one concern I (still) have is that these wont be automagically
cleaned up by the (optional) cron tmpdir sweepers ... while the main
PCP daemons tend to cleanup, I know of one library that does a very
ordinary job of cleaning up its own mmv turds. That said, tmpwatch
can be a pain and I've seen it clean up active mmv files for a very
long running process! Damned if you do and damned if you don't.
> ...
> Once this is understood/fixed, I can get back to my earlier problem
> where the non-root change causes additional problems for pmlogger
> where
> the symlink "primary" is unreadable for anyone other than the "pcp"
> user ... but more on that later when I get past the current directory
> mode obstacle.
Hmm, I wonder if those two problem are related. From an RPM point of
view, I've not observed this issue you're seeing, so hopefully with
the debian packaging fix from earlier today this will go away also.
> And all I wanted to do 3 days ago was QA some pmie "debug mode"
> changes ... sigh.
Ah well, its all for the greater good! ;) (much less exposed to
remote root exploits now)
cheers.
--
Nathan
|