-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins 2.332.2
Audit Trail plugin 3.10
This is very similar to https://issues.jenkins.io/browse/JENKINS-44129, which appears to have not been fixed after all.
In our environment, we use LogFileAuditLogger and also maintain our whole config in YAML (CasC plugin), reloading it when we make changes.
It appears that every time we reload the configuration, LogFileAuditLogger ends up creating a couple new files and associated locks.
Let's say we start with this:
$ ls -la /jenkins/logs/audit total 0 drwxr-xr-x 2 foo foo 140 Jul 26 12:56 . drwxr-xr-x 5 foo foo 72 Apr 20 16:12 .. -rw-r--r-- 1 foo foo 0 Jul 26 12:55 audit-0.log -rw-r--r-- 1 foo foo 0 Jul 26 12:56 audit-0.log.1 -rw-r--r-- 1 foo foo 0 Jul 26 12:56 audit-0.log.1.lck -rw-r--r-- 1 foo foo 0 Jul 26 12:56 audit-0.log.2 -rw-r--r-- 1 foo foo 0 Jul 26 12:56 audit-0.log.2.lck -rw-r--r-- 1 foo foo 0 Jul 26 12:55 audit-0.log.lck
Then after one configuration reload we get this:
$ ls -la /jenkins/logs/audit total 8 drwxr-xr-x 2 foo foo 232 Jul 26 13:00 . drwxr-xr-x 5 foo foo 72 Apr 20 16:12 .. -rw-r--r-- 1 foo foo 0 Jul 26 12:55 audit-0.log -rw-r--r-- 1 foo foo 0 Jul 26 12:56 audit-0.log.1 -rw-r--r-- 1 foo foo 0 Jul 26 12:56 audit-0.log.1.lck -rw-r--r-- 1 foo foo 612 Jul 26 12:59 audit-0.log.2 -rw-r--r-- 1 foo foo 0 Jul 26 12:56 audit-0.log.2.lck -rw-r--r-- 1 foo foo 0 Jul 26 13:00 audit-0.log.3 -rw-r--r-- 1 foo foo 0 Jul 26 13:00 audit-0.log.3.lck -rw-r--r-- 1 foo foo 217 Jul 26 13:00 audit-0.log.4 -rw-r--r-- 1 foo foo 0 Jul 26 13:00 audit-0.log.4.lck -rw-r--r-- 1 foo foo 0 Jul 26 12:55 audit-0.log.lck
And so on, and so on, files are added after each config reload.
Java's FileHandler has a hard-coded limit for MAX_LOCKS, which is 100. Once you reach that, the Audit Trail plugin stops working altogether and throws:
SEVERE h.p.a.LogFileAuditLogger#configure: Couldn't configure the plugin, you should report this issue java.io.IOException: Couldn't get lock for /jenkins/logs/audit/audit-%g.log at java.logging/java.util.logging.FileHandler.openFiles(FileHandler.java:491) at java.logging/java.util.logging.FileHandler.<init>(FileHandler.java:451) at java.logging/java.util.logging.FileHandler.<init>(FileHandler.java:409) at hudson.plugins.audit_trail.LogFileAuditLogger.configure(LogFileAuditLogger.java:109)
What I also noticed is that the lock files are not cleaned up after I restart Jenkins.
The cleanup routine that was added as part of fix to https://issues.jenkins.io/browse/JENKINS-44129 seems to work fine in the unit tests, see output from this slightly modified test:
public void configuringAFileLoggerWithNonExistingParents() throws IOException {
Path logFile = folder.getRoot().toPath().resolve("subdirectory").resolve("file");
LogFileAuditLogger l = new LogFileAuditLogger(logFile.toString(), 5, 1, null);
Assert.assertTrue(logFile.toFile().exists());
System.out.println("--- Before cleanup ---");
Files.list(folder.getRoot().toPath().resolve("subdirectory")).forEach(System.out::println);
l.cleanUp();
System.out.println("--- After cleanup ---");
Files.list(folder.getRoot().toPath().resolve("subdirectory")).forEach(System.out::println);
Output:
--- Before cleanup --- /tmp/junit15417480884372762097/subdirectory/file.lck /tmp/junit15417480884372762097/subdirectory/file --- After cleanup --- /tmp/junit15417480884372762097/subdirectory/file
But even though it works in the test, it doesn't appear to be called in the deployed plugin.
- is blocked by
-
-
- Resolved
-