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
