Jira (PUP-1150) Race condition in Puppet::Util::Lockfile

2014-01-27 Thread Glenn Pratt (JIRA)
Title: Message Title










 

 Glenn Pratt commented on an issue


















  Re: Race condition in Puppet::Util::Lockfile 










I wouldn't imagine the output showing different configurations unless something is also updating configurations on the master.












   

 Add Comment

























 Puppet /  PUP-1150



  Race condition in Puppet::Util::Lockfile 







 Puppet::Util::Lockfile does not exclude other processes from acquiring a lock between the time it checks if the lock file exists and when it writes to the lock file. This allows for a race condition, and two puppet processes started simultaneously are likely to acquire the same lock.   This has been witnessed in the wild where I work because we may have...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.


Jira (PUP-1230) Windows process helper that can be used instead of Ruby fork

2014-01-15 Thread Glenn Pratt (JIRA)
Title: Message Title










 

 Glenn Pratt commented on an issue


















  Re: Windows process helper that can be used instead of Ruby fork 










Checkout what rails does:
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/testing/isolation.rb












   

 Add Comment

























 Puppet /  PUP-1230



  Windows process helper that can be used instead of Ruby fork 







 There are a number of tests that fork to simulate contention behavior. On Windows however, we punt on these since Ruby's fork is unsupported on Windows.   Ruby 1.9.3 added `spawn`, and while this is not the same thing as `fork`, in instances where we need to simulate file locking behavior for the sake of tests, this might be a reasonable substitute.  ...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit 

Jira (PUP-1150) Race condition in Puppet::Util::Lockfile

2014-01-14 Thread Glenn Pratt (JIRA)
Title: Message Title










 

 Glenn Pratt commented on an issue


















  Re: Race condition in Puppet::Util::Lockfile 










I left the call to locked? in speficically because of the spec lockfile_spec.rb. Not for any technical reason. I'm happy to remove that spec.
I came up with the 2 forks 5 times pattern running it on Linux and Mac machines available to me - happy to change but I should probably verify 10 x 1 replicates it reliably.
Just noticed a bug while looking at how this is done elsewhere:
https://github.com/puppetlabs/puppet/blob/master/spec/unit/file_system/file_spec.rb#L802
I believe 5 should be num_procs.












   

 Add Comment

























 Puppet /  PUP-1150



  Race condition in Puppet::Util::Lockfile 







 Puppet::Util::Lockfile does not exclude other processes from acquiring a lock between the time it checks if the lock file exists and when it writes to the lock file. This allows for a race condition, and two puppet processes started simultaneously are likely to acquire the same lock.   This has been witnessed in the wild where I work because we may have...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 




  

Jira (PUP-1150) Race condition in Puppet::Util::Lockfile

2014-01-10 Thread Glenn Pratt (JIRA)
Title: Message Title










 

 Glenn Pratt commented on an issue


















  Re: Race condition in Puppet::Util::Lockfile 










Joshua Partlow updated the PR with the filesystem changes.












   

 Add Comment

























 Puppet /  PUP-1150



  Race condition in Puppet::Util::Lockfile 







 Puppet::Util::Lockfile does not exclude other processes from acquiring a lock between the time it checks if the lock file exists and when it writes to the lock file. This allows for a race condition, and two puppet processes started simultaneously are likely to acquire the same lock.   This has been witnessed in the wild where I work because we may have...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.


Jira (PUP-1150) Race condition in Puppet::Util::Lockfile

2013-12-17 Thread Glenn Pratt (JIRA)
Title: Message Title










 

 Glenn Pratt created an issue


















 Puppet /  PUP-1150



  Race condition in Puppet::Util::Lockfile 










Issue Type:

  Bug




Affects Versions:


 3.3.3, 3.4.0, 4.0.0




Assignee:


 Unassigned




Created:


 17/Dec/13 12:13 PM




Labels:


 puppet-agent




Priority:

  Normal




Reporter:

 Glenn Pratt










Puppet::Util::Lockfile does not exclude other processes from acquiring a lock between the time it checks if the lock file exists and when it writes to the lock file. This allows for a race condition, and two puppet processes started simultaneously are likely to acquire the same lock.
This has been witnessed in the wild where I work because we may have multiple request that trigger puppet runs on certain nodes. Here's an example:



Dec 11 05:41:46 ded-4 puppet-agent[20075]: Retrieving plugin
Dec 11 05:41:46 ded-4 puppet-agent[20076]: Retrieving plugin
Dec 11 05:41:46 ded-4 puppet-agent[20076]: Loading facts in /var/lib/puppet/lib/facter/installed_gems.rb
Dec 11 05:41:46 ded-4 puppet-agent[20075]: Loading facts in /var/lib/puppet/lib/facter/installed_gems.rb
Dec 11 05:41:46 ded-4 puppet-agent[20076]: Loading facts in /var/lib/puppet/facts/ah_custom_facts.rb
Dec 11 05:41:46 ded-4 puppet-agent[20075]: Loading facts in /var/lib/puppet/facts/ah_custom_facts.rb
Dec 11 05:42:01