You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Doug Robinson <do...@wandisco.com> on 2017/03/02 13:19:04 UTC

Suspected issue with "remove-zombie-locks.py"?

Folks:

The following commands were run on a CentOS 6.x, WANdisco Subversion 1.9.5,
Python 2.7:
--------------------------------------------------------------------------------------
# svn export https://svn.apache.org/repos/asf/subversion/trunk/
contrib/hook-scripts
# svnadmin create repo
# svn co file:///path/to/repo wc
# cd wc
# touch wc/a; svn add wc/a; svn ci -mm wc
# svn lock wc/a; svn rm wc/a; svn ci -mm --no-unlock wc
# hook-scripts/remove-zombie-locks.py repo1 all

Removing all zombie locks from repository at /root/repo

This may take several minutes...

/a

Traceback (most recent call last):

  File "hook-scripts/remove-zombie-locks.py", line 214, in <module>

    main()

  File "hook-scripts/remove-zombie-locks.py", line 208, in main

    remover.run()

  File "hook-scripts/remove-zombie-locks.py", line 138, in run

    self.unlock_nonexistent_files, self.pool)

  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/libsvn/fs.py",
line 860, in svn_fs_get_locks2

    return _fs.svn_fs_get_locks2(*args)

svn.core.SubversionException: 160034 - No username is currently associated
with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'

--------------------------------------------------------------------------------------


Is this a known issue?  Or should I file a bug?


Thank you.


Doug
-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robinson@wandisco.com

*www.wandisco.com <http://www.wandisco.com/>*

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>

Listed on the London Stock Exchange: WAND 
<http://www.bloomberg.com/quote/WAND:LN>

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Suspected issue with "remove-zombie-locks.py"?

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Mon, Mar 06, 2017 at 17:22:14 +0100:
> On Mon, Mar 06, 2017 at 04:06:44PM +0000, Daniel Shahaf wrote:
> > I can reproduce this using the FS API only (without the contrib/ script):
> 
> Hmm, looks like the contrib script is using the API wrong.
> Check out what 'svnadmin unlock' does:
> [[[
>   /* Open the repos/FS, and associate an access context containing
>      USERNAME. */
>   SVN_ERR(open_repos(&repos, opt_state->repository_path, opt_state, pool));
>   fs = svn_repos_fs(repos);
>   SVN_ERR(svn_fs_create_access(&access, username, pool));
>   SVN_ERR(svn_fs_set_access(fs, access));
> 
>   SVN_ERR(svn_utf_cstring_to_utf8(&lock_path_utf8, lock_path, pool));
>   if (opt_state->bypass_hooks)
>     SVN_ERR(svn_fs_unlock(fs, lock_path_utf8, lock_token,
>                           FALSE, pool));
>   else
>     SVN_ERR(svn_repos_fs_unlock(repos, lock_path_utf8, lock_token,
>                                 FALSE, pool));
> ]]]
> 
> The script should probably be doing something like this, too.

I don't think so.  The documentation of svn_fs_unlock() points to
the documentation of svn_fs_unlock_many(), which states:

 * If @a fs has no username associated with it, yield an
 * #SVN_ERR_FS_NO_USER (E160034) unless @a break_lock is specified.

The reproductions pass break_lock=True, so shouldn't get that error.

Cheers,

Daniel

> Doug, I believe filing a bug is entirely appropriate here. Thanks!

Re: Suspected issue with "remove-zombie-locks.py"?

Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 06, 2017 at 05:22:14PM +0100, Stefan Sperling wrote:
> On Mon, Mar 06, 2017 at 04:06:44PM +0000, Daniel Shahaf wrote:
> > I can reproduce this using the FS API only (without the contrib/ script):
> 
> Hmm, looks like the contrib script is using the API wrong.
> Check out what 'svnadmin unlock' does:
> [[[
>   /* Open the repos/FS, and associate an access context containing
>      USERNAME. */
>   SVN_ERR(open_repos(&repos, opt_state->repository_path, opt_state, pool));
>   fs = svn_repos_fs(repos);
>   SVN_ERR(svn_fs_create_access(&access, username, pool));
>   SVN_ERR(svn_fs_set_access(fs, access));
> 
>   SVN_ERR(svn_utf_cstring_to_utf8(&lock_path_utf8, lock_path, pool));
>   if (opt_state->bypass_hooks)
>     SVN_ERR(svn_fs_unlock(fs, lock_path_utf8, lock_token,
>                           FALSE, pool));
>   else
>     SVN_ERR(svn_repos_fs_unlock(repos, lock_path_utf8, lock_token,
>                                 FALSE, pool));
> ]]]
> 
> The script should probably be doing something like this, too.

This problem with 'svnadmin load' might also be caused by wrong use
of the API: https://issues.apache.org/jira/browse/SVN-4030
I have not checked the details, though. But if anybody is fixing the script,
consider taking a look at issue #4030 as well while the context is fresh.

Re: Suspected issue with "remove-zombie-locks.py"?

Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 06, 2017 at 04:06:44PM +0000, Daniel Shahaf wrote:
> I can reproduce this using the FS API only (without the contrib/ script):

Hmm, looks like the contrib script is using the API wrong.
Check out what 'svnadmin unlock' does:
[[[
  /* Open the repos/FS, and associate an access context containing
     USERNAME. */
  SVN_ERR(open_repos(&repos, opt_state->repository_path, opt_state, pool));
  fs = svn_repos_fs(repos);
  SVN_ERR(svn_fs_create_access(&access, username, pool));
  SVN_ERR(svn_fs_set_access(fs, access));

  SVN_ERR(svn_utf_cstring_to_utf8(&lock_path_utf8, lock_path, pool));
  if (opt_state->bypass_hooks)
    SVN_ERR(svn_fs_unlock(fs, lock_path_utf8, lock_token,
                          FALSE, pool));
  else
    SVN_ERR(svn_repos_fs_unlock(repos, lock_path_utf8, lock_token,
                                FALSE, pool));
]]]

The script should probably be doing something like this, too.

Doug, I believe filing a bug is entirely appropriate here. Thanks!

Re: Suspected issue with "remove-zombie-locks.py"?

Posted by Doug Robinson <do...@wandisco.com>.
Daniel:

https://issues.apache.org/jira/browse/SVN-4674

Thank you.

Doug

On Mon, Mar 6, 2017 at 11:06 AM, Daniel Shahaf <d....@daniel.shahaf.name>
wrote:

> Doug Robinson wrote on Mon, Mar 06, 2017 at 10:15:04 -0500:
> >
> > Doug Robinson <do...@wandisco.com> wrote:
> > > Traceback (most recent call last):
> > >
> > >   File "hook-scripts/remove-zombie-locks.py", line 214, in <module>
> > >
> > >     main()
> > >
> > >   File "hook-scripts/remove-zombie-locks.py", line 208, in main
> > >
> > >     remover.run()
> > >
> > >   File "hook-scripts/remove-zombie-locks.py", line 138, in run
> > >
> > >     self.unlock_nonexistent_files, self.pool)
> > >
> > >   File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/
> libsvn/fs.py",
> > > line 860, in svn_fs_get_locks2
> > >
> > >     return _fs.svn_fs_get_locks2(*args)
> > >
> > > svn.core.SubversionException: 160034 - No username is currently
> associated
> > > with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'
>
> I can reproduce this using the FS API only (without the contrib/ script):
>
> % python2
> >>> from svn.core import *
> >>> from svn.fs import *
> >>> from __future__ import print_function
> >>> fs = svn_fs_open("r/db", None)
> >>> svn_fs_get_locks2(fs, "", svn_depth_infinity, print)
> <libsvn.core.svn_lock_t; proxy of <Swig Object of type 'svn_lock_t *' at
> 0x7f4d83bb9660> > <libsvn.core.apr_pool_t; proxy of <Swig Object of type
> 'apr_pool_t *' at 0x7f4d83bb96c0> >
> >>> svn_fs_get_locks2(fs, "", svn_depth_infinity, (lambda lock, pool:
> svn_fs_unlock(fs, lock.path, lock.token, True, pool)))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/usr/lib/python2.7/dist-packages/libsvn/fs.py", line 876, in
> svn_fs_get_locks2
>     return _fs.svn_fs_get_locks2(*args)
> svn.core.SubversionException: 160034 - No username is currently associated
> with filesystem 'a1257b00-ab15-4056-8430-3a7080d0ccfe'
>
> > I realize that the SHA1-collision issues are consuming most of the duty
> > cycles at this point.  Before I forget about this one - should I file a
> bug?
>
> Yes, please.
>
> Thanks,
>
> Daniel
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robinson@wandisco.com

*www.wandisco.com <http://www.wandisco.com/>*

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>

Listed on the London Stock Exchange: WAND 
<http://www.bloomberg.com/quote/WAND:LN>

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

'svn lock -q' (was: Suspected issue with "remove-zombie-locks.py"?)

Posted by Daniel Shahaf <da...@apache.org>.
Daniel Shahaf wrote on Mon, Mar 06, 2017 at 16:06:44 +0000:
> I can reproduce this using the FS API only (without the contrib/ script):

While reproducing this I ran into:

    % svn lock -q a
    Subcommand 'lock' doesn't accept option '-q [--quiet]'
    Type 'svn help lock' for usage.

I assume the following will fix it, but I don't have a build environment
so I can't test it.

[[[
Index: subversion/svn/svn.c
===================================================================
--- subversion/svn/svn.c	(revision 1785678)
+++ subversion/svn/svn.c	(working copy)
@@ -807,7 +807,7 @@ const svn_opt_subcommand_desc2_t svn_cl__cmd_table
      "usage: lock TARGET...\n"
      "\n"
      "  Use --force to steal the lock from another user or working copy.\n"),
-    { opt_targets, 'm', 'F', opt_force_log, opt_encoding, opt_force },
+    { opt_targets, 'q', 'm', 'F', opt_force_log, opt_encoding, opt_force },
     {{'F', N_("read lock comment from file ARG")},
      {'m', N_("specify lock comment ARG")},
      {opt_force_log, N_("force validity of lock comment source")}} },
]]]

Cheers,

Daniel

Re: Suspected issue with "remove-zombie-locks.py"?

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Doug Robinson wrote on Mon, Mar 06, 2017 at 10:15:04 -0500:
> 
> Doug Robinson <do...@wandisco.com> wrote:
> > Traceback (most recent call last):
> >
> >   File "hook-scripts/remove-zombie-locks.py", line 214, in <module>
> >
> >     main()
> >
> >   File "hook-scripts/remove-zombie-locks.py", line 208, in main
> >
> >     remover.run()
> >
> >   File "hook-scripts/remove-zombie-locks.py", line 138, in run
> >
> >     self.unlock_nonexistent_files, self.pool)
> >
> >   File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/libsvn/fs.py",
> > line 860, in svn_fs_get_locks2
> >
> >     return _fs.svn_fs_get_locks2(*args)
> >
> > svn.core.SubversionException: 160034 - No username is currently associated
> > with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'

I can reproduce this using the FS API only (without the contrib/ script):

% python2
>>> from svn.core import *
>>> from svn.fs import *
>>> from __future__ import print_function
>>> fs = svn_fs_open("r/db", None)
>>> svn_fs_get_locks2(fs, "", svn_depth_infinity, print) 
<libsvn.core.svn_lock_t; proxy of <Swig Object of type 'svn_lock_t *' at 0x7f4d83bb9660> > <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at 0x7f4d83bb96c0> >
>>> svn_fs_get_locks2(fs, "", svn_depth_infinity, (lambda lock, pool: svn_fs_unlock(fs, lock.path, lock.token, True, pool)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/libsvn/fs.py", line 876, in svn_fs_get_locks2
    return _fs.svn_fs_get_locks2(*args)
svn.core.SubversionException: 160034 - No username is currently associated with filesystem 'a1257b00-ab15-4056-8430-3a7080d0ccfe'

> I realize that the SHA1-collision issues are consuming most of the duty
> cycles at this point.  Before I forget about this one - should I file a bug?

Yes, please.

Thanks,

Daniel

Re: Suspected issue with "remove-zombie-locks.py"?

Posted by "C. Michael Pilato" <cm...@collab.net>.
Yes, please do.

On 03/06/2017 10:15 AM, Doug Robinson wrote:
> Folks:
>
> I realize that the SHA1-collision issues are consuming most of the
> duty cycles at this point.  Before I forget about this one - should I
> file a bug?
>
> Cheers!
>
> Doug
>
> On Thu, Mar 2, 2017 at 8:19 AM, Doug Robinson
> <doug.robinson@wandisco.com <ma...@wandisco.com>> wrote:
>
>     Folks:
>
>     The following commands were run on a CentOS 6.x, WANdisco
>     Subversion 1.9.5, Python 2.7:
>     --------------------------------------------------------------------------------------
>     # svn
>     export https://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts
>     <https://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts>
>     # svnadmin create repo
>     # svn co file:///path/to/repo wc
>     # cd wc
>     # touch wc/a; svn add wc/a; svn ci -mm wc
>     # svn lock wc/a; svn rm wc/a; svn ci -mm --no-unlock wc
>     # hook-scripts/remove-zombie-locks.py repo1 all
>
>     Removing all zombie locks from repository at /root/repo
>
>     This may take several minutes...
>
>     /a
>
>     Traceback (most recent call last):
>
>       File "hook-scripts/remove-zombie-locks.py", line 214, in <module>
>
>         main()
>
>       File "hook-scripts/remove-zombie-locks.py", line 208, in main
>
>         remover.run()
>
>       File "hook-scripts/remove-zombie-locks.py", line 138, in run
>
>         self.unlock_nonexistent_files, self.pool)
>
>       File
>     "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/libsvn/fs.py",
>     line 860, in svn_fs_get_locks2
>
>         return _fs.svn_fs_get_locks2(*args)
>
>     svn.core.SubversionException: 160034 - No username is currently
>     associated with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'
>
>     --------------------------------------------------------------------------------------
>
>
>     Is this a known issue?  Or should I file a bug?
>
>
>     Thank you.
>
>
>     Doug
>     -- 
>     *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>
>     *T *925-396-1125
>     *E* doug.robinson@wandisco.com <ma...@wandisco.com>
>
>     *www.wandisco.com <http://www.wandisco.com/>*
>     *
>     *
>     **
>
>
>
>
> -- 
> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>
> *T *925-396-1125
> *E* doug.robinson@wandisco.com <ma...@wandisco.com>
>
> *www.wandisco.com <http://www.wandisco.com/>*
> *
> *
> **
>
> Learn how WANdisco Fusion solves Hadoop data protection and
> scalability challenges <http://www.wandisco.com/hadoop/wd-fusion>
>
> Listed on the London Stock Exchange: WAND
> <http://www.bloomberg.com/quote/WAND:LN>
>
> THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND
> MAY BE PRIVILEGED.  If this message was misdirected, WANdisco, Inc.
> and its subsidiaries, ("WANdisco") does not waive any confidentiality
> or privilege.  If you are not the intended recipient, please notify us
> immediately and destroy the message without disclosing its contents to
> anyone.  Any distribution, use or copying of this e-mail or the
> information it contains by other than an intended recipient is
> unauthorized.  The views and opinions expressed in this e-mail message
> are the author's own and may not reflect the views and opinions of
> WANdisco, unless the author is authorized by WANdisco to express such
> views or opinions on its behalf.  All email sent to or from this
> address is subject to electronic storage and review by WANdisco.
>  Although WANdisco operates anti-virus programs, it does not accept
> responsibility for any damage whatsoever caused by viruses being passed.
>


Re: Suspected issue with "remove-zombie-locks.py"?

Posted by Doug Robinson <do...@wandisco.com>.
Folks:

I realize that the SHA1-collision issues are consuming most of the duty
cycles at this point.  Before I forget about this one - should I file a bug?

Cheers!

Doug

On Thu, Mar 2, 2017 at 8:19 AM, Doug Robinson <do...@wandisco.com>
wrote:

> Folks:
>
> The following commands were run on a CentOS 6.x, WANdisco Subversion
> 1.9.5, Python 2.7:
> ------------------------------------------------------------
> --------------------------
> # svn export https://svn.apache.org/repos/asf/subversion/trunk/con
> trib/hook-scripts
> # svnadmin create repo
> # svn co file:///path/to/repo wc
> # cd wc
> # touch wc/a; svn add wc/a; svn ci -mm wc
> # svn lock wc/a; svn rm wc/a; svn ci -mm --no-unlock wc
> # hook-scripts/remove-zombie-locks.py repo1 all
>
> Removing all zombie locks from repository at /root/repo
>
> This may take several minutes...
>
> /a
>
> Traceback (most recent call last):
>
>   File "hook-scripts/remove-zombie-locks.py", line 214, in <module>
>
>     main()
>
>   File "hook-scripts/remove-zombie-locks.py", line 208, in main
>
>     remover.run()
>
>   File "hook-scripts/remove-zombie-locks.py", line 138, in run
>
>     self.unlock_nonexistent_files, self.pool)
>
>   File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/libsvn/fs.py",
> line 860, in svn_fs_get_locks2
>
>     return _fs.svn_fs_get_locks2(*args)
>
> svn.core.SubversionException: 160034 - No username is currently associated
> with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'
>
> ------------------------------------------------------------
> --------------------------
>
>
> Is this a known issue?  Or should I file a bug?
>
>
> Thank you.
>
>
> Doug
> --
> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>
> *T *925-396-1125
> *E* doug.robinson@wandisco.com
>
> *www.wandisco.com <http://www.wandisco.com/>*
>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robinson@wandisco.com

*www.wandisco.com <http://www.wandisco.com/>*

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>

Listed on the London Stock Exchange: WAND 
<http://www.bloomberg.com/quote/WAND:LN>

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.