This is a problem which has happened to some of the Dropbox customers, who have the client installed under Linux:
The Dropbox Icon changes to a grayed-out icon, with a red cross, and when we click or right-click on the icon, it says it’s unable to access (its) Dropbox folder. It even asks us for our Linux Password (apparently Windows-gurus don’t understand Linux), in a bid to correct the permissions of the folder in question. Don’t enter any password. At the same time, if we have a very complex desktop-management system running, we may find that the Desktop and its management-software become laggy to almost non-functional, especially with ‘Baloo’ running etc..
In my case this was due to the combination of two factors:
- I had added many, systematically-named files to my Dropbox folder from another synced computer, due to backing up newly-installed software.
- Dropbox uses a feature called ‘INotify’, so that a program gets notified as soon as the contents of a file are changed, which that program has placed a watch on. In this case, Dropbox has a watch on thousands of files.
In my case, the following helped. On a Debian-based system, in a terminal-window, type:
dirk@Phoenix:~$ su Password: root@Phoenix:/home/dirk# cd /etc root@Phoenix:/etc# edit text/*:sysctl.conf
Then, edit the file in question, to contain the following two lines:
fs.inotify.max_user_watches = 262144 fs.inotify.max_user_instances = 256
Then, to make the changes take effect, type:
root@Phoenix:/etc# sysctl -p
What this does is set the kernel limits ‘very high’, as to how many INotify-watches it will support. For the moment, the Dropbox client on this machine is stable again.
(Updated 07/03/2018, 8h35 … )
(As of 07/02/2018, 11h25 : )
Actually, according to my own recent experience, after applying the above fix, if the limit already did run out, a reboot is nevertheless required.
And because of the needed reboot, my server was also down for about 10 minutes this morning…
What I read is that on a 32-bit system, each watch takes up 540 bytes of kernel-memory, while on a 64-bit system, it takes up 1080 bytes. The server which I have, named ‘Phoenix’, is also my weakest system, with only 4GB of RAM. Therefore, it would not make sense for me to set an astronomically-high limit on this box. The above limit will take up a maximum of 270MiB.
I suppose another question readers might have, is whether just to log out, and then to log back in again, will provide relief. And the answer to that question depends, on what sort of programs are asking for watches.
The problem that I encountered seemed to be due, to the total number of ‘INotify’ watches exceeding a default-limit. Well if a certain percentage of those watches were not actually requested by Dropbox, but let’s say by the ‘Baloo desktop-indexing system’ – which I have running – then, to log out and log back in again, will at least close this program, and will release the watches that it created. However, if other users are set up in such away, that their ‘Dropbox’ client has asked for most of the watches, then logging out and back in again, will just have as effect, that as soon as Dropbox restarts, it will hit the limit again.
One saving grace which my Debian / Jessie systems, like ‘Phoenix’, already have, is that if ‘Baloo’ encounters this sort of problem,
it will defer indexing my folders, the next time it starts. But on that thread I noticed, that I had passively set Baloo to monitor the ‘Dropbox’ folder as well. This means that for all the potentially thousands of files I had newly added to the Dropbox folder, there were actually two watches being requested, one from Dropbox, and another from Baloo.
Because ‘Phoenix’ is ‘low on memory’ (at 4GB!), what I have done next is to put the ‘Dropbox’ folder as one of those, which ‘Baloo’ will not index. This should additionally alleviate the pinch on my kernel resources.
As the line above states, apparently, so many processes use ‘INotify’, that if this feature ever blocks, the session could be compromised, and a full reboot may be necessary, before the PC’s behavior is correct again. Another reason this would be true is the fact that unlike a person, a program which receives a failure-code, when using a feature, may not make any more attempts later on, to use the same feature. In other words, programs that have failed in their requests to set up INotify watches, may simply stop working, until they’re restarted again. The following command-line will show the user, how many INotify watches his processes have set, and was actual on my machine, directly after a reboot:
dirk@Phoenix:~$ lsof | grep notify | wc -l 2600 dirk@Phoenix:~$ su Password: root@Phoenix:/home/dirk# lsof | grep notify | wc -l 2608 root@Phoenix:/home/dirk#
Giving this command may result in an unexpectedly high number. Given the fact that on some systems, the default limit is 8192, the number evoked above could reach that limit, and not entirely due to processes which the user is consciously aware of. Imagine, if in my case, this number had increased by a few factors, because both ‘Dropbox’ and ‘Baloo’ was using this mechanism to monitor the same folders, and because the computer had been running for many days…
(Update 07/03/2018, 8h35 : )
I suppose that it’s possible, that the kernel will pre-allocate the required number of Megabytes, when the setting is applied and that, if the kernel has as many safeguards built-in as an application would, it would ignore the setting when the required amount of RAM cannot be allocated to it. For that reason it might seem logical, to verify whether the allocation took place, by using the following commands:
dirk@Phoenix:~$ cat /proc/sys/fs/inotify/max_user_watches 262144 dirk@Phoenix:~$ cat /proc/sys/fs/inotify/max_user_instances 256 dirk@Phoenix:~$
However, kernel-code may not have the safeguards built-in, to handle a failure to allocate memory to itself correctly. If not, then a reboot is required.