Problem:
The AD Connector services (univention-ad-con_*) are observed to restart or stop repeatedly, typically occurring around midnight (00:00). In environments with multiple AD connector instances, these restarts may happen in very short intervals (seconds), leading to service instability or total failure.
Cause
This issue is caused by a misconfigured logrotate setting. When a wildcard is used to specify multiple log files (e.g., /var/log/univention/con_*.log) and a postrotate script is defined to restart the services, logrotate’s default behavior is to execute the postrotate script for every single file that matches the pattern and is rotated.
If multiple log files match the pattern, the restart command (e.g., systemctl try-restart univention-ad-con_*) is triggered multiple times in rapid succession. This creates a “restart storm” that prevents the services from remaining stable and available.
Solution
There are to ways to resolve this.
- Add the
sharedscriptsdirective to thelogrotateconfiguration file. This directive ensures that thepostrotatescript is executed only once at the end of the rotation cycle, regardless of how many files were rotated.
Example of problematic configuration:
In this example, the postrotate script runs for every .log file found.
/var/log/univention/con_*.log {
compress
create 640 root adm
missingok
notifempty
daily
maxsize 500M
rotate 12
postrotate
systemctl try-restart univention-ad-con_* > /dev/null
endscript
}
This would look like this:
/var/log/univention/con_*.log {
compress
create 640 root adm
missingok
notifempty
daily
maxsize 500M
rotate 12
sharedscripts
postrotate
systemctl try-restart univention-ad-con_* > /dev/null
endscript
}
- Solution, which comes with a better stability and predictability, it is recommended to explicitly list the services to be restarted in the
postrotatescript instead of using wildcards:
postrotate
systemctl try-restart univention-ad-con_service1.service > /dev/null
systemctl try-restart univention-ad-con_service2.service > /dev/null
endscript