On Friday, May 23, 2014 9:01:26 PM UTC-5, Matt W wrote:
>
> When you have hundreds of hosts and run Puppet every 30 mins (splayed 
> across the hour), it seems that you end up running into various 'dpkg' 
> locks fairly randomly and at a surprisingly high occurrence (once or twice 
> a day at least). This happens if you do something simple like a cron-based 
> 'apt-get update' or 'apt-get autoclean'. It happens even more often, oddly, 
> when you tell Puppet to always install Package-Foo, and you manually run 
> jobs across the farms occasionally to upgrade Package-Foo.
>


If you manage the same resources via two different, independent mechanisms, 
then it is likely that from time to time those mechanisms will interfere 
with one another.  In this case "the same resources" means the same type of 
resources, not necessarily the same individual resources, because the dpkg 
lock couples all dpkg packages together.

How many conflicts you have per unit time depends on the number of 
machines, on the frequency and schedule of each mechanism, and on the 
temporal cross section for collision.  I don't know about dpkg, but yum can 
have a rather large cross section, at least when it makes any changes.  It 
varies depending on which plugins are installed.

If you have hundreds of machines or if dpkg frequently has updates to 
install then I have no trouble believing that you get several occurrences 
per day.
 

>
> Is there any way to tell Puppet to wait and then re-try when theres a dpkg 
> lock in place, rather than outright failing? Overall its just a nuisance, 
> but we must get 3-5 of these reports a day..
>
>

Details of applying resources of most types are managed by 'providers' 
associated with those types, so, as Jakov says, the dpkg package provider 
is the place to look.  You could modify the existing one or write your own, 
possibly a simple derivative of the existing one.  If you write a new 
provider then you will probably need to assign it explicitly to your 
packages via their 'provider' parameter.  If you modify the existing 
provider then you may need to arrange to distribute that to all your 
agents.  (A custom provider can be distributed via plugin sync, but I'm 
doubtful whether the same applies to a modified core component.)


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d76dbec2-4b2b-45e2-97c7-c8ff575f8157%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to