Bug: logrotate config conflict between waagent and azuremonitorlinuxagent

[johncrim]

After upgrading to AzureMonitorLinuxAgent 1.35 (from 1.33) I'm getting logrotate failures. Eg:

me@vms0:/etc/logrotate.d$ systemctl list-units --failed
  UNIT              LOAD   ACTIVE SUB    DESCRIPTION     
● logrotate.service loaded failed failed Rotate log files

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
1 loaded units listed.
me@vms0:/etc/logrotate.d$ systemctl status logrotate.service
× logrotate.service - Rotate log files
     Loaded: loaded (/lib/systemd/system/logrotate.service; static)
     Active: failed (Result: exit-code) since Mon 2025-07-21 16:48:13 UTC; 1h 16min ago
TriggeredBy: ● logrotate.timer
       Docs: man:logrotate(8)
             man:logrotate.conf(5)
    Process: 1222476 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=1/FAILURE)
   Main PID: 1222476 (code=exited, status=1/FAILURE)
        CPU: 36ms

Jul 21 16:48:13 vms0 systemd[1]: Starting Rotate log files...
Jul 21 16:48:13 vms0 logrotate[1222476]: error: waagent-extn.logrotate:1 duplicate log entry for /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/CommandExecution.log
Jul 21 16:48:13 vms0 logrotate[1222476]: error: found error in file waagent-extn.logrotate, skipping
Jul 21 16:48:13 vms0 systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Jul 21 16:48:13 vms0 systemd[1]: logrotate.service: Failed with result 'exit-code'.
Jul 21 16:48:13 vms0 systemd[1]: Failed to start Rotate log files.

The cause appears to be (I'm not a logrotate expert) that the same files are being rotated by 2 configs:

me@vms0:/etc/logrotate.d$ cat waagent-extn.logrotate 
/var/log/azure/*/*.log {
    # Old versions of log files are compressed with gzip by default.
    compress

    # Rotate log files > 10 MB, and keep last 10 archived files. With an compression ratio ranging from 5-10%, The
    # archived files would take an average of around 5-10 MB.
    size 10M
    rotate 10

    # Add date as extension when rotating logs
    dateext

    # Formatting the date extension to YYYY-MM-DD-SSSSSSS format. logrotate does not provide hours, mins and seconds
    # option. Adding the %s (system clock epoch time) to differentiate rotated log files within the same day.
    dateformat -%Y-%m-%d-%s

    # Do not rotate the log if it is empty
    notifempty

    # If the log file is missing, go on to the next one without issuing an error message.
    missingok
}
me@vms0:/etc/logrotate.d$ cat azuremonitoragentextension 
/var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/extension.log
{
    copytruncate
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    size 10M
}
/var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/CommandExecution.log
{
    copytruncate
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    size 10M
}
/var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/telegraf.log
{
    copytruncate
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    size 10M
}

The file /etc/logrotate.d/azuremonitoragentextension wasn't present on the VMs until I upgraded the AzureMonitorLinuxAgent VM extension to version 1.35 (from 1.33).

[bpickhardt]

Seeing the exact same behavior. I have found that backing up the new file azuremonitoragentextension to my home folder and removing it from /etc/logrotate.d resolves the error with logrotate but the file recreated itself the first time I did that. I have since disabled auto-update on the VM extension to see if that prevents it from automatically recreating itself.

Edit: 1 week later the file restored itself. At this point I may need to create a cron task to clear the bad file to allow logrotate.d to function on the server.

[johncrim]

This appears to be fixed by upgrading to AzureMonitorLinuxAgent 1.37. I saw the error pre-upgrade, and so far I don't see it after.

Nice of Microsoft people to comment on this and let us know when it was fixed...