SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264
|Anonymous | Login||2019-11-13 16:47 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002644||Endian Firewall||Other Scripts||public||2010-01-28 14:28||2010-09-21 18:33|
|Target Version||future||Fixed in Version|
|Summary||0002644: synchronization issues in endian.core.notification module|
|Description||StatusFileMutex.__init__() removes the mutex file if it does already exist|
StatusFile.close() removes the mutex file after releasing the lock.
what if another process (B) acquired a lock on the mutex file held by process A? That process stored already the filehandle and blocks until A releases. When process C removes the file, before acquire(), C can create a new file which is not more blocked by A. The file blocked by A is removed from the filesystem, but the filedescriptor is still open and A can write to it.
When A closes that filedescriptor, process B will be able to open it and continue operations on it. But that is not more the same file as we see in the filesystem.
In that case 2 processes with the same lockfile are running but only 1 lockfile is visible in filesystem.
That's no mutex
|Tags||No tags attached.|
|2010-01-28 14:28||peter-endian||New Issue|
|2010-09-21 18:33||peter-endian||Status||new => confirmed|
|Copyright © 2000 - 2012 MantisBT Group|