[pca] Kernel Patch 142909-17

[Ron Halstead]

  David,

Me again. On my system (Nevada 129), there is no /etc/patch/pdo.conf, 
just  patch.conf and secret.conf.

Ron Halstead



On 10/11/10 03:28, Don O'Malley wrote:
> Hi David,
>
> Good point re: num_proc.
>
> The maximum recommended value for num_proc is 1.5 * <number of 
> processors on the system (i.e. output of psrinfo)>
>
> So, for example a T2000 with psrinfo like this:
> # psrinfo
> 0	on-line   since 07/13/2010 15:45:39
> 1	on-line   since 07/13/2010 15:45:40
> 2	on-line   since 07/13/2010 15:45:40
> 3	on-line   since 07/13/2010 15:45:40
> 4	on-line   since 07/13/2010 15:45:40
> 5	on-line   since 07/13/2010 15:45:40
> 6	on-line   since 07/13/2010 15:45:40
> 7	on-line   since 07/13/2010 15:45:40
> 8	on-line   since 07/13/2010 15:45:40
> 9	on-line   since 07/13/2010 15:45:40
> 10	on-line   since 07/13/2010 15:45:40
> 11	on-line   since 07/13/2010 15:45:40
> 12	on-line   since 07/13/2010 15:45:40
> 13	on-line   since 07/13/2010 15:45:40
> 14	on-line   since 07/13/2010 15:45:40
> 15	on-line   since 07/13/2010 15:45:40
> 16	on-line   since 07/13/2010 15:45:40
> 17	on-line   since 07/13/2010 15:45:40
> 18	on-line   since 07/13/2010 15:45:40
> 19	on-line   since 07/13/2010 15:45:40
> 20	on-line   since 07/13/2010 15:45:40
> 21	on-line   since 07/13/2010 15:45:40
> 22	on-line   since 07/13/2010 15:45:40
> 23	on-line   since 07/13/2010 15:45:40
> 24	on-line   since 07/13/2010 15:45:40
> 25	on-line   since 07/13/2010 15:45:40
> 26	on-line   since 07/13/2010 15:45:40
> 27	on-line   since 07/13/2010 15:45:40
> 28	on-line   since 07/13/2010 15:45:40
> 29	on-line   since 07/13/2010 15:45:40
> 30	on-line   since 07/13/2010 15:45:40
> 31	on-line   since 07/13/2010 15:45:40
> #
> could have a maximum value of num_proc=48
>
> Obviously, the correct setting for num_proc depends on the number of 
> zones you have on your system (there's no point in setting num_proc 
> higher than the number of zones you have).
>
> HTH,
> -Don
>
>
> French, David wrote:
>> I just wanted to point out that you can modify /etc/patch/pdo.conf and
>> set num_proc to something higher than the default of 1.  This will patch
>> num_proc zones in parallel when patchadd runs.  For example, if you have
>> many cpus and 10 zones, it shouldn't take much more time than twice what
>> it took to patch the global alone if you set the value to ten, as they
>> will all run in parallel.  I have a couple of T2000s with a global and 4
>> container zones.  The first (num_proc=1) took hours (4-5) to add about
>> 120 patches.  The other system I made sure the parameter above was set
>> to 5.  Patching on that server for the same 120 or so patches (identical
>> setups) took a little over an hour.  You can really see the difference
>> with the Java patches.
>>
>> BTW, the parameter is described in the patchadd man page, just search
>> for parallel.
>>
>> 	--Dave
>>
>>    
>>> -----Original Message-----
>>> From:pca-bounces at lists.univie.ac.at  [mailto:pca-
>>> bounces at lists.univie.ac.at] On Behalf Of Diana Orrick
>>> Sent: Saturday, October 09, 2010 3:41 PM
>>> To: PCA (Patch Check Advanced) Discussion
>>> Subject: Re: [pca] Kernel Patch 142909-17
>>>
>>>
>>>    Thanks for the suggestions everyone, will supply more info when time
>>> allows.
>>> Still working on the cluster...
>>>
>>> On 10/9/2010 6:18 PM, Rajiv Gunja wrote:
>>>      
>>>> You might want to compare the times it took for other patches so
>>>>        
>> that
>>    
>>>> you know if it will take longer that 13*11*x minutes whet x is some
>>>> random number which it seems to take for patching zones. If the
>>>>        
>>> server
>>>      
>>>> is ok to run for more time let it run. It took my server 7 hours to
>>>> patch 200 patches on a server with 3 zones. Sine you have 13 zones
>>>>        
>> it
>>    
>>>> might take longer.
>>>> -GGR
>>>>
>>>>        
>>>>> On Oct 9, 2010 12:17 PM, "Martin Paul"<martin at par.univie.ac.at
>>>>> <mailto:martin at par.univie.ac.at>>  wrote:
>>>>>
>>>>> Diana Orrick schrieb:
>>>>>
>>>>>
>>>>>          
>>>>>> Any suggestions on how to determine if the patching is
>>>>>>            
>> progressing
>>    
>>>>> at all?
>>>>>
>>>>> I guess you could use "truss -f -p<PID>" on the PID of the
>>>>> "patchadd" process to see what's going on.
>>>>>
>>>>> If you have to interrupt the patch installation process, the only
>>>>> "good" thing is that PCA is using plain patchadd for the patch
>>>>> install, so there's no extra uncertainty added by the fact that you
>>>>> are using PCA. On the other hand I don't have much practical
>>>>> experience about how "patchadd" reacts to Ctrl-C. I think that it
>>>>> should be pretty save to remove the partly installed patch with
>>>>> "patchrm" afterwards without causing any ill effects.
>>>>>
>>>>> Martin.
>>>>>
>>>>>
>>>>>          
>>> --
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>            Diana Mayer Orrick, System Administrator
>>>    Information Technology Services, Florida State University
>>>          Contact:orrick at fsu.edu    --   (850) 645-8009
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>      
>>
>>