Re: [pca] xref aged 1603 considered up to date?
Glen, 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. It's probably because PCA moves patchdiag.xref to patchdiag.xref.tmp before trying the download, so it has a backup copy if the download fails. (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.) Yes, looks like, after some googling. It does that for a similiar purpose - marking files which have been backuped for the nexte incremental backup. BTW, do you know PCA's -y, --nocheckxref option? It will make PCA skip the check for updates of the xref file. If you use it with a frozen patchdiag.xref file, everything should be fine. Martin.
Re: [pca] xref aged 1603 considered up to date?
Martin, BTW, do you know PCA's -y, --nocheckxref option? It will make PCA skip the check for updates of the xref file. If you use it with a frozen patchdiag.xref file, everything should be fine. I find both: --nocheckxref and --xrefdir very useful. Thanks, GlenG
Re: [pca] xref aged 1603 considered up to date?
Thanks for mentioning this. We're slowing getting rid of Solaris, but being able to snapshot a patchdiag.xref file with the patches, and not have to deal with it trying to look up a new one make our process very consistent. Ben On Mon, Nov 4, 2013 at 4:53 PM, Glen Gunselman gguns...@emporia.edu wrote: Martin, BTW, do you know PCA's -y, --nocheckxref option? It will make PCA skip the check for updates of the xref file. If you use it with a frozen patchdiag.xref file, everything should be fine. I find both: --nocheckxref and --xrefdir very useful. Thanks, GlenG
Re: [pca] xref aged 1603 considered up to date?
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] xref aged 1603 considered up to date?
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.)
[pca] xref aged 1603 considered up to date?
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. ex=0 1030 10:20:43 zoot ~ notme $sudo /var/tmp/pca -V --list 149668 --xrefdir=/var/tmp --patchdir=/var/tmp/pcatmp Option list: 1 Option patchdir: /var/tmp/pcatmp Option debug: 1 Command: /var/tmp/pca ARGV: 149668 Version: 20130502-01 CWD: /home/gunselmg Found /usr/sfw/bin/wget (1.12, 11200, https) Using /usr/sfw/bin/wget Found /usr/bin/uname Prerequisites for threads not met, setting threads to 0 Never update Expanded patch list: 149668 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 Local file /var/tmp/patchdiag.xref is up to date osname from uname: SunOS Reading from /usr/bin/showrev -p 2/dev/null patchdiag.xref size: 2241259 Using /var/tmp/patchdiag.xref from Dec/20/12 SUNWswmt patches: 108987 108988 110763 112951 114194 119254 119255 Host: zoot (SunOS 5.10/Generic_147440-25/sparc/sun4v) List: 149668 (1/356) Patch IR CR RSB Age Synopsis -- -- - -- --- --- --- 149668 -- 01 --- 356 VM Server for SPARC 2.2 ldmd patch ex=0 1030 10:21:06 zoot ~ notme $ Glen Gunselman
Re: [pca] xref aged 1603 considered up to date?
Are you running the LDOM manager (OVM 2.2) ? Ben On Wed, Oct 30, 2013 at 11:31 AM, Glen Gunselman gguns...@emporia.eduwrote: 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. ** ** ** ** ex=0 1030 10:20:43 zoot ~ notme $sudo /var/tmp/pca -V --list 149668 -- xrefdir=/var/tmp --patchdir=/var/tmp/pcatmp Option list: 1 Option patchdir: /var/tmp/pcatmp Option debug: 1 Command: /var/tmp/pca ARGV: 149668 Version: 20130502-01 CWD: /home/gunselmg Found /usr/sfw/bin/wget (1.12, 11200, https) Using /usr/sfw/bin/wget Found /usr/bin/uname Prerequisites for threads not met, setting threads to 0 Never update Expanded patch list: 149668 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 Local file /var/tmp/patchdiag.xref is up to date osname from uname: SunOS Reading from /usr/bin/showrev -p 2/dev/null patchdiag.xref size: 2241259 Using /var/tmp/patchdiag.xref from Dec/20/12 SUNWswmt patches: 108987 108988 110763 112951 114194 119254 119255 Host: zoot (SunOS 5.10/Generic_147440-25/sparc/sun4v) List: 149668 (1/356) ** ** Patch IR CR RSB Age Synopsis -- -- - -- --- --- --- 149668 -- 01 --- 356 VM Server for SPARC 2.2 ldmd patch ex=0 1030 10:21:06 zoot ~ notme $ ** ** ** ** ** ** Glen Gunselman
Re: [pca] xref aged 1603 considered up to date?
Yes, ldm --version Logical Domains Manager (v 2.2.0.0) Hypervisor control protocol v 1.7 Using Hypervisor MD v 1.0 System PROM: Hypervisor v. 1.10.7. @(#)Hypervisor 1.10.7.c 2012/09/07 15:35\015 OpenBootv. 4.33.6. @(#)OpenBoot 4.33.6.a 2012/03/29 11:22 Glen From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Ben Taylor Sent: Wednesday, October 30, 2013 10:47 AM To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] xref aged 1603 considered up to date? Are you running the LDOM manager (OVM 2.2) ? Ben On Wed, Oct 30, 2013 at 11:31 AM, Glen Gunselman gguns...@emporia.edumailto:gguns...@emporia.edu wrote: 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. ex=0 1030 10:20:43 zoot ~ notme $sudo /var/tmp/pca -V --list 149668 --xrefdir=/var/tmp --patchdir=/var/tmp/pcatmp Option list: 1 Option patchdir: /var/tmp/pcatmp Option debug: 1 Command: /var/tmp/pca ARGV: 149668 Version: 20130502-01tel:20130502-01 CWD: /home/gunselmg Found /usr/sfw/bin/wget (1.12, 11200, https) Using /usr/sfw/bin/wget Found /usr/bin/uname Prerequisites for threads not met, setting threads to 0 Never update Expanded patch list: 149668 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 Local file /var/tmp/patchdiag.xref is up to date osname from uname: SunOS Reading from /usr/bin/showrev -p 2/dev/null patchdiag.xref size: 2241259 Using /var/tmp/patchdiag.xref from Dec/20/12 SUNWswmt patches: 108987 108988 110763 112951 114194 119254 119255 Host: zoot (SunOS 5.10/Generic_147440-25/sparc/sun4v) List: 149668 (1/356) Patch IR CR RSB Age Synopsis -- -- - -- --- --- --- 149668 -- 01 --- 356 VM Server for SPARC 2.2 ldmd patch ex=0 1030 10:21:06 zoot ~ notme $ Glen Gunselman
