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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Robinson
Folks:

The following commands were run on a CentOS 6.x, WANdisco Subversion 1.9.5, Python 2.7:
--------------------------------------------------------------------------------------
# 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




Learn how WANdisco Fusion solves Hadoop data protection and scalability challenges

Listed on the London Stock Exchange: WAND

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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Robinson
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 <[hidden email]> wrote:
Folks:

The following commands were run on a CentOS 6.x, WANdisco Subversion 1.9.5, Python 2.7:
--------------------------------------------------------------------------------------
# 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






--
DOUGLAS B. ROBINSON SENIOR PRODUCT MANAGER




Learn how WANdisco Fusion solves Hadoop data protection and scalability challenges

Listed on the London Stock Exchange: WAND

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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Shahaf-2
Doug Robinson wrote on Mon, Mar 06, 2017 at 10:15:04 -0500:

>
> Doug Robinson <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

C. Michael Pilato
In reply to this post by Doug Robinson
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
> <[hidden email] <mailto:[hidden email]>> 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* [hidden email] <mailto:[hidden email]>
>
>     *www.wandisco.com <http://www.wandisco.com/>*
>     *
>     *
>     **
>
>
>
>
> --
> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>
> *T *925-396-1125
> *E* [hidden email] <mailto:[hidden email]>
>
> *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.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Shahaf-5
In reply to this post by Daniel Shahaf-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Stefan Sperling
In reply to this post by Daniel Shahaf-2
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!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Stefan Sperling
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Shahaf-2
In reply to this post by Stefan Sperling
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!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Doug Robinson
In reply to this post by Daniel Shahaf-2

On Mon, Mar 6, 2017 at 11:06 AM, Daniel Shahaf <[hidden email]> wrote:
Doug Robinson wrote on Mon, Mar 06, 2017 at 10:15:04 -0500:
>
> Doug Robinson <[hidden email]> 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




Learn how WANdisco Fusion solves Hadoop data protection and scalability challenges

Listed on the London Stock Exchange: WAND

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.

Loading...