12:49 a.m.
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
--
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
1:09 a.m.
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
--
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
1:11 a.m.
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.
--
Getting tired of non-Fedora discussions and self-serving posts
1:23 a.m.
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.
--
Getting tired of non-Fedora discussions and self-serving posts
1:40 a.m.
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).
--
Getting tired of non-Fedora discussions and self-serving posts
2:08 a.m.
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(a)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
--
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
3:24 a.m.
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.
--
Getting tired of non-Fedora discussions and self-serving posts
3:28 a.m.
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
3:47 a.m.
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.
--
Getting tired of non-Fedora discussions and self-serving posts
7:51 a.m.
On 20 April 2014 10:28, M. Fioretti <mfioretti(a)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
--
Ahmad Samir
8:02 a.m.
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.
[1]https://bugzilla.redhat.com/show_bug.cgi?id=858271
Thanks for that. I should have know to check that directory.
--
Getting tired of non-Fedora discussions and self-serving posts
8:15 a.m.
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.
[1]https://bugzilla.redhat.com/show_bug.cgi?id=858271
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
8:38 a.m.
On 20 April 2014 15:15, Ed Greshko <ed.greshko(a)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.
>
> [1]https://bugzilla.redhat.com/show_bug.cgi?id=858271
>
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.
--
Ahmad Samir
8:39 a.m.
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!
--
Getting tired of non-Fedora discussions and self-serving posts
12:07 p.m.
On Apr 20, 2014 6:46 PM, "Ed Greshko" <ed.greshko(a)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.
>
> [1]https://bugzilla.redhat.com/show_bug.cgi?id=858271
>
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(a)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.
12:25 a.m.
New subject: CLOSED: advice needed before changing inotify max_user_watches
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
--
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
3663
days inactive
3667
days old
15 comments
4 participants
participants (4)
-
Ahmad Samir -
Ed Greshko -
M. Fioretti -
Sudhir Khanger