Actually, the solution we have for now, which I need to put into the bugReally weird. This looks like a classic deadlock. This would happen if the Sharity daemon wants to access data in the /CIFS directory or any other mount served by itself. The daemon would wait for itself to answer an NFS query. Most Unix operating systems leave processes in an unkillable state while they wait for a reply to an NFS query.
report is this:
1. Un-mount the Sharity file systems using the Unix umount command (not the
sharity umount command) like this:
umount -f /CIFS
2. Find the PID for the daemon
3. Kill this PID
4. Restart
For whatever reason, the Sharity daemon will not accept any requests
(dealock maybe) and therefore does not accept any system messages (I'm
guessing here). Therefore, for whatever reason, unmount the Unix mount
forcibly causes the daemon to begin accepting messages again.
Weird.
The question is, why the Sharity daemon would want to access a file on a Sharity mount. The only files accessed directly from the daemon are the database and configuration files in /usr/local/sharity, which are NOT served by Sharity. An other possible access is when you mount something. Sharity accesses the mount point, but it forks a separate process for this to avoid the deadlock. So this should not be the cause either.
An other possible explanation would be a bug (or at least unconventional implementation) in the operating system kernel. If file accesses lock each other, the kernel may lock Sharity's access to a config file while an other process waits for data on a Sharity mount. This is considered a bug by most operating system vendors, because such an unnecessary dependence may slow down access to ordinary files to the speed of concurrent NFS requests. We know that such a problem exists in the Mac OS X kernel since version 10.1.4 (I think).
We were able to work around the problem on Mac OS X by reducing file accesses by the daemon to the absolute minimum (which is: writing database files when a configuration changes). You can disable the routine checks for database and config files by changing the options "cfgParseInterval" and "databaseParseInterval" both to 0 in sharity.cfg. With these automatic checks disabled, you need to send the daemon a HUP signal to force re-reading of files when you edit them.
Hope this helps...
Regards, Christian.
--
Dipl.-Ing. Christian Starkjohann
Objective Development
mailto:cs@;obdev.at | http://www.obdev.at/
_______________________________________________
Sharity-talk mailing list
[EMAIL PROTECTED]
To unsubscribe see http://at.obdev.at/mailman/listinfo/sharity-talk
