Univention Bugzilla – Bug 56906
Univention Management Console Server Fails to Release File Handles After Log Rotation
Last modified: 2024-04-24 14:56:09 CEST
Critical Bug Report: Univention Management Console Server Fails to Release File Handles After Log Rotation Description: The customer has identified a critical issue with the Univention Management Console (UMC) Server on the Primary DC. This issue has been observed twice in the last few weeks, where the UMC Server retains hundreds of open file handles for already rotated log files, causing the /var/log directory to fill up. Reproduction Steps: Execute the following command to identify the number of open file handles for deleted log files: root@nayru:~# lsof 2>/dev/null | grep '/var/log/univention/management.*deleted' | wc -l The result shows 862 open file handles. Check the Multithreading configuration of the UMC Server: root@nayru:~# ucr get umc/server/processes The Multithreading configuration is set to 15. The customer suspects that the issue may be related to the Multithreading configuration of the UMC, which is not active on any other UCS system. The customer suggests checking if a similar result can be obtained with a Multithreaded UMC-Server after log rotation. After restarting the UMC-Server, the customer observed a release of 27GB of memory. Issue Details: The problem seems to be associated with the Multithreading configuration of the UMC Server. The log file /var/log/univention/management-console-server.log.1 appears to be specifically affected. Despite log rotation, the UMC Server retains file handles on already rotated (compressed) log files and continues logging into them until the UMC process is terminated. SIGHUP signals sent to the UMC Server after log rotation do not seem to take effect. Reproduction on another System: The issue has been successfully reproduced on another system with the following steps: 1. Set Multithreading configuration: ucr set umc/server/processes=3 umc/http/processes=3 2. Restart the UMC Service: service univention-management-console-server restart 3. Force log rotation: logrotate -f /etc/logrotate.d/univention-management-console 4. Check for open file handles: lsof 2>/dev/null | grep '/var/log/univention/management.*deleted' 5. The result shows open file handles for the deleted log file /var/log/univention/management-console-server.log.1. Impact: The UMC Server continues writing to a deleted and growing file until the next restart. Logs written during this period are lost permanently. The customer experienced a loss of all logs in the specified log file since mid-October after a UMC restart on the Primary DC. Recommendation: We recommend investigating and addressing the issue with the Multithreading configuration and the failure of SIGHUP signals to release file handles after log rotation. This issue poses a significant risk of data loss and impacts the overall stability and reliability of the Univention Management Console Server.
I think I sae this yesterday in an other school env, wondering why the UMC ist running, but nothing in the logfile. Now an other customer reported, that we now cannot debug an important situation, because we do not have logs, so please fix this soon!
57143f3abb9f5163d108b1e7b701e4dd2ad6d590 - logrotate with copytruncate to not delete but truncate UMC logfiles successful build Package: univention-management-console Version: 12.0.33-6 Branch: 5.0-0 Scope: errata5.0-7 Successful build Package: ucs-test Version: 10.0.21-26 Branch: 5.0-0 Scope: errata5.0-7
OK: logrotate uses truncate now OK: Neither the main process, nor the modules continue to write logs to deleted files OK: YAML OK: Jenkins Verified
<https://errata.software-univention.de/#/?erratum=5.0x1032>