Clementine complains about inotify max_user_watches

Support
1

Hi,
Clementine greeted me with an error message including the hint:
On a Linux system, this may be due to the inotify max_user_watches limit.

This prompted me to search for the issue and I found Arch/Manjaro - wiki/Increasing-the-amount-of-inotify-watchers · Issue #444 · guard/listen · GitHub and increase inotify file watchers in manjaro · Issue #4 · Pliavi/distros-tweaks-and-fixes · GitHub

I checked the /etc/sysctl.d/ directory and found only one of the files discussed in the above links (50-max_user_watches.conf) with the only content of: “fs.inotify.max_user_watches = 16384”

Also the Manjaro forum has one bit of information regarding the above conf file here: Inotify_add_watch Permission denied

Based on the Manjaro forum post of @merlock I have now set the limit to 204800.

So far, so good, and now comes the question: what is a “sane” value for the max_user_watches limit and/or what determines what a “sane” limit for a given system might be? The info I find to this is cryptic to me … Thanks a lot for your input.

1 Like
2

Since inotify is used by various software, a ‘sane’ amount is (IMO) whatever amount stops errors from occurring.

If you’re so inclined, you could play with various values until you find a lower limit that stops errors from occurring.

1 Like
3

I know that this doesn’t answer your question, but have you considered trying Strawberry music player? It is a fork of Clementine and seems to be more actively developed.

1 Like
4

It doesn’t really matter, I just know there might be some memory constraints if you set it very high. I have mine set to 50000 just shy of 524288 (max limit) because VSCode was complaining about not having enough. I probably don’t need that many but so far it hasn’t done any harm.

1 Like
5

I attempted to find/use a sane value in

… wait a sec … it looks like its not in there.

Some version has it … I probably dropped it somewhere …

1 Like
6

Could by a typo, but that number is 1/10 and not “just shy of”.

edit: Manjaro’s filesystem package contains /usr/lib/sysctl.d/10-manjaro.conf which sets this:

$ cat /usr/lib/sysctl.d/10-manjaro.conf
# Raise inotify resource limits
fs.inotify.max_user_instances = 1024
fs.inotify.max_user_watches = 524288
1 Like
7

@merlock: Thanks, it seems like you took the middle ground with your proposition then, right?
@Thatguy, @cscs and @freggel.doe Thank you also for your input. What does the 10-manjaro.conf file do? Just defining the limits? I thought 524288 inodes were a system-wise limitation anyways? :thinking:
I thought the inotify value has something to do with the absolute number of files in the root directory. I guess that Clementine was complaining as my root partition was 94% filled up with quite a lot of crap actually like depreciated kernels, enormous log-files and first and foremost an insane amount of package cache. So my theory is that Clementine complained that it has not enough inodes left for the files of my (considerably large) music collection.

So I raised the inotify limit as posted, and cleaned the root partition (down to 57% occupancy) and the error has not reoccurred since.

@jrichard326: Yes, I have tried what feels about 95% of the available music players, strawberry included (I missed the nice Clementine option of smart playlists, which I use regularly, so I dropped it). My second choice after Clementine is gmusicbrowser, it’s a bit clumsier but has all the features I ask for and then some and on top of it those features again (which makes it a bit clumsy); unluckily it’s no longer actively developed.

8

Seems the Strawberry folks are working on this feature:

2 Likes
9

I have added this to my system for using JACK, as recommended by realtimeconfigquickscan

# /etc/sysctl.d/99-sysctl-realtime.conf
vm.swappiness=10
fs.inotify.max_user_watches = 524288

But if you want to use a smaller value, this script may help help
dotfiles/inotify-consumers at master · fatso83/dotfiles · GitHub

1 Like
10

Thank you! While I don’t think that I need to make my system real-time ready, the links were very insightful!

One note to the swappiness: I have implemented a small swap partition (after reading a lot pro/con) of only 1 GB (the system has 16 GB RAM), for some possible advantages I don’t remember any more, but at the time I made the decision to have a (not suspend to disk ready sized) swap partition. Presently, the swap partition just “dribbles” full and the system becomes “sloppy”. I have set the swappiness to 1 (didn’t help) and now even to 0, but even with a swappiness of zero, the effect of slowly filling up swap (and then behaving sloppy) persists. Why?

My actual swappiness “workaround” is to just swapoff -a (and maybe I just opt to disable swap entirely).

11

I guess /etc/sysctl.d/50-max_user_watches.conf is overriding the max user watches, since I also have that file you mention, but the limit clearly isn’t set by it?

Edit: According to pacman, no package owns my 50-max_user_watches.conf

12

The file I mentioned is named 10-manjaro.conf and it (still) does belong to a package:

$ pacman -Qo /usr/lib/sysctl.d/10-manjaro.conf
/usr/lib/sysctl.d/10-manjaro.conf is owned by filesystem 2021.01.19-1

It is on my system(s).

Check if any “later” conf-file overrides that setting.

13

I was talking about /etc/sysctl.d/50-max_user_watches.conf, which overrides it.
But I’ve just removed it, so /usr/lib/sysctl.d/10-manjaro.conf is now the one setting the limit.

Whatever originally brought it to my system between last June and today, I don’t know. But it’s planned to be removed from ISOs as well:

1 Like