Ah, I did not know that. Thanks for the tip! I've made and committed
that change.
- Jamis
On 6/26/07, Adrian B. Danieli <[EMAIL PROTECTED]> wrote:
>
> Great, just saw the change. You probably want to use a Monitor instead
> of a Mutex though, as Monitors are reentrant.
>
> For example, this will fail:
>
> set(:foo) { fetch :user }
> fetch :foo
>
> Cheers,
> Adrian
>
>
> On Jun 25, 10:12 pm, "Jamis Buck" <[EMAIL PROTECTED]> wrote:
> > Ah, I see it now. That's fixed now, too. :) Thanks!
> >
> > - Jamis
> >
> > On 6/25/07, Adrian B. Danieli <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > Hi Jamis,
> >
> > > I tried the capistrano-1.99.2.7114.gem you uploaded this morning, but
> > > it doesn't solve the threading issue I am encountering. :( Same for
> > > trunk rev 7126...
> >
> > > You can replicate the problem like this:
> > > $ ssh-add -l
> > > The agent has no identities.
> > > $ cap HOSTS="server1,server2" COMMAND="uptime" invoke
> > > * executing `invoke'
> > > * executing "uptime"
> > > servers: ["server1", "server2"]
> > > Password: Password:
> >
> > > Applying the patch works for me.
> >
> > > Adrian ---- -- -
> >
> > > On Jun 25, 6:53 pm, "Jamis Buck" <[EMAIL PROTECTED]> wrote:
> > > > Thanks, Adrian. This has indeed been fixed in trunk. I've uploaded a
> > > > new gem to this mailing list (you can download it by going
> > > > tohttp://groups.google.com/group/capistranoandfinding the files
> > > > section).
> >
> > > > - Jamis
> >
> > > > On 6/25/07, Adrian Danieli <[EMAIL PROTECTED]> wrote:
> >
> > > > > Greetings,
> >
> > > > > Not sure if this has been recently addressed, but password-based
> > > > > authentication against multiple hosts doesn't work correctly in the
> > > > > latest beta gem.
> >
> > > > > I believe it has to do with the recent change to
> > > > > Capistrano::Configuration::Connections establish_connections_to
> > > > > method. It attempts to do them all in parallel now -- and you get
> > > > > prompted for the login password for each concurrently. One host gets
> > > > > the correct password, the others don't.
> >
> > > > > Simple workarounds are to pass "-p" to cap so it immediately prompts
> > > > > for the password, set the password explicitly in your configuration
> > > > > file, or use public keys.
> >
> > > > > I think this can be fixed by modifying Capistrano::Variables.fetch to
> > > > > synchronize around the code that attempts to cache the result of the
> > > > > block (in this case the call to password_prompt). I'm submitting a
> > > > > patch for lib/capistrano/configuration/variables.rb.
> >
> > > > > Cheers,
> > > > > Adrian
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
