Mercurial push locks
durwin at mgtsciences.com
durwin at mgtsciences.com
Mon Sep 29 19:24:42 UTC 2014
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
>
> >
> > Did you look at the file permissions and ownership in the 2
> > repositories, particularly in the .hg/cache directory?
> >
> > Simon
>
>
>
> This email message and any attachments are for the sole use of the
> intended recipient(s) and may contain proprietary and/or
> confidential information which may be privileged or otherwise
> protected from disclosure. Any unauthorized review, use, disclosure
> or distribution is prohibited. If you are not the intended recipient
> (s), please contact the sender by reply email and destroy the
> original message and any copies of the message as well as any
> attachments to the original message.
This email message and any attachments are for the sole use of the
intended recipient(s) and may contain proprietary and/or confidential
information which may be privileged or otherwise protected from
disclosure. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient(s), please contact the
sender by reply email and destroy the original message and any copies of
the message as well as any attachments to the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140929/83863335/attachment-0002.html>
More information about the Mercurial
mailing list