pcp
[Top] [All Lists]

Re: [pcp] pcp updates - porting to NetBSD

To: kenj@xxxxxxxxxxxxxxxx
Subject: Re: [pcp] pcp updates - porting to NetBSD
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Fri, 22 Feb 2013 03:28:05 -0500 (EST)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1361512296.15056.18.camel@bozo-laptop>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>

----- Original Message -----
> Thanks for the feedbakc Nathan.
> 

No worries.  Just got through a QA run with those changes (and
others), and this failure below may be some unintended fallout
of those mkstemp / tempdir changes just made?

[73%] 448 0s ... - output mismatch (see 448.out.bad)
7a8,9
> getconfig: vpmprintf: failed to create "/pcp-piYj5S": Permission denied
> vpmprintf msg:
12a15,16
> getconfig: vpmprintf: failed to create "/pcp-SdS4QT": Permission denied
> vpmprintf msg:

Looks like something is not being set... ah this is the "bad $PCP_DIR"
case.  I think what may have happened is previously we were going down
the tempnam(3) path, which when passed NULL as its first argument uses
the system TMPDIR.  We probably need a hard-coded fail-safe like this
for such a pathological case...

diff --git a/src/libpcp/src/util.c b/src/libpcp/src/util.c
index a92f98c..6f07b13 100644
--- a/src/libpcp/src/util.c
+++ b/src/libpcp/src/util.c
@@ -1091,9 +1091,10 @@ vpmprintf(const char *msg, va_list arg)
        int     fd = -1;
 
 #if HAVE_MKSTEMP
+       char *tmpdir = pmGetConfig("PCP_TMP_DIR");
        fname = (char *)malloc(MAXPATHLEN+1);
        if (fname == NULL) goto fail;
-       snprintf(fname, MAXPATHLEN, "%s/pcp-XXXXXX", pmGetConfig("PCP_TMP_DIR"))
+       snprintf(fname, MAXPATHLEN, "%s/pcp-XXXXXX", tmpdir ? tmpdir : "/tmp"));
        fd = mkstemp(fname);
 #else
        fname = tempnam(pmGetConfig("PCP_TMP_DIR"), "pcp-");
> > Heh.  Looks like "real" kernels prefer /dev/kmem readers too.  :)
> 
> Hmm ... now I am pretty sure I wrote my first /dev/kmem reader code
> for
> Sixth Edition Unix in 1976 ... no reason to believe something that
> worked 37 years ago would not still work ... 8^)> (let's see how Java
> and Python are making out in 30+ years ... I'll need you to check on
> that, 'cause I won't be here).

:^)

cheers.

--
Nathan

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