[kde-freebsd] QKqueueFileSystemWatcherEngine regression?

[Jason E. Hale]

On Thursday, September 13, 2012 16:45:16 Andriy Gapon wrote:
> on 05/09/2012 13:36 Andriy Gapon said the following:
> > I have a quite large photo collection managed with digikam.
> > After upgrading my machine after a long (couple of months) pause I am now
> > seeing the following when starting digikam:
> > 
> > QKqueueFileSystemWatcherEngine::addPaths: open: Too many open files
> > QFileSystemWatcher: failed to add paths: [scrubbed]
> > QKqueueFileSystemWatcherEngine::addPaths: open: Too many open files
> > ...
> > 
> > Lots of these messages.  digikam then crashes:
> > 
> > digikam(89741) KIO::SlavePrivate::SlavePrivate: Connection server not
> > listening, could not connect
> > 
> > GLib-ERROR **: Cannot create pipe main loop wake-up: Too many open files
> > 
> > aborting...
> > 
> > I have out-of-box limits on open files:
> > kern.maxfiles: 50000
> > kern.maxfilesperproc: 11095
> > 
> > I find it to be a problem that digikam now has to open all files in my
> > collection because of how QKqueueFileSystemWatcherEngine works.
> > 
> > Have I missed some UPDATING note or a package message about this?
> > 
> > I would prefer to not bump kern.maxfilesperproc to an arbitrarily large
> > value. Is there a knob to control filesystem-watcher behavior?
> 
> So, does anyone know what's the story here?

There was a discussion about this in this thread: 
http://mail.kde.org/pipermail/kde-freebsd/2012-June/013374.html

I added the workaround suggested in the thread to the Digikam port in area51.  
After some testing, I didn't see any difference in file manipulation detection 
and the "Too many open files" problem went away.

As far as I know, it might be caused by a Qt bug (#2478...Qt bugtracker is 
down right now, so I can't give a link).  IIRC, the bug was reported on OSX 
and was closed but not fixed.

Jason