home-assistant / operating-system

:beginner: Home Assistant Operating System
Apache License 2.0
4.55k stars 939 forks source link

Can't use folder_watcher #1599

Closed yordanov-alexandar closed 8 months ago

yordanov-alexandar commented 2 years ago

Hardware Environment

Home Assistant OS release:

yordanov-alexandar commented 2 years ago

Forgot to mention that I am using this: https://gist.github.com/eklex/c5fac345de5be9d9bc420510617c86b5 to mount two external drives in the media directory

yordanov-alexandar commented 2 years ago

I have new information about this issue. I have Jellyfin server installed (https://github.com/alexbelgium/hassio-addons/tree/master/jellyfin) that is setup to serve the files from one of the drives mentioned above and it occurred to me that maybe it's 'consuming' all of the inotify watchers and that's why folder_watcher gives this error. So i tried disabling it and restarted the home assistant host. There was no inotify watch limit reached error this time and the automation using folder_watcher worked. So now I am pretty sure that increasing the value of fs.inotify.max_user_watches will solve my problem

agners commented 2 years ago

According to the Linux Kernel documentation, the default of this value depends on the amount of memory your system has. By default the system allows to allocate file system watcher up to 4% of available memory.

Since this value is determined dynamically, I cannot just simply set a static, higher value for all users. Also we do have users having problems with running out of memory, so restricting memory usage for filesystem watchers seems a good thing there...

What you can do is just simply add another RUN command to the udev rule. E.g. check what the current settings are in your system, and then set a higher value for your specific use case:

# sysctl fs.inotify.max_user_watches

Then add

sysctl -w fs.epoll.max_user_watches=<highervalue>
yordanov-alexandar commented 2 years ago

Thank you that worked. It hadn't occurred to me to use the udev rule in such a way. This feels like a hack though :) Might I suggest implementing a mechanism that copies the files from /sysctl.d/ to /etc/sysctl.d/ similar to what is done with the udev rules