Mercurial push locks

Simon King simon at simonking.org.uk
Mon Sep 29 20:36:55 UTC 2014 

On 29 Sep 2014, at 20:24, durwin at mgtsciences.com wrote:

> Regarding the hg-svnuser.  I just check it, and your right, it is a script.  I thought otherwise. 
> So I don't know if setting SUID helps. 
> 
> Durwin F. De La Rue
> Management Sciences, Inc.
> 6022 Constitution Ave. NE
> Albuquerque, NM  87110
> Phone (505) 255-8611 
> 
> Durwin De La Rue/Mgtsciences/US wrote on 09/29/2014 01:19:57 PM:
> 
> > From: Durwin De La Rue/Mgtsciences/US 
> > To: Simon King <simon at simonking.org.uk> 
> > Cc: Mercurial mailing list <mercurial at selenic.com>, Matt Mackall 
> > <mpm at selenic.com> 
> > Date: 09/29/2014 01:19 PM 
> > Subject: Re: Mercurial push locks 
> > 
> > Simon King <simon at simonking.org.uk> wrote on 09/29/2014 10:19:58 AM:
> > 
> > > From: Simon King <simon at simonking.org.uk> 
> > > To: Durwin De La Rue <durwin at mgtsciences.com> 
> > > Cc: Mercurial mailing list <mercurial at selenic.com>, Matt Mackall 
> > > <mpm at selenic.com> 
> > > Date: 09/29/2014 11:23 AM 
> > > Subject: Re: Mercurial push locks 
> > > 
> > > On Mon, Sep 29, 2014 at 4:41 PM,  <durwin at mgtsciences.com> wrote:
> > > > Simon King <simon at simonking.org.uk> wrote on 09/27/2014 03:14:15 PM:
> > > >
> > > >> From: Simon King <simon at simonking.org.uk>
> > > >> To: durwin at mgtsciences.com
> > > >> Cc: Matt Mackall <mpm at selenic.com>, Mercurial mailing list
> > > >> <mercurial at selenic.com>
> > > >> Date: 09/27/2014 03:14 PM
> > > >> Subject: Re: Mercurial push locks
> > > >>
> > > >> On 27 Sep 2014, at 00:16, durwin at mgtsciences.com wrote:
> > > >>
> > > >> > Matt Mackall <mpm at selenic.com> wrote on 09/26/2014 03:30:00 PM:
> > > >> >
> > > >> > > From: Matt Mackall <mpm at selenic.com>
> > > >> > > To: durwin at mgtsciences.com,
> > > >> > > Cc: Mercurial mailing list <mercurial at selenic.com>, Simon King
> > > >> > > <simon at simonking.org.uk>
> > > >> > > Date: 09/26/2014 03:30 PM
> > > >> > > Subject: Re: Mercurial push locks
> > > >> > >
> > > >> > > On Fri, 2014-09-26 at 11:19 -0600, durwin at mgtsciences.com wrote:
> > > >> > > > > > > With the introduction of phases (Mercurial 2.1, Feb 2012),
> > > >> > > > > > > pushes
> > > >> > > > may
> > > >> > > > > > > now acquire a lock on the sending side (so that it can update
> > > >> > > > > > > the
> > > >> > > > phase
> > > >> > > > > > > of local commits). Thus, you may get a deadlock if you
> > > >> push inside a
> > > >> > > > > > > hook where a lock is already held.
> > > >> > > > > >
> > > >> > > > > > This appears to what is occurring.  Is there a way around this?
> > > >> > > > > > I
> > > >> > > > need to
> > > >> > > > > > perform a push
> > > >> > > > > > to the other repository after each push to either.  ShouldI
> > > >> > > > > > change
> > > >> > > > this
> > > >> > > > > > to a script and
> > > >> > > > > > run it in an 'at' job delayed a minute?
> > > >> > > > >
> > > >> > > > > What version of Mercurial are you running on the server?
> > > >> > > >
> > > >> > > > Mercurial version 2.6.3
> > > >> > >
> > > >> > > Hmmm, shouldn't be a problem here: the changegroup hook is run
> > > >> > > immediately after lock release.
> > > >> > >
> > > >> > > Perhaps you can create a minimal model of your flow:
> > > >> > >
> > > >> > > $ hg init local
> > > >> > > $ hg init server1
> > > >> > > # add push hook
> > > >> > > $ hg init server2
> > > >> > >
> > > >> > > ..and see if you can get it to lock.
> > > >> >
> > > >> > I do have a 'test' repository where all I have are two files.  The
> > > >> hook always works for me.  In fact the project repository all ways
> > > >> works for me.  There was a time where I would see the lock, but that
> > > >> is no longer occurring.  I tried logging into server as one of the
> > > >> users having the problem and cloned their repository, but it would
> > > >> not lock up, it pushed just fine.
> > > >> >
> > > >>
> > > >> I’m not sure I understand your setup here. Based on your earlier
> > > >> emails you say you have:
> > > >>
> > > >> Local machine
> > > >>   -> push to ssh://server//home/svnuser/project-hg/WebApplication
> > > >>     -> changegroup hook pushing to
> > > >> /home/svnuser/project-hg/WebApplication/
> > > >>
> > > >> This doesn’t appear to make any sense (changegroup hook pushing to
> > > >> the current repository), so perhaps you’ve changed the paths and
> > > >> they’re not really like this.
> > > >>
> > > >> For the first push, I assume that each user has their own account on
> > > >> the server, but file permissions are set up such that they all have
> > > >> write privileges on the first server-side repo. This is a potential
> > > >> source of problems if the users don’t have appropriate umask and
> > > >> group settings, as one user could create files that can’t be updated
> > > >> by other users.
> > > >>
> > > >> The hook then uses sudo to run the second push as the user
> > > >> “svnuser”, and it calls a program called “hg-svnuser”. This raises a
> > > >> couple more questions:
> > > >
> > > >
> > > > I have 2 servers, each with a clone of the project.  Webuser works off
> > > > ServerA,
> > > > while the rest work off ServerB.  When a push is done to ServerB, it must
> > > > then
> > > > push to ServerA.  I copied hg executable to hg-svnuser then set the SUID
> > > > and the user to 'svnuser' with the intent on getting consistent 
> > properties.
> > > > Every user is in the 'svnuser' sudo group with NOPASSWD defined for
> > > > hg-svnuser executable.
> > > 
> > > If that works for you, that's fine. An alternative approach is to put
> > > ssh keys for each of your users in the authorized_keys file for
> > > svnuser, then have everyone push using that account. Because all
> > > operations on the server are then run as svnuser, all your permissions
> > > should be consistent, and there would be no need for sudo, or the
> > > separate SUID script). This approach is described at
> > > http://mercurial.selenic.com/wiki/SharedSSH (hg-ssh) and
> > > https://sites.google.com/site/ucdcsssg/announcements/
> > > howtocollaborateusingmercurialwithhg-ssh. 
> > 
> > This I already tried with one user.  It still locked. 
> > 
> > > 
> > > (Does making "hg-svnuser" SUID actually work? I thought that wasn't
> > > generally possible for scripts) 
> > 
> > I just copied the executable (did not want to break anything for normal 'hg') 
> > and set the SUID. 
> > 
> > > 
> > > >
> > > >>
> > > >> 1. Do all users have the same sudo privileges? Perhaps the blocking
> > > >> happens because sudo is trying to prompt for a password in some cases?
> > > >>
> > > >> 2. Is “hg-svnuser” a different installation of mercurial than the
> > > >> one invoked as part of the “initial” push? If so, have you checked
> > > >> the version numbers of both installations?
> > > >>
> > > >> I don’t know what you mean when you say you logged into the server
> > > >> as a different user and cloned their repository - perhaps you could
> > > >> explain those steps in detail.
> > > >
> > > > I had logged into one users login on ServerB to see if I can duplicate
> > > > problem.
> > > >
> > > > $ ssh user1 at serverb
> > > > $ hg clone ssh://serverb//home/svnuser/project/ project/
> > > >
> > > 
> > > I see. The permissions on the "local" clone (that one that initiates
> > > the original push) are unlikely to be relevant - I think you could
> > > done a similar test by pushing from your own clone, but specifying the
> > > other user's account in the ssh url. ie.
> > > 
> > >   hg push ssh://user1@serverb//home/svnuser/project 
> > 
> > I'll have to keep this in mind. 
> > 
> > > 
> > > > Then make an edit, commit, then push.
> > > >
> > > > None of the users are actually working *on* the server.  They are using
> > > > Windows,
> > > > most using Netbeans, one using Cygwin.
> > > >
> > > > I even had one create a new clone, but still had lockups.
> > > >
> > > > I did remove the hook for testing and there was no lockups.
> > > > I am trying to recode hook to perform a push to other server *after* user
> > > > has
> > > > competed (using at).
> > > >
> > > 
> > > I still feel that your problem is permission-related, in which case
> > > changing the time at which the secondary push happens won't fix the
> > > problem. You may find that your "at" job hangs instead, and if it
> > > locks the repository, you will only find out when the *next* person
> > > tries to push and can't... 
> > 
> > I have repeatedly checked and reset user name, group name, and permissions. 
> > I also had one user create a clone authenticating as 'svnuser', yet it 
> > still locked during push.  I will watch even more closely at the permissions 
> > after a push.  Maybe I am missing something. 
> > 
> > Durwin 
> > 

OK, another experiment might be in order here. The default timeout that hg will wait for a lock for is 10 minutes (the ui.timeout parameter http://www.selenic.com/mercurial/hgrc.5.html#ui). To find out whether the “hang” is actually mercurial’s default locking mechanism, you could try lowering that timeout to just a few seconds. You probably ought to do so on *both* server repositories. Hopefully, when you try to push, it will block, but only for a few seconds, and then if we’re lucky you’ll see an error message about failing to acquire the lock.

*If* all of that happens, you might be able to use the solution I posted here:

  http://www.selenic.com/pipermail/mercurial/2013-November/046176.html

Hope that helps,

Simon

More information about the Mercurial mailing list