ERROR cannot read info: lock timeout exceeded

[John Meinel]

I don't know the concrete details here, but I do believe there are a few
files that are shared in one JUJU_HOME. There is only one environments.yaml
and the new multi-environment code means there is another shared file that
holds the list of known servers and environments.
I would hope that the code would not hold the lock for the lifetime of the
process but only do a "grab the lock, read, update, write, release the
lock". But I don't know that code, so there might have been some other
thoughts there.

John
=:->
On Sep 25, 2015 5:44 PM, "Tim Van Steenburgh" <
tim.van.steenburgh at canonical.com> wrote:

>
> On Fri, Sep 25, 2015 at 9:56 AM, Curtis Hovey-Canonical <
> curtis at canonical.com> wrote:
>
>> On Fri, Sep 25, 2015 at 9:15 AM, Tim Van Steenburgh
>> <tim.van.steenburgh at canonical.com> wrote:
>> > Hi everyone,
>> >
>> > I have a jenkins slave that's running charm and bundle tests on 5
>> different
>> > clouds pretty much all the time. My problem is that tests will randomly
>> fail
>> > after hitting this lock timeout.
>>
>> Juju QA has pondered deleting any lock more than a minute old every
>> time we call the client to bootstrap or destroy-environment.
>>
>
> This is a good idea and probably worth doing, although it won't fix our
> most common
> failure, where a test run bootstraps successfully, but then fails later
> when *another*
> env bootstraps just before the running test tries to execute a juju
> command.
>
>
>>
>> > Is the best way around this to have a separate $JUJU_HOME for all my
>> test
>> > clouds, so that I end up with one lock per cloud? I haven't tried this
>> yet
>> > but it seems like the simplest way forward, if it works and is safe (is
>> > it?).
>>
>> Generating separate JUJU_HOMEs will insulate your from bug
>> https://bugs.launchpad.net/juju-core/+bug/1467331
>
>
> Thanks, I'm going to try this approach and see what happens. Although, it
> seems
> to me that if it's safe to have multiple JUJU_HOMEs, all "doing stuff"
> concurrently,
> it would also be possible to have one lock per env, instead of one global
> lock. Can
> anyone on the core team explain why there is one global lock? I'm just
> curious.
>
>
>>
>>
>>
>> --
>> Curtis Hovey
>> Canonical Cloud Development and Operations
>> http://launchpad.net/~sinzui
>>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150926/69f292fd/attachment.html>