Greetings,
a while ago, I noticed that on my Fedora box digiKam would not load and display picture galleries anymore, and when launched from the prompt would produce this message:
digikam(14981)/digikam (core): Reached inotify limit
which IIUC means this is a general problem on that computer, not digikam specific.
An online search returned always the same "fix" described e.g. at http://monodevelop.com/Inotify_watches_limit, that is: ################################################################## To change the limit, run:
# echo 16384 > /proc/sys/fs/inotify/max_user_watches
To make the change permanent, edit the file /etc/sysctl.conf and add this line to the end of the file:
fs.inotify.max_user_watches=16384 ##################################################################
(the current value now is 8192)
I could not, however, find any clear (to me at least) explanation of possible unwanted side-effects of this. Should I check/do something else (but what?) or can I safely apply those suggestions and reboot? Is there risk that doing that stuff "as is" messes things up and forces me to spend a day or so recovering the system?
Thanks, Marco
On 04/20/14 13:49, M. Fioretti wrote:
Greetings,
a while ago, I noticed that on my Fedora box digiKam would not load and display picture galleries anymore, and when launched from the prompt would produce this message:
digikam(14981)/digikam (core): Reached inotify limit
which IIUC means this is a general problem on that computer, not digikam specific.
An online search returned always the same "fix" described e.g. at http://monodevelop.com/Inotify_watches_limit, that is: ################################################################## To change the limit, run:
# echo 16384 > /proc/sys/fs/inotify/max_user_watches
To make the change permanent, edit the file /etc/sysctl.conf and add this line to the end of the file:
fs.inotify.max_user_watches=16384 ##################################################################
(the current value now is 8192)
I could not, however, find any clear (to me at least) explanation of possible unwanted side-effects of this. Should I check/do something else (but what?) or can I safely apply those suggestions and reboot? Is there risk that doing that stuff "as is" messes things up and forces me to spend a day or so recovering the system?
I don't know how the system sets this value. 8192 seems rather small to me. On my system....
[egreshko@meimei inotify]$ cat /proc/sys/fs/inotify/max_user_watches 524288
This is the case on an F20 system with 8GB of RAM on real HW and a VM with 1 GB.
And there is nothing in my sysctl.conf to override.
On Sun, Apr 20, 2014 14:11:24 PM +0800, Ed Greshko wrote:
I don't know how the system sets this value. 8192 seems rather small to me.
good point, thanks. This, in fact, is a side question that I forgot to ask in my original email: what are the criteria or rule of thumb to calculate which value of max_user_watches is sensible? Does it depend on number of files, RAM amount, what else?
And there is nothing in my sysctl.conf to override.
same here, but I understand that I should __ADD__ that setting at the end of the file. But this is another point on which I am seeking confirmation/feedback, instead of risking to stop work for a day to fix some problem...
Marco
On 04/20/14 14:09, M. Fioretti wrote:
On Sun, Apr 20, 2014 14:11:24 PM +0800, Ed Greshko wrote:
I don't know how the system sets this value. 8192 seems rather small to me.
good point, thanks. This, in fact, is a side question that I forgot to ask in my original email: what are the criteria or rule of thumb to calculate which value of max_user_watches is sensible? Does it depend on number of files, RAM amount, what else?
And there is nothing in my sysctl.conf to override.
same here, but I understand that I should __ADD__ that setting at the end of the file. But this is another point on which I am seeking confirmation/feedback, instead of risking to stop work for a day to fix some problem...
Marco
Well.... As I noted, my 1GB VM F20 system has a value of 524288. I can't see how upping that value on your system will damage anything. In the little searching I also did on that issue I see some folks with 1M+ for that value.
One "silly" question.....
What version of Fedora are you running..... I found a message on the mailing lists back in 2010 which, from a reliable source, indicated....
kde packagers received a request to consider shipping systems with a higher (default) value of /proc/sys/fs/inotify/max_user_watches to allow for a better experience for noticing changes (notably when using nepomuk indexing of content in users' homedir).
The suggested value was something like 524288 (seems the default on f13 is 8192).
On Sun, Apr 20, 2014 14:40:07 PM +0800, Ed Greshko wrote:
One "silly" question.....
What version of Fedora are you running..... I found a message on the mailing lists back in 2010 which, from a reliable source, indicated....
this is happening on an F17 box. It **is** scheduled to be moved (full reinstall, not update) to F20 in a couple of weeks, but for reasons not really relevant here it has to stay F17 until then :-(
Marco
kde packagers received a request to consider shipping systems with a higher (default) value of /proc/sys/fs/inotify/max_user_watches to allow for a better experience for noticing changes (notably when using nepomuk indexing of content in users' homedir).
The suggested value was something like 524288 (seems the default on f13 is 8192).
-- Getting tired of non-Fedora discussions and self-serving posts -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 04/20/14 15:08, M. Fioretti wrote:
On Sun, Apr 20, 2014 14:40:07 PM +0800, Ed Greshko wrote:
One "silly" question.....
What version of Fedora are you running..... I found a message on the mailing lists back in 2010 which, from a reliable source, indicated....
this is happening on an F17 box. It **is** scheduled to be moved (full reinstall, not update) to F20 in a couple of weeks, but for reasons not really relevant here it has to stay F17 until then :-(
FWIW, everything I've seen indicates this value is not calculated but configured when the kernel is compiled. I just happen to have an old F17 disk and created a VM.
As expected, it is set to 8192.
On Sun, Apr 20, 2014 16:24:08 PM +0800, Ed Greshko wrote:
On 04/20/14 15:08, M. Fioretti wrote:
FWIW, everything I've seen indicates this value is not calculated but configured when the kernel is compiled. I just happen to have an old F17 disk and created a VM. As expected, it is set to 8192.
ok that's why then. So the only thing I need, if anything, is further confirmation that increasing it on F17 would not cause problems. I'll wait until tomorrow for further comments and then "risk" the increase :-) Marco
On 04/20/14 16:28, M. Fioretti wrote:
ok that's why then. So the only thing I need, if anything, is further confirmation that increasing it on F17 would not cause problems. I'll wait until tomorrow for further comments and then "risk" the increase :-)
FWIW, I just made the change in /etc/sysctl.conf to up it to 524288, rebooted, and everything seems to be working as normal.
On Sun, Apr 20, 2014 16:47:01 PM +0800, Ed Greshko wrote:
On 04/20/14 16:28, M. Fioretti wrote:
ok that's why then. So the only thing I need, if anything, is further confirmation that increasing it on F17 would not cause problems. I'll wait until tomorrow for further comments and then "risk" the increase
confirmed that changing it and rebooting works
Thanks, Marco
On 20 April 2014 10:28, M. Fioretti mfioretti@nexaima.net wrote:
On Sun, Apr 20, 2014 16:24:08 PM +0800, Ed Greshko wrote:
On 04/20/14 15:08, M. Fioretti wrote:
FWIW, everything I've seen indicates this value is not calculated but configured when the kernel is compiled. I just happen to have an old F17 disk and created a VM. As expected, it is set to 8192.
ok that's why then. So the only thing I need, if anything, is further confirmation that increasing it on F17 would not cause problems. I'll wait until tomorrow for further comments and then "risk" the increase :-) Marco --
M. Fioretti http://mfioretti.com http://stop.zona-m.net
Your own civil rights and the quality of your life heavily depend on how software is used *around* you
The value of fs.inotify.max_user_watches was increased in F18, and later releases, due to this bug[1] in nepomuk. It's configured by /usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf which is installed by nepomuk-core, so ideally you'd get that value if you have KDE or installed a package that pulled nepomuk-core as a dependency.
[1]https://bugzilla.redhat.com/show_bug.cgi?id=858271
On 04/20/14 20:51, Ahmad Samir wrote:
The value of fs.inotify.max_user_watches was increased in F18, and later releases, due to this bug[1] in nepomuk. It's configured by /usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf which is installed by nepomuk-core, so ideally you'd get that value if you have KDE or installed a package that pulled nepomuk-core as a dependency.
Thanks for that. I should have know to check that directory.
On 04/20/14 20:51, Ahmad Samir wrote:
The value of fs.inotify.max_user_watches was increased in F18, and later releases, due to this bug[1] in nepomuk. It's configured by /usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf which is installed by nepomuk-core, so ideally you'd get that value if you have KDE or installed a package that pulled nepomuk-core as a dependency.
I have another question......
I just did a "yum erase nepomuk-core" on a system and /usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf was removed since it was owned by nepomuk-core.
Upon reboot of the system ....
[egreshko@f20kde ~]$ ls /usr/lib/sysctl.d/ 00-system.conf 50-default.conf libvirtd.conf [egreshko@f20kde ~]$ cat /proc/sys/fs/inotify/max_user_watches 524288
So, it seems that file isn't really needed in F20 at this time to raise the limit?
On 20 April 2014 15:15, Ed Greshko ed.greshko@greshko.com wrote:
On 04/20/14 20:51, Ahmad Samir wrote:
The value of fs.inotify.max_user_watches was increased in F18, and later
releases, due to this bug[1] in nepomuk. It's configured by /usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf which is installed by nepomuk-core, so ideally you'd get that value if you have KDE or installed a package that pulled nepomuk-core as a dependency.
I have another question......
I just did a "yum erase nepomuk-core" on a system and /usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf was removed since it was owned by nepomuk-core.
Upon reboot of the system ....
[egreshko@f20kde ~]$ ls /usr/lib/sysctl.d/ 00-system.conf 50-default.conf libvirtd.conf [egreshko@f20kde ~]$ cat /proc/sys/fs/inotify/max_user_watches 524288
So, it seems that file isn't really needed in F20 at this time to raise the limit?
/usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf is included in the initramfs by dracut when a kernel is installed/updated. Check `lsinitrd /boot/initramfs-$(uname -r).img | grep sysctl`.
So in effect you'd have to re-create the initramfs after uninstalling nepomuk-core to make that custom setting go away completely.
On 04/20/14 21:38, Ahmad Samir wrote:
/usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf is included in the initramfs by dracut when a kernel is installed/updated. Check `lsinitrd /boot/initramfs-$(uname -r).img | grep sysctl`.
So in effect you'd have to re-create the initramfs after uninstalling nepomuk-core to make that custom setting go away completely.
Duh!
On Apr 20, 2014 6:46 PM, "Ed Greshko" ed.greshko@greshko.com wrote:
On 04/20/14 20:51, Ahmad Samir wrote:
The value of fs.inotify.max_user_watches was increased in F18, and
later releases, due to this bug[1] in nepomuk. It's configured by /usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf which is installed by nepomuk-core, so ideally you'd get that value if you have KDE or installed a package that pulled nepomuk-core as a dependency.
I have another question......
I just did a "yum erase nepomuk-core" on a system and
/usr/lib/sysctl.d/97-kde-nepomuk-filewatch-inotify.conf was removed since it was owned by nepomuk-core.
Upon reboot of the system ....
[egreshko@f20kde ~]$ ls /usr/lib/sysctl.d/ 00-system.conf 50-default.conf libvirtd.conf [egreshko@f20kde ~]$ cat /proc/sys/fs/inotify/max_user_watches 524288
So, it seems that file isn't really needed in F20 at this time to raise
the limit?
-- Getting tired of non-Fedora discussions and self-serving posts -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Nepomuk has been deprecated in favor of Baloo. Wonder if KDE guys still plan to ship the higher limit.
-
Ahmad Samir -
Ed Greshko -
M. Fioretti -
Sudhir Khanger