Insync-headless v 1.2.17 will not start

Dominic · July 27, 2015, 10:49pm

I can’t get insync-headless v1.2.17 to start. When I run it with the no-daemon flag, I get the following output:

  CRITICAL:root:while creating Client object
Traceback (most recent call last):
  File "ideskmain/client.py", line 816, in client_gevent_runner
  File "ideskutils/gevent_itc.py", line 120, in wrapper
  File "ideskutils/gevent_itc.py", line 29, in wrapper
  File "ideskmain/client.py", line 65, in __init__
  File "ideskmain/client.py", line 534, in __load_config
  File "ideskmain/clientconfig.py", line 8, in __init__
  File "ideskmain/clientconfig.py", line 82, in _install_db
  File "ideskdb/clientdb.py", line 135, in __init__
  File "ideskdb/clientdb.py", line 235, in execute
OperationalError: unable to open database file
An unexpected critical error occurred. Will quit now.

This is since updating from the previous version, with no other changes.

Dominic · July 27, 2015, 10:58pm

Sorry, I forgot to give other details. I’m running ubuntu version 14.04 (64 bit).

lpugoy · July 29, 2015, 7:18am

@Dominic Could you try running sqlite3 ~/.config/Insync/dbs/config.db '' then restarting Insync?

Dominic · July 29, 2015, 9:46pm

No change.
The first command ran without any obvious output or error. I got the same errors as before when trying to restart insync-headless.

I don’t know much about sqlite3, but I ran a few sqlite commands, to see if the db could open, like .tables, .dump and PRAGMA integrity check, with the following results:

sqlite3 ~/.config/Insync/dbs/config.db
       .timeout MS            Try opening locked tables for MS milliseconds                           SQLite version 3.8.2 2013-12-06 14:53:30
       .width NUM1 NUM2 ...   Set column widths for "column" mode                                     Enter ".help" for instructions
       .timer ON|OFF          Turn the CPU timer measurement on or off                                Enter SQL statements terminated with a ";"
       sqlite>                                                                                        sqlite> .tables
                                                                                                      sqlite> .dump
OPTIONS                                                                                               PRAGMA foreign_keys=OFF;
       sqlite3 has the following options:                                                             BEGIN TRANSACTION;
                                                                                                      /**** ERROR: (14) unable to open database file *****/
       -init file                                                                                     ROLLBACK; -- due to errors

and:

sqlite3 ~/.config/Insync/dbs/config.db "PRAGMA integrity_check"
       -init file                                                                                     Error: unable to open database file

it’s not a file permissions thing, I can cat the file just fine.

For what it’s worth, I have various backups of the config file going back to before, when I could launch insync OK.

Dominic · July 29, 2015, 9:55pm

@lpugoy - one more thing. The database file has not changed in the last week, and I only updated to 1.2.17 two days ago, so it may be that whatever has gone wrong is not a 1.2.17 thing, so much as it was the trigger for me having to restart insync, and noticing the problem.

As a side comment - running the command insync-headless start gave no visible errors whatsoever, even though the --no-daemon version did, which seems unfortunate. It’s only my check that it’s running (which I do when I’ve restarted manually) that caught the problem. That means that I might have had insync not running for some time (i.e. since I last rebooted), without knowing it. Which is not ideal for a backup solution.

Dominic · August 4, 2015, 7:44am

Any advice on what I should try next? It’s been 5 days.

I could delete the config file and reestablish my account credentials. I don’t want to have to resync all my files, but if the config file is just for account details, would that work?

lpugoy · August 12, 2015, 10:55am

@Dominic Apologies for not replying sooner. If the issue is only with the config.db file, you could try the following:

mv ~/.config/Insync ~/.config/Insync.bak
Re-add the accounts in your original Insync setup. You could just choose a temporary folder and not sync any files since we are just concerned with the config.db file.
After adding the original accounts stop Insync.
mv ~/.config/Insync/dbs/config.db ~/.config/Insync.bak/dbs/config.db
rm -r ~/.config/Insync
mv ~/.config/Insync.bak ~/.config/Insync
Restart Insync.

Dominic · August 12, 2015, 8:46pm

The procedure of reconnecting the account appeared to work (started to create files in the new temp folder, etc.)

But after replacing the rest of the directory contents, I get exactly the same errors, including not being able to dump the contents of the config.db.

However, I noticed the config.db-wal file and the other (longfilename).db-wal file.
After removing those, I was able to restart insync-headless. I presume that insync had shutdown badly and these files should have been cleaned up.

Until it can get to a point where it’s saying that it has fully synchronised, it’s hard for me to know whether it’s working. (It’s currently stuck on 1546 files are queued), but at least I’ve got it running.

Dominic · August 13, 2015, 8:11pm

Although it hasn’t finished yet, it now seems to be syncing as expected.

I’ve also worked out what went wrong: at some point I ran insync-headless with sudo. I’m not sure why. That created the temporary .db-wal files with root:root ownership, which meant that on restarting insync using my normal account, it couldn’t clear up the .db-wal files and proceed.

FWIW, the lessons I take from this are:

it would be much better if insync-headless was automatically restarted after upgrades, rather than having to be manually restarted.
it would be better if it logged errors (and startup / shutdown events) in a more obvious way - to syslog, for example, or by email, where I would have seen them and been more likely to work out what was happening.
when starting insync from the command line it would be much better if it showed errors if it failed to start

lpugoy · August 14, 2015, 8:20am

@Dominic I see. Glad it’s working for you now. #1 and #3 are in our list of TODOs but they haven’t been scheduled yet so I can’t give an ETA for them. Let us know if you encounter any more issues.

Dominic · August 14, 2015, 7:42pm

unfortunately, now that it’s finished syncing and all at first appears to be normal, I’ve gone back to check that it is working, and there are at least two directories whose contents have not been synchronised.
(These are directories of photos taken during the downtime when insync was not running; both the directories and their contents were created since insync was last run successfully.)

More alarmingly than that, there are errors in the logs.db file that show that insync tried to delete the local directories, but failed because they were not empty.

I do not understand why of the three directories of photos, in one parent directory, insync successfully uploaded one directory to the cloud, but chose to try to delete the local copies of the other two (plus other folders in other locations).

I am extremely relieved that it did not succeed in deleting my only copies.

Do you have any advice on:

How can I get insync to back these up correctly?
How can I tell whether insync is going to have this problem for other files?

lpugoy · August 17, 2015, 7:58am

@Dominic Please send your logs to support@insynchq.com for investigation: How to find the log files.