Hi Michael, thanks for the hints. Unfortunately, the log dir and logs all belong to condor:condor. But interestingly, the message still pops up endlessly, when moving the ShadowLog to the ram disk [1]?! Cheers, Thomas [1] root@grid-arcce1: [~] tail -F /dev/shm/ShadowLog 02/05/20 10:25:10 (20489576.0) (3710922): File transfer completed successfully. 02/05/20 10:25:10 (20489576.0) (3710922): WriteUserLog checking for event log rotation, but no lock 02/05/20 10:25:10 (20489576.0) (3710922): WriteUserLog checking for event log rotation, but no lock On 04/02/2020 17.39, Michael Pelletier via HTCondor-users wrote: > Hey Thomas, > > Check to see if someone changed the permissions of /var/log/condor to root:root instead of condor:condor. The ShadowLog is created and written as condor:condor, so if some overzealous security remediation script locked down /var/log/condor, that'd prevent it from being created, and if it changed the ownership of the ShadowLog file to root:root, it would prevent access to it. > > On systems where I have this problem due to a strict and militant interpretation of security configuration standards for /var/log, or where the audit subsystem records a failure warning every time a user-owned shadow (run_as_owner=True) attempts to write to it and causes a raft of spurious audit fail events, I change the SHADOW_LOG configuration to point to /dev/shm/ShadowLog instead, or just discard it. > > Michael V. Pelletier > Information Technology > Digital Transformation & Innovation > Integrated Defense Systems > Raytheon Company > > > _______________________________________________ > HTCondor-users mailing list > To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a > subject: Unsubscribe > You can also unsubscribe by visiting > https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users > > The archives can be found at: > https://lists.cs.wisc.edu/archive/htcondor-users/ >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature