Here's an example from my laptop with trackerd running (example uses gnome-packagekit): [patrys@meaw SPECS]$ cat /proc/sys/fs/inotify/max_user_watches 8192 [patrys@meaw SPECS]$ POLKIT_DEBUG=1 gpk-update-viewer 21:56:39.232: Using policy files from directory /usr/share/PolicyKit/policy 21:56:39.232: failed to add watch on file '/etc/PolicyKit/PolicyKit.conf': No space left on device [WARN 2673] polkit-error.c:143:polkit_error_get_error_message(): error != NULL trackerd quickly saturates all the inotify watches, once it happens polkit-based apps no longer work.
Uhm, so you're saying every app using inotify should handle cases where inotify is not available? FWIW, I don't think so, I think the culprit is either trackerd or perhaps the way inotify works. Either way, with the polkit rewrite currently underway the client libraries won't be using inotify.
Please, no offense. What I'm saying is inotify is a limited resource per definition and inotify failing should not be critical to application startup :)
(In reply to comment #2) > Please, no offense. Oh, none taken. > What I'm saying is inotify is a limited resource per > definition and inotify failing should not be critical to application startup :) In this case, how PolicyKit currently works and all, the security model relies on the client being notified when the set of authorizations changes. So the right answer here is to just bail out. FWIW, this is going to be different with the PolicyKit rewrite that is in progress (listening to system daemon instead). But, really, someone needs to fix either trackerd or inotify (preferably both though it's hard to avoid having limits when it comes to inotify). I mean, what happens is that trackerd is effectly DOS'ing the user account by going to the limit. And if you look at the whole desktop stack wrt. how file monitoring is used (watching desktop files, mime types), things are going to stop working in really weird ways if inotify craps out like this. Hoping you agree it's fine to close as NOTOURBUG.
(In reply to comment #3) > In this case, how PolicyKit currently works and all, the security model relies > on the client being notified when the set of authorizations changes. Btw, just to make it clear: even if inotify is not available the security model of polkit is still sound (since the mechanism running as root of course checks too). But it does mean that the client UI won't get updated (e.g. buttons won't change sensitivity etc.) when the authorizations change.
Sure, I mean it's fine if PolKit behaves weird but it should not die as it would be easy for one malicious client (even if trackerd behaves nicely it is still trivial to just create one million empty files and watch them) to DoS the whole desktop as more and more applications depend on libpolkit and none of us wouls like to have to deal with all the bugs (speaking on behalf of downstream here) :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.