I did some digging, and found that I had to remove some files in the ~/.s3ql directory. All is okay now - I am currently using fsck to repair some damage to the FS. This had also happened before, but instead of being because of some files in the .s3ql directory, it was because fusermount -u did not cause mount.s3ql to terminate and then kill -TERM'ing it caused similar fsck repair to be necessary.
I think it's all sorted out now. Thanks Brandon On Fri, Aug 12, 2016 at 10:27 PM, Brandon Orwell <[email protected]> wrote: > I had an Amazon S3 filesystem mounted in /mnt/s3qlbackup1. I was copying > files via "rsync" to it, interrupted the rsync, and then "fusermount -u > /mnt/s3qlbackup1" to unmount it. > > A minute later, I tried to remount the filesystem. Instead of mounting > successfully, I received this error (using the --debug flag as well) this > is from ~/.s3ql/mount.log: > > 2016-08-12 22:24:40.878 22074:MainThread s3ql.mount.determine_threads: >>> Using 10 upload threads. >> >> 2016-08-12 22:24:40.879 22074:MainThread s3ql.mount.main: Autodetected >>> 65474 file descriptors available for cache entries >> >> 2016-08-12 22:24:40.898 22074:MainThread s3ql.backends.s3c._do_request: >>> started with GET /s3ql_passphrase?None, qs=None >> >> 2016-08-12 22:24:40.899 22074:MainThread s3ql.backends.s3c._send_request: >>> sending GET /s3ql_passphrase >> >> 2016-08-12 22:24:41.079 22074:MainThread s3ql.backends.s3c._do_request: >>> started with GET /s3ql_passphrase?None, qs=None >> >> 2016-08-12 22:24:41.079 22074:MainThread s3ql.backends.s3c._send_request: >>> sending GET /s3ql_passphrase >> >> 2016-08-12 22:24:41.290 22074:MainThread s3ql.backends.s3c.list: started >>> with s3ql_seq_no_, >> >> 2016-08-12 22:24:41.290 22074:MainThread s3ql.backends.s3c.list: >>> requesting with marker= >> >> 2016-08-12 22:24:41.291 22074:MainThread s3ql.backends.s3c._do_request: >>> started with GET /?None, qs={'max-keys': 1000, 'prefix': 's3ql_seq_no_', >>> 'marker': ''} >> >> 2016-08-12 22:24:41.291 22074:MainThread s3ql.backends.s3c._send_request: >>> sending GET /?max-keys=1000&prefix=s3ql_seq_no_&marker= >> >> 2016-08-12 22:24:41.636 22074:MainThread s3ql.backends.s3c.lookup: >>> started with s3ql_seq_no_7 >> >> 2016-08-12 22:24:41.636 22074:MainThread s3ql.backends.s3c._do_request: >>> started with HEAD /s3ql_seq_no_7?None, qs=None >> >> 2016-08-12 22:24:41.636 22074:MainThread s3ql.backends.s3c._send_request: >>> sending HEAD /s3ql_seq_no_7 >> >> 2016-08-12 22:24:41.708 22074:MainThread s3ql.backends.s3c.lookup: >>> started with s3ql_seq_no_7 >> >> 2016-08-12 22:24:41.708 22074:MainThread s3ql.backends.s3c._do_request: >>> started with HEAD /s3ql_seq_no_7?None, qs=None >> >> 2016-08-12 22:24:41.709 22074:MainThread s3ql.backends.s3c._send_request: >>> sending HEAD /s3ql_seq_no_7 >> >> 2016-08-12 22:24:41.775 22074:MainThread s3ql.backends.s3c.lookup: >>> started with s3ql_seq_no_8 >> >> 2016-08-12 22:24:41.775 22074:MainThread s3ql.backends.s3c._do_request: >>> started with HEAD /s3ql_seq_no_8?None, qs=None >> >> 2016-08-12 22:24:41.775 22074:MainThread s3ql.backends.s3c._send_request: >>> sending HEAD /s3ql_seq_no_8 >> >> 2016-08-12 22:24:41.838 22074:MainThread s3ql.mount.get_metadata: Using >>> cached metadata. >> >> 2016-08-12 22:24:41.839 22074:MainThread root.excepthook: Uncaught >>> top-level exception: >> >> Traceback (most recent call last): >> >> File "/usr/local/bin/mount.s3ql", line 9, in <module> >> >> load_entry_point('s3ql==2.18', 'console_scripts', 'mount.s3ql')() >> >> File "/usr/local/lib/python3.4/dist-packages/s3ql-2.18-py3.4- >>> linux-x86_64.egg/s3ql/mount.py", line 129, in main >> >> (param, db) = get_metadata(backend, cachepath) >> >> File "/usr/local/lib/python3.4/dist-packages/s3ql-2.18-py3.4- >>> linux-x86_64.egg/s3ql/mount.py", line 372, in get_metadata >> >> db = Connection(cachepath + '.db') >> >> File "/usr/local/lib/python3.4/dist-packages/s3ql-2.18-py3.4- >>> linux-x86_64.egg/s3ql/database.py", line 71, in __init__ >> >> cur.execute(s) >> >> File "src/cursor.c", line 990, in APSWCursor_execute.sqlite3_prepare >> >> File "src/statementcache.c", line 386, in sqlite3_prepare >> >> apsw.BusyError: BusyError: database is locked >> >> > I am unable to mount the filesystem now. The rsync/cp process was killed > prior to unmounting it. Why is this error occurring and, most importantly, > how do I remedy it? > > > Thanks, > > Brandon > > -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
