DropBox crashes on permission error
Posted: Mon May 18, 2015 12:59 pmHi,
our DropBox just crashed because of a directory permission error (which I corrected shortly thereafter). It would be much better if exceptions like this would be caught and not lead to a dysfunctional DropBox. I think the DropBox could recover from errors like this before v5.1.0 (we are currently using v5.1.1).
Cheers,
Tristan
EDIT:
I think the problem is somewhere in the fact that DropBox now immediatly watches every new directory. A script of ours creates new user directories inside $OMERODATA/DropBox as soon as a user tries to access this directory. The script also sets the correct permissions, but this is only done in a second step and the DropBox watch was added (apparently) in between. I changed this now in a way that the directories will have the proper permission at the moment of their creation, but it would (as mentioned above) be better if DropBox could recover from an error like this and check again after some time.
our DropBox just crashed because of a directory permission error (which I corrected shortly thereafter). It would be much better if exceptions like this would be caught and not lead to a dysfunctional DropBox. I think the DropBox could recover from errors like this before v5.1.0 (we are currently using v5.1.1).
Cheers,
Tristan
- Code: Select all
2015-05-18 13:23:15,861 WARNI [ stderr] (Thread-4 ) Exception in thread Thread-4:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/local/share/omero/OMERO.server-5.1.1-ice35-b43/lib/python/omero_ext/pyinotify.py", line 1411, in run
self.loop()
File "/usr/local/share/omero/OMERO.server-5.1.1-ice35-b43/lib/python/omero_ext/pyinotify.py", line 1397, in loop
self.process_events()
File "/usr/local/share/omero/OMERO.server-5.1.1-ice35-b43/lib/python/omero_ext/pyinotify.py", line 1198, in process_events
self._default_proc_fun(revent)
File "/usr/local/share/omero/OMERO.server-5.1.1-ice35-b43/lib/python/omero_ext/pyinotify.py", line 841, in __call__
return _ProcessEvent.__call__(self, event)
File "/usr/local/share/omero/OMERO.server-5.1.1-ice35-b43/lib/python/omero_ext/pyinotify.py", line 578, in __call__
return self.process_default(event)
File "/usr/local/share/omero/OMERO.server-5.1.1-ice35-b43/lib/python/fsPyinotifyMonitor.py", line 267, in process_default
pathModule.path(name).parent].getMask())
File "/usr/local/share/omero/OMERO.server-5.1.1-ice35-b43/lib/python/fsPyinotifyMonitor.py", line 166, in addWatch
for d in pathModule.path(path).dirs():
File "/usr/local/share/omero/OMERO.server-5.1.1-ice35-b43/lib/python/path.py", line 552, in dirs
return [p for p in self.listdir(pattern) if p.isdir()]
File "/usr/local/share/omero/OMERO.server-5.1.1-ice35-b43/lib/python/path.py", line 527, in listdir
names = os.listdir(self)
OSError: [Errno 13] Permission denied: '/srv/omero_data/DropBox/ttester'
2015-05-18 14:50:13,843 INFO [ fsserver.fsMonitorServer] (Dummy-7 ) Monitor id = a6d51912-fd42-11e4-8d2b-001e6752dcf8 stopped
2015-05-18 14:50:13,864 INFO [ fsserver.MonitorServer] (MainThread) Stopping OMERO.fs MonitorServer
EDIT:
I think the problem is somewhere in the fact that DropBox now immediatly watches every new directory. A script of ours creates new user directories inside $OMERODATA/DropBox as soon as a user tries to access this directory. The script also sets the correct permissions, but this is only done in a second step and the DropBox watch was added (apparently) in between. I changed this now in a way that the directories will have the proper permission at the moment of their creation, but it would (as mentioned above) be better if DropBox could recover from an error like this and check again after some time.