Hi folks, Can someone explain the new-style locking to me (or at least point me to the design document)? I just upgraded to a bleeding-edge Condor and new-style locking started to be used for the first time. I saw lots of files being created in /tmp/condorLocks (which is inappropriate, that's what /var/lock/condor is for). Inside it, there are hundreds of files (after running the schedd for a few minutes, 2000+ total entries in the directory tree) and a lot of directories. The files are owned by many users and the directories (again, owned by many users) are world-writeable. Note - it would be very helpful if you could organize the locks by owner, instead of having an apparently random scheme. The semantics are probably identical, but it'll help sysadmins understand what's happening. I see a lot of errors in the ScheddLog along the lines of this: 12/17/10 09:45:11 (pid:5168) directory_util::rec_touch_file: File /tmp/condorLocks/29/85/0/285458.lockc cannot be created (Permission denied) 12/17/10 09:45:11 (pid:5168) directory_util::rec_touch_file: File /tmp/condorLocks/29/85/0/285458.lockc cannot be created (Permission denied) 12/17/10 09:45:11 (pid:5168) FileLock::FileLock: File locks cannot be created on local disk - will fall back on locking the actual file. 12/17/10 09:45:11 (pid:5168) Warning: Failed to open event rotation lock file /var/log/condor/EventLog.lock: 13 (Permission denied) I don't know what EUID is being used to create the lock file, so I don't know whether the Permission Denied errors are appropriate. The EventLog.lock issues aren't new, but the directory_util::rec_touch_file lines are new. I think the EventLog.lock has always been rotated with the wrong permissions in the most recent versions of Condor. So, there's lots of things happening, quite a few errors in the logs, but it appears the system is working. I would appreciate whatever background folks can provide. Brian
Attachment:
smime.p7s
Description: S/MIME cryptographic signature