pcp
[Top] [All Lists]

Re: That pmie tmpdir QA fallout change

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: That pmie tmpdir QA fallout change
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 19 Feb 2014 08:18:09 +1100
Cc: PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1958567240.10287297.1392754302864.JavaMail.zimbra@xxxxxxxxxx>
References: <1958567240.10287297.1392754302864.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
On 19/02/14 07:11, Nathan Scott wrote:
Hi Ken,

I'm puzzled by the need for the change below, as I've not been
seeing this message (and hence, no QA fallout for me).  What
was the full error message string you saw here?  (or errno?)
Is it EPERM?  EACCESS?  The idea was that pmie would quietly
continue on its way in these situations, without exporting the
stats file - just want to make sure we are doing that right.
(ie perhaps we need to check for errnos in addition to EEXIST,
which appears to be doing the trick for me but not for you?).

Thanks Nathan for spotting this.

The code change may have been premature.

I discovered the root cause later (thanks to qa/994 which we should try and clone with a small sequence number so it gets run early and late), namely /var/lib/pcp/tmp/pmie is removed and/or had its mode changed to 755 (not 775 as installed).

This has been a lurking problem for me for sometime, and I cannot isolate the qa (or other!) malevolent pixie that is smacking the sometime after a package install.

I've reverted commit a5aa0cc8 in my tree, and rerun the -g pmie qa group which passes up to qa/515, so this reversion will be in my next batch of pushed commits and I'll track down who's really smacking this directory in the qa environment.

<Prev in Thread] Current Thread [Next in Thread>