#41 inotify thread aborts

pre 0.12 SVN
closed-fixed
Leo
General (19)
1
2010-04-06
2008-10-12
yura
No

Hi!

I see the following behaviour in MT 0.11.0:

When configuring a directory for inotify as scanning option and the directory has one or more subdirectories which can not be watched by the MT user (e.g. lost+found which can be only accessed with UID 0) the thread will abort with the log line (caused in AutoscanInotify::threadProc() line 335):

...
ERROR: Inotify thread caught exception: no permission
...

The result is that the directory is no longer watched and no changes are recorded.

A possible solution would be to log the name of the offending directory in the log file and proceed with adding watches where it is possible.

Yours,
yura

Discussion

  • Jin

    Jin - 2008-10-12

    Leo, did you fix this already in svn or is it still valid?

     
  • Jin

    Jin - 2008-10-12
    • assigned_to: jin_eld --> lww
     
  • Klaus S. Madsen

    Klaus S. Madsen - 2008-11-14

    The patch attached in bug 2088696 solves this problem for me.

     
  • Jin

    Jin - 2008-11-23

    Hmm, well, we tried it without your patch today (wanted to reproduce the problem before testing the patch). We can't reproduce the problem... the thread will catch an exception when adding a directory (so the watch for that particular directory for which we do not have appropriate permissions is not added), but besides that everything seems to work and continues to work...

    How exactly can we reproduce the problem?

     
  • yura

    yura - 2008-11-25

    Hi!

    For me it happened when I added a mount point as inotify-monitored directory.
    It failed on the 'lost+found' directory of the ext3 filesystem - owner UID 0, permission 700.

    The log line is dumped and no further changes are noticed for this location...

     
  • yura

    yura - 2009-08-13

    Hi!

    I have rebuilt mediatomb using the patch from bug 2088696 and now it works flawlessly - thanks for the tip hjernemadsen!
    So I can also confirm that this solves the problem - at least for me.

    I have furthermore just checked the SVN codebase. The implementation is still as of 0.11 - so currently it won't work.

    Yours,
    Yura

     
  • Jin

    Jin - 2009-12-21
    • milestone: 814929 --> pre 0.12 SVN
    • status: open --> open-accepted
     
  • Jin

    Jin - 2009-12-21
    • priority: 5 --> 6
     
  • Leo

    Leo - 2009-12-21

    fixed with r2032

     
  • Leo

    Leo - 2009-12-21
    • status: open-accepted --> open-fixed
     
  • Leo

    Leo - 2009-12-21
    • priority: 6 --> 1
     
  • Jin

    Jin - 2010-04-06
    • status: open-fixed --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks