Headless 3 fails to "see" certain files

Bugs and issues Linux
#1

Headless 3.2.3.10725
Ubuntu 20.04.4 LTS (server)

We recently upgraded from 1.5 to 3 and one odd thing I’ve noticed is that certain files in our most heavily trafficked Google folder get ignored. If I run selective-sync, simply opening that interface causes
Insync to find the files – within seconds it syncs them. This is a big problem, because it requires that I check on the folder several times a day to make sure the files are actually moving.

I have one other question (my apologies if this is answered elsewhere): What is the upper limit on the number of files that Insync can track? We got into trouble with version 1 a few weeks ago, probably becayse we accidentally accumulated too many files.

Thanks for your help!

Jay

#2

Hi Jay (@integration_integrat)!

Thanks so much for reaching out and my apologies for the trouble. Indeed, it’s not sustainable to need to manually check the selective-sync interface just to sync those files .Am I understanding that these files are ignored even if Insync-headless is running (without opening selective-sync)?

Please do send your logs.db and out.txt files to support@insynchq.com with the link to this post (and look for me, Mia!). We’ll need to investigate what the possible cause/s is/are.

As for the upper limit - I do not have the exact numbers for you, but I will check with our team if there is one :slight_smile:

#3

@integration_integrat Update from our engineer:

On Linux, there’s a default limit of 8192 inotify watches. But when Insync gets installed, we do automatically set this limit (fs.inotify.max_user_watches) higher to 1048576.

1 Like
#4

Am I understanding that these files are ignored even if Insync-headless is running (without opening selective-sync)?

That’s correct. We have it running all the time, and most of the files get picked up without any intervention, but every day there are several dozen that do not. I’ve emailed the logs as you requested.

1 Like
#5

Thanks for sending the files my way, @integration_integrat! I’ve forwarded them to our Linux team and I’ll update you once I know more about the issue.

1 Like
#6

when Insync gets installed, we do automatically set this limit (fs.inotify.max_user_watches) higher to 1048576.

Do you know if there’s a relatively simple way to check how close to this limit we are?

#7

Let me check that for you!

#8

Hi @integration_integrat! find </path/to/directory> | wc -l should work :slight_smile:

#9

It would need to be built-in because of the selective-sync configuration (We have dozens of black-listed subdirectories). Something to consider for a future release.

#10

Just looking around, I’ve found a user-made script (in StackOverflow) which lists the current processes and number of watchers they consume.

Hope that helps.

2 Likes
#11

That’s an interesting idea – thank you!

2 Likes
#12

You’re very welcome, don’t mention it. :slight_smile:

#13

@mia, is there any further information I can give your engineering team?

#14

Hello, @integration_integrat! I am following this up with our Linux team to check what other information we would need from you. I appreciate you for bumping this thread - thank you as well for your patience!

1 Like
#15

Update: (also sent to your email, @integration_integrat!)

Upon checking, our engineers saw some errors that could be causing the cloud to local sync issues you described. They’re still looking into this lead and continuing their investigation to collect more information.

Thank you for your patience!

1 Like
#16

Just checking in…

#17

Hi @integration_integrat :slight_smile:

I will follow this up with them as they have not yet found any further leads after I last updated this forums 3 days ago. Thank you so much for bumping this thread to flag it!

#18