Re: [pca] xref aged 1603 considered up to date?

2013-10-31 Thread Martin Paul 

Glen,


This does not seem right to me.  Am I missing something? Isn't the number of 
days since last December less than 1603? I thought pca would download a new 
xref file if the one it found was over 1 day old.

xref mtime: Thu Dec 20 20:45:08 2012
xref now  : Wed Oct 30 10:20:58 2013
xref ctime: Wed Oct 30 09:54:15 2013
xref age  : 1603


The age here is the difference between xref now (the current time) 
and xref ctime (the file/inode change time) in seconds. If it's more 
than 3 hours (10800 seconds), pca will download the xref file. xref 
mtime is the original modification time of the xref file.


It's been a long time since I wrote that code, and I remember that it 
took me a long time to get this right. The goal was to ensure that PCA 
always works with a current xref file; it's not very efficient to 
download the xref on every PCA run, though.


Sun/Oracle updates the file once per day. In the beginning, I tried to 
find out the time of day the update happens and hard coded it into PCA, 
so it updated the xref file exactly once per day. That didn't always 
work, and things got complicated when Sun/Oracle wasn't the only source 
of the xref file anymore, after support for local proxy etc. was added.


I then made PCA maintain the original modification time of the xref 
file, as this is what's shown when doing an ls -l. It would have been 
very confusing, if PCA updated that timestamp. So I'm using the ctime as 
a marker which notes when PCA last tried to update the file. If it has 
done so in the last 3 hours, it does nothing. Otherwise it downloads the 
new xref file and then compares the timestamp in the file (header 
line), and only uses the fresh file if it's really new.


Like that, PCA usually gets the current xref file when I run it for the 
first time in the morning, but subsequent runs to download or install 
patches just use the file and don't re-download the file in the next 3 
hours.


Martin.

Re: [pca] a new R patch

2013-10-31 Thread Laurent Blume 

On 31/10/13 08:34, Martin Paul wrote:

Yes, there have always been special rules for patches for unbundled
software, like firmware, compilers, etc. ISTR that the shared library
for C++ was also considered a part of this group, maybe it's maintained
by the compiler team.


I can confirm that, there were several compiler patches released 
together with it, one of them regarding the same issue memory leak.



I also notice unusual updates of the date columns for some patches in
the past days, i.e. only the release date is changed to a patch in the
xref file, nothing else.


So did I. It seems there was some sort of respin, and one compiler patch 
added to the list as well.


Laurent

Re: [pca] xref aged 1603 considered up to date?

2013-10-31 Thread Glen Gunselman 

Martin,


 So I'm using the ctime as a marker which notes when PCA last tried to update 
 the file.

I think it is the tried part that got me.

If I have a normal routine, it is to save a patchdiag.xref file and use it for 
all the servers, but for some things - such as LU patches - I always want the 
current patchdiag.xref file.  

I have notes containing many pca commands with various options.  In this case I 
was copying and pasting commands and inadvertently picked one using the current 
xref file when I intended to use the saved file.  Of course I realized this 
when pca displayed Trying https ... and stopped it with cntl-c.  Also, this 
server requires explicit routes for Oracle (route add ...) and the IPs have 
changed since last December, so pca was not going to succeed anyway.

Using BASH's PS1='ex=$? \D{%m%d} \t \h \w \u \$' here's the console output:


ex=0 1030 09:46:16 notme ~ notme $sudo /var/tmp/pca --list 149668 
--xrefdir=/var/tmp --patchdir=/var/tmp/pcatmp
Downloading xref file to /var/tmp/patchdiag.xref
Trying Oracle
Trying https://getupdates.oracle.com/ (1/1)
^C
ERROR: Caught a SIGINT
ex=1 1030 09:54:15 notme ~ notme $

Based on the end time (09:54:15) and the ctime of /var/tmp/patchdiag.xref 
(09:54:15) if looks like the pca error processing may have resulted in the 
updating of ctime.

ls -lcE  /var/tmp/patchdiag.xref
-rw-rw-rw-   1 root root 2241259 2013-10-30 09:54:15.544509000 -0500 
/var/tmp/patchdiag.xref


Anyway, pca's debug option (-V) quickly revealed the problem with both the xref 
and the IPs I needed to add.

Thanks,
Glen Gunselman

(Note:  I checked the ctime for patchdiag.xref on several servers and it 
appears that NetBackup is causing ctime to be updated when the file is backed 
up.)