Checking Current Activity Status Troubleshooting

Bugs and issues Linux
#1

Hi,

Using insync-headless you have a couple of actions like get_actions_required, get_errors, get_sync_progress and get_status that enables you to check what is going on with Insync at a high level. I use these commands regularly when working with Insync on a headless box.

I would however like to know how to check what is happening with Insync at a lower level as well, when none of the above commands are able to resolve why Insync is seemingly just hanging in a paused state for days and not doing anything else?

I have copies of the various .db files from the faulty server, amongst others the logs.db file as well. Is this the correct place to check what is happening with Insync at this very moment? As Insync does not add any log entries to native Linux logging journals it is assumed that this is the only place one can look for its up-to-the-second state information?

As these are DB tables, I am also assuming that the latest log entries will appear in the last rows of the events_log table? Your time stamps that you are using are gibberish so its difficult to find the correct time entry by looking at those :slight_smile: Is there a way to decode these to confirm time entries?
The last row is showing client_run as the thread name, yet when get_status is queried is shows as paused?

Werner

1 Like
#2

Tagging our engineer @lpugoy and he will get back to you.

#3

@WvdW: Hi. What are the outputs of the get_actions_required, get_errors, etc. commands? Yes, the logs.db file is Insync’s log, and the last rows of the events_log table contains the latest entries. The timestamp column is the Unix time of representation of the date and time when the event happened. You can convert it to a normal date time representation with the date command for example:

$ date -u -d '@1489323076'
Sun Mar 12 12:51:16 UTC 2017

Where “1489323076” is an example of a Unix time.

#4

Hi @lpugoy, thanks. Outputs are as follows:

  1. get_sync_progress: No syncing activities
  2. get_actions_required: A list of some folders it couldn’t delete
  3. get_errors: None
  4. get_status: PAUSED

The folders that can’t be deleted are there because we have a file exclusion of .directory, and if any folder contains a .directory file, it will not be removed until you manually go and delete those. As soon as you manually delete the files then Insync automatically picks it up and it will remove the folder(s) and clear this list.
So I’m not concerned that this is where the problem lies. We have dealt with this many times before successfully without Insync going into this perpetual pending state.

Werner

#5

@WvdW: Thanks. The output of get_status shows PAUSED. Have you tried running the resume_syncing command?

#6

@lpugoy slight_smile: as soon as I posted the reply I saw that and thought that maybe I should have categorically stated something about it before you ask… but then again if you read the last sentence of my original post then you will see that there is an anomaly. The log says the client is running but get_status says its paused?

To answer your question very specifically: Yes, I have already resume_syncing and response is OK but nothing happens. Even after several resume_syncing and reboots, all the states remain exactly the same.

#7

@WvdW: I see. We probably need to take a look at your logs in that case. Please send them to support@insynchq.com for investigation. You can compress them before sending to save space.

#8

@lpugoy: Compressed the combined file size of config.db, gd2*.db and logs.db is still 623mb, so way to big to mail. Do you have an uploadable file share maybe? Or maybe just the logs.db itself?

On the issue of log sizes - until digging around in them with the troubleshooting I never realised how big they had grown. Is there a way to curb their growth or at least do some table trims safely? Or do they just keep on growing?
What is the standard log maintenance procedures to follow to keep your machine from running out of space?

#9

@WvdW: You can upload them to Google Drive and share the link with support@insynchq.com. For the logs, you can delete the logs.db file while Insync is stopped if it grows too large. The files under ~/.config/Insync/dbs cannot be changed though because that is where Insync keeps track of the state of your Google Drive account.

#10

@lpugoy: I will upload and send.

The gd*.db files are the problem. Collectively they are already over 3gb and growing. Once files/folders have been synced and then removed from selective syncing, surely their history can be cleaned out of the tables? It is storing redundant information that is never going to be required again and just filling space unnecessarily?
I can understand that information has to be retained for files/folders that are actively being synced but the old ones?

#11

@WvdW: The gd*.db file stores the metadata of all the files in your Drive account as well as the files in your local Insync folder. If you have a lot of files in both then it would grow to a large size. There’s no work yet to reduce the size of these dbs, apologies for the trouble.

#12

@lpugoy: So it stores the metadata for ALL files in Drive, and not just the folders/files that have been selected during selective syncing?
Surely this not only takes up unnecessary db storage but also slows down syncs and resyncs a lot as it now has to check through metadata for so many more files than required by the actual sync job?

#13

@WvdW: We store the metadata for all files in Drive to make it easier for users to use the selective sync interface. The metadata of other files shouldn’t affect the syncing speed of changed files because they are not being accessed.

#14

Whatever happened with this problem?