Long filename errors in logrotate logs

Bug
#1

I don’t know if this is a bug or something else.

My logrotate seems to run properly, but every few months I get messages like this;
etc/cron.daily/logrotate:

error: failed to rename /var/log/roundcubemail/errors.log-20181216-20181217-20181218-20181219-20181220-20181221-20181222-20181223-20181224-20181225-20181226-20181227-20181228-20181229-20181230-20181231-20190101-20190102-20190103-20190104-20190105-20190106-20190107-20190108-20190109-20190110-20190111 to /var/log/roundcubemail/errors.log-20181216-20181217-20181218-20181219-20181220-20181221-20181222-20181223-20181224-20181225-20181226-20181227-20181228-20181229-20181230-20181231-20190101-20190102-20190103-20190104-20190105-20190106-20190107-20190108-20190109-20190110-20190111-20190112: File name too long

I usually just delete the file, the server seems fine otherwise. The logrotate errors seem to involve roundcube, letsencrypt, and openvpn log files

Looking at the logrotate scripts doesn’t offer any clues, they are stock yum installs.

Any insights would be appreciated!

#2

I seem to remember that the same issue appeared in the freepbx package on SME Server and that was fixed. The note of the fix should be in the changelog. I believe it had something to do with the rotate config.

HTH

#3

It’s happening because the wildcard specification for the logrotate for those products matches the logs already rotated as well as the ones needing to be.
This was fixed some time ago for OpenVPN (I thought), unless I’m still running my patched version:

[root@Nethserver ~]# cat /etc/logrotate.d/openvpn
/var/log/openvpn/*.log {
 missingok
 compress
 notifempty
 copytruncate
 create 0600 root root
}
[root@Nethserver ~]#

I’m surprised you include LetsEncrypt, as I didn’t believe that uses logrotate, as it has it’s own scheme to handle logs outside of logrotate.

Don’t use RoundCube.

Cheers.

#4

We don’t like RoundCube?
It works with my sieve scripts!
Thank you all for the support, I think I found the issue…

#5

I didn’t word that too well did I.

What I meant to say was that: I don’t use RoundCube. I wan’t passing on advice. :sunglasses:

Cheers.

#6

It sounds like a bug.

@stephdl can you reproduce on your machine? I will check on mine tomorrow.

1 Like
#7

It seems that I cannot reproduce but we have also something probably tied, ok the key is fail2ban but because the log file of roundcubemail doesn’t exist

#8

does the logrotate.d has been modified ?

# cat /etc/logrotate.d/roundcubemail 
/var/log/roundcubemail/*.log {
    missingok
    su root apache
    notifempty
    size 30k
    nocreate
}
#9

That isn’t what I have;
cat /etc/logrotate.d/roundcubemail
/var/log/roundcubemail/* {
missingok
su root apache
notifempty
size 50k
nocreate
}
It looks like I have the losing hand here.
yum whatprovides /etc/logrotate.d/roundcubemail
Loaded plugins: changelog, etckeeper, fastestmirror, nethserver_events
Loading mirror speeds from cached hostfile

The *.log would never match my errors log file, it’s simply called errors without the extension.

#10

Hi, here is the logrotate file:

[root@neth7 roundcubemail]# cat /etc/logrotate.d/roundcubemail
/var/log/roundcubemail/*.log {
missingok
su root apache
notifempty
size 30k
nocreate

I can not understand why the correct log file is missing. I had a strong intuition that fail2ban would go wrong because of a path or missing file. Moreover the strangeness and that gave error only to the manual restart of the service because during the start of the server the service is apparently active with the tick of enable.

#11

we do not provide the roundcubemail rpm, it comes from upstream, I suppose it has been modified on you server, but it is good on others. I would suggest that you modify accordingly your logrotate.d/roundcubemail file

#12

I think I have similar error with letsencrypt. I noticed it because logrotate process takes 100% CPU.

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 9392 root      30  10  535564 402084   1148 R 100.0  5.0 713:49.06 logrotate

So I took a look at what logrotate is doing:

[root@server2 ~]# tail -f /var/lib/logrotate/logrotate.status
"/var/log/letsencrypt/letsencrypt.log.14-20181004.gz-20181007.gz-20181104.gz-20181111.gz-20181125.gz-20181209.gz-20181216.gz-20181223.gz-20181230.gz" 2019-1-6-7:26:42
"/var/log/letsencrypt/letsencrypt.log.16-20181014.gz-20181028.gz-20181209.gz-20181230.gz-20190106.gz" 2019-1-8-23:0:0
"/var/log/letsencrypt/letsencrypt.log.12-20181002.gz-20181007.gz-20181021.gz-20181028.gz-20181209.gz-20181216.gz" 2019-1-6-7:26:42
"/var/log/letsencrypt/letsencrypt.log.3-20180923.gz-20180930.gz-20181021.gz-20181111.gz-20181125.gz-20181216.gz-20181230.gz" 2019-1-6-7:26:42
"/var/log/letsencrypt/letsencrypt.log.14-20181014.gz-20181021.gz-20181028.gz-20181118.gz-20181125.gz-20181202.gz-20181216.gz-20181223.gz-20181230.gz-20190106.gz" 2019-1-8-23:0:0
"/var/log/letsencrypt/letsencrypt.log.50-20181107.gz-20181118.gz-20181209.gz-20181216.gz-20190106.gz" 2019-1-8-23:0:0
"/var/log/letsencrypt/letsencrypt.log.3-20181014.gz-20181028.gz-20181223.gz-20181230.gz" 2019-1-6-7:26:42
"/var/log/letsencrypt/letsencrypt.log.6-20180927.gz-20181014.gz-20181021.gz-20181104.gz-20181118.gz-20181209.gz-20181230.gz-20190106.gz" 2019-1-8-23:0:0
"/var/log/letsencrypt/letsencrypt.log.3-20181014.gz-20181104.gz-20181111.gz-20181118.gz-20181125.gz-20181202.gz-20181209.gz-20181216.gz-20181223.gz-20181230.gz-20190106.gz" 2019-1-8-23:0:0
"/var/log/letsencrypt/letsencrypt.log.21-20181014.gz-20181028.gz-20181111.gz-20181118.gz-20181202.gz-20181209.gz-20181216.gz-20181230.gz-20190106.gz" 2019-1-8-23:0:0

This is my /etc/logrotate.d/letsencrypt:

/var/log/letsencrypt/*.log.* {
    compress
    missingok
}

@EddieA describes it here.

The already processed files are processed again because of a wrong wildcard:

letsencrypt.log.99
letsencrypt.log.99-20181226.gz
letsencrypt.log.99-20181226.gz-20181230.gz
letsencrypt.log.99-20181226.gz-20181230.gz-20190106.gz.

EDIT:

I killed logrotate (kill PID), changed the wildcard in /etc/logrotate.d/letsencrypt to /var/log/letsencrypt/*.log and removed the files in /var/log/letsencrypt. After that logrotate runs normally again.

3 Likes
#13

And here also. :grin:

Cheers.

#14

I can’t reproduce on my production machine, the logorate reported by @france is the right one.
To fix your machine:

rm -f /etc/logrotate.d/roundcubemail
yum reinstall roundcubemail
signal-event nethserver-roundcubemail-update

There is no logorate config in nethserver because certbot takes care of its own log rotation.
In fact I have no entry about letsencrypt inside /var/lib/logrotate/logrotate.status file.

#15

Hello, I made the change suggested by Giacomo, now resuming to work regularly. I simulated a password error twice and the banned is working. At the moment I leave in test, however I believe that everything worked. Thank you all !! :sunglasses:

1 Like
#16

I too have reinstalled RoundCube, and it seems to have updated my logrotate script to match on *.log,
I’m curious why I didn’t get a .rpmnew file, I have a cron job that looks for those and e-mails a diff once a week. Never a peep on this one.
Thank you all!