Age | Commit message (Collapse) | Author | Files | Lines |
|
Before this commit, Puppet::Util::Lockfile.lock called the locked?
method before opening the @lockfile for write. Checking that the file
doesn't exist and creating the file were not an atomic operation, which
allowed two processes to detect that the file didn't exist and open it
for write simultaneously.
This commit adds and used Puppet::FileSystem::exclusive_create wrapper
that sets the following options:
* File:CREAT - Creates the file if it doesn't exist.
* File:EXCL - Fails if the file does exist.
* File:WRONLY - Opens the file for write only.
File:EXCL is the important option, callers will recieve an Exception if
the file exists, meaning another process has acquired the lock. If the
file doesn't exist it will be created atomically, so other another
caller cannot create the file in the gap.
|
|
|
|
- All previous File and FileTest calls to exist? or exists? go through
the new FileSystem::File abstraction so that the implementation can
later be swapped for a Windows specific one to support symlinks
|
|
Without this patch Ruby 1.9 is still complaining loudly about trying to
parse the spec files. The previous attempt to clean up this problem in
edc3ddf works for Ruby 1.8 but not 1.9.
I'd prefer to remove the shebang lines entirely, but doing so will cause
encoding errors in Ruby 1.9. This patch strives for a happy middle
ground of convincing Ruby it is actually working with Ruby while not
confusing it to think it should exec() to rspec.
This patch is the result of the following command run against the source
tree:
find spec -type f -print0 | \
xargs -0 perl -pl -i -e 's,^\#\!\s?/(.*)rspec,\#! /usr/bin/env ruby,'
|
|
Without this patch some spec files are using `ruby -S rspec` and others
are using `rspec`.
We should standardize on a single form of the interpreter used for spec
files.
`ruby -S rspec` is the best choice because it correctly informs editors
such as Vim with Syntastic that the file is a Ruby file rather than an
Rspec file.
|
|
|
|
This commit does the following:
1. Refactors our main lockfile class to accept a data object
as an argument to the #lock method. This data can
then be retrieved at any time while the lock is held;
the implementation is to write the hash as JSON to
the lockfile. This will allow external tools to
read it without calling into puppet code.
2. Refactor pidlock to use the above--but only serializing
a String (the pid) to the file.
3. Refactor disabler to use the above, with a Hash containing
a key/value pair identifying the "disabled" message.
4. Fix and clean up spec tests.
|