Score:0

Server

Logrotate Service Failure

Maestro223

10/8/22, 9:35 AM

My logrotate service failes. It complains about a duplicate entry for modsecurity.

 ● logrotate.service - Rotate log files
       Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
       Active: failed (Result: exit-code) since Tue 2021-06-08 14:22:07 CST; 2h 54min ago
         Docs: man:logrotate(8)
               man:logrotate.conf(5)
     Main PID: 15370 (code=exited, status=1/FAILURE)
    
    Jun 08 14:22:07 server1.example.com systemd[1]: Starting Rotate log files...
    Jun 08 14:22:07 server1.example.com logrotate[15370]: error: modsecurity:1 duplicate log entry for /var/log/apache2/modsec_audit.log
    Jun 08 14:22:07 server1.example.com logrotate[15370]: error: found error in file modsecurity, skipping
    Jun 08 14:22:07 server1.example.com systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
    Jun 08 14:22:07 server1.example.com systemd[1]: logrotate.service: Failed with result 'exit-code'.
    Jun 08 14:22:07 server1.example.com systemd[1]: Failed to start Rotate log files.

However, /etc/logrotate.d/modsecurity doesn't contain any duplicates:

/var/log/apache2/modsec_audit.log
{
        rotate 14
        daily
        missingok
        compress
        delaycompress
        notifempty
}

Any thought?

UPDATE:

#grep -r 'modsec_audit.log' /etc/

/etc/logrotate.d/modsecurity:/var/log/apache2/modsec_audit.log
/etc/modsecurity/modsecurity.conf:SecAuditLog /var/log/apache2/modsec_audit.log
/etc/modsecurity/modsecurity.conf-recommended:SecAuditLog /var/log/apache2/modsec_audit.log

So I went through:

 /etc/modsecurity/modsecurity.conf:SecAuditLog /var/log/apache2/modsec_audit.log
 /etc/modsecurity/modsecurity.conf-recommended:SecAuditLog /var/log/apache2/modsec_audit.log

and hashed out the modsec_audit.log values, as below

#SecAuditLogType Serial
#SecAuditLog /var/log/apache2/modsec_audit.log

then ran:
systemctl restart logrotate

Same error

UPDATE 2:

Following @Nikita Kipriyanov advice, I went through and completely hashed out /etc/logrotate.d/modsecurity and now logrotate executes successfully (all mdosec logs hashed out):

#systemctl status logrotate ● logrotate.service - Rotate log files Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled) Active: inactive (dead) since Thu 2021-06-10 09:36:53 CST; 52s ago Docs: man:logrotate(8) man:logrotate.conf(5) Process: 20308 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=0/SUCCESS) Main PID: 20308 (code=exited, status=0/SUCCESS)

Jun 10 09:36:52 tester1.example.com systemd[1]: Starting Rotate log files...
Jun 10 09:36:53 tester1.example.com systemd[1]: logrotate.service: Succeeded.
Jun 10 09:36:53 tester1.example.com systemd[1]: Started Rotate log files.

So I enabled the original modsec_audit.log located at /etc/modsecurity/modsecuirty.confto see what would happen. Again, things seem to work correctly

systemctl status logrotate

● logrotate.service - Rotate log files Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled) Active: inactive (dead) since Thu 2021-06-10 09:54:05 CST; 4s ago Docs: man:logrotate(8) man:logrotate.conf(5) Process: 21452 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=0/SUCCESS) Main PID: 21452 (code=exited, status=0/SUCCESS)

Jun 10 09:54:05 tester1.example.com systemd[1]: Starting Rotate log files... Jun 10 09:54:05 tester1.example.com systemd[1]: logrotate.service: Succeeded. Jun 10 09:54:05 tester1.example.com systemd[1]: Started Rotate log files.

Same story for /etc/modsecurity/modsecurity-recommended, meaning that the logrotate service only fails when I use
/etc/logrotate.d/modsecuirty and the collision has to be a wildcard as suggested by @Nikita Kipriyanov

1887

2 + 3

linux

logrotate

Michael Hampton

10/8/22, 9:48 AM

Find the other file that it is defined in.

Nikita Kipriyanov

10/9/22, 2:09 PM

Notice the duplicate entry may be a wildcard. It could be pointless to search exactly for `modsec_audit`. This could be checked by disabling *known* offending file and if everything starts after that then there *is* a collision.

Maestro223

10/10/22, 2:12 AM

@NikitaKipriyanov You were correct the collision has to be a wildcard, I showed the work in the post above. How do I fix the collision?

Score:2

Server

Nikita Kipriyanov

10/10/22, 7:43 AM

So, the file /var/log/apache2/modsec_audit.log is set up to be rotated by the /etc/logrotate.d/modsecurity and some other file, which covers it with a wildcard. For example, that might be defined as /var/log/apache2/*log, which of course includes this file. I don't know which other logrotate configuration files you have, but chances are high that it is /etc/logrotate.d/apache2 or something like that has a wildcard.

Therefore, the /var/log/apache2/modsec_audit.log will be rotated even if you remove /etc/logrotate.d/modsecurity. Or better, replace it with an empty file (or a file with just a comment containing a link to this SF question and answer to easy remember what's happened). This is simplest near-time solution for a problem. Other way, you might want to remove /var/log/apache2/modsec_audit.log from being catched with the wildcard; there is no way to set excludes to wildcards in logrotate, so you'd end up with rewriting the wildcard(s) so it'll include all files except this one. I consider this cumbersome.

Also remember, /etc/logrotate.d/modsecurity and the other logrotate configurations likely were installed by some OS packages. Those files will be reinstalled when you update those packages. While removed file will be just put again into place, the the edited file won't. The configuration file protection will kick in and at least you'll have a notice about updated configuration and the prompt to resolve by hand. So "create an empty file" is counted as an edit and will save you some hair.

And, to resolve this completely and forever, you should discover which packages these clashing files belong to, and file a bug into your distribution's bug tracker. You may convince them to fix packages so updates wouldn't contain these files or these files wouldn't clash, so nothing breaks after update.

0 + 0

Score:1

Server

p10l

10/8/22, 1:01 PM

Most probably you have duplicate entry defined in another file.
Check /etc/logrotate.conf file for duplicates, if there are none in this file issue

grep -rnw '/etc/logrotate.d/' -e 'modsec_audit.log'

to find duplicates in other files.

You can also try looking in /etc/logrotate.d/rsyslog file:

grep 'modsec_audit.log' /etc/logrotate.d/rsyslog

You may find duplicates there.

0 + 7

Maestro223

10/8/22, 4:39 PM

Thanks for the reply. I am a bit confused on how to proceed based the output of `grep -rnw '/etc/logrotate.d/' -e 'modsec_audit.log``, which is `/etc/logrotate.d/modsecurity:1:/var/log/apache2/modsec_audit.log `

p10l

10/8/22, 4:47 PM

I edited my answer and added another way to find duplicates. See if it helps.

p10l

10/8/22, 4:56 PM

Also `/etc/logrotate.conf` may include other files with `include` directive. Make sure there are no duplicates in included files.

Maestro223

10/9/22, 1:08 AM

I added the output of `#grep -r 'modsec_audit.log' /etc/` to my post. I don't see (or don't understand) where a duplicate could be.

p10l

10/9/22, 5:16 AM

Well, there you have it. Three duplicates. One in `/etc/logrotate.d/modsecurity`, one in `/etc/modsecurity/modsecurity.conf` and one in `/etc/modsecurity/modsecurity.conf-recommended`. Remove two of those and restart logrotate service.

Maestro223

10/9/22, 5:47 AM

That is what I thought as well, so I went through and hashed out `modsec_audit.log` from the bottom 2 file listed above, only leaving `/etc/logrotate.d/modsecurity:/var/log/apache2/modsec_audit.log`. Then restarted the logrotate service... same error :-/ I will show the work above, in a few minutes.

Maestro223

10/9/22, 5:53 AM

Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/126251/discussion-between-yupthatguy-and-pawel-grondal).

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Logrotate Service Failure

TH: Logrotate Service Failure

RO: Logrotate Service Failure

RU: Logrotate Service Failure

VI: Logrotate Service Failure

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.