You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Master:
Salt Version:
Salt: 3004.1
Dependency Versions:
cffi: 1.14.0
cherrypy: Not Installed
dateutil: 2.8.0
docker-py: 4.0.2
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 2.11.2
libgit2: 1.3.0
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 0.5.6
msgpack-pure: Not Installed
mysql-python: Not Installed
pycparser: 2.20
pycrypto: Not Installed
pycryptodome: 3.6.1
pygit2: 1.7.1
Python: 3.7.10 (default, Jun 3 2021, 00:02:01)
python-gnupg: Not Installed
PyYAML: 5.3.1
PyZMQ: 17.0.0
smmap: Not Installed
timelib: Not Installed
Tornado: 4.5.3
ZMQ: 4.2.3
System Versions:
dist: amzn 2
locale: UTF-8
machine: x86_64
release: 4.14.177-139.254.amzn2.x86_64
system: Linux
version: Amazon Linux 2
Minion:
Salt Version:
Salt: 3004.1
Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: Not Installed
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 2.10
libgit2: Not Installed
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 0.5.6
msgpack-pure: Not Installed
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: Not Installed
pycryptodome: 3.6.1
pygit2: Not Installed
Python: 3.7.10 (default, Jun 3 2021, 00:02:01)
python-gnupg: Not Installed
PyYAML: 4.2
PyZMQ: 17.0.0
smmap: Not Installed
timelib: Not Installed
Tornado: 4.5.3
ZMQ: 4.2.3
System Versions:
dist: amzn 2
locale: UTF-8
machine: x86_64
release: 4.14.273-207.502.amzn2.x86_64
system: Linux
version: Amazon Linux 2
When running the logrotate formula with an hourly logrotate job, everything is laid down correctly but if rotation is not forced to run the first time (i.e. "initialize" the job) it stays stuck in a state of returning log does not need rotating (log has been already rotated) when evaluating status forever, thus filling up the disk space and crashing my app. :(
I think this has something to do with the /var/lib/logrotate/logrotate.hourly.status file not already existing before the job is populated.
Steps to reproduce the bug
Pretty much just "lay down logrotate for a fresh application with an hourly config option, watch to see if logrotate -d /etc/logrotate.d/job_name ever returns log needs rotating, even after it should rotate the log. In my experience, it never does.
Expected behaviour
Logfiles rotate, even if they have never done so before.
Attempts to fix the bug
The only thing that fixes this is manually running logrotate -f /etc/logrotate.d/my_app because that forces rotation and after that, the status file is created/set correctly.
That, or adding a -f flag to the actual logrotate line in /etc/cron.daily/logrotate (or wherever your system has the cronjob definition).
Additional context
n/a
The text was updated successfully, but these errors were encountered:
mdschmitt
changed the title
[BUG] First-run of new logrotate job evaluates necessity incorrectly, so rotation never actually works.
[BUG] First-run of new logrotate hourly job evaluates necessity incorrectly, so rotation never actually works.
Jun 20, 2022
Hm, I think this has to do with the fact that a custom logrotate status file is used for the hourly jobs. If that file has nothing in it to begin with, logrotate doesn't know what has or has not happened, so it defaults to evaluating jobs as "not needing rotation" even though they should get rotated. The one-time addition of the -f flag forces the job and thereby creates the needed statusfile with contents that are then valid and all successive runs succeed.
Your setup
Formula commit hash / release tag
tag: v0.13.2
Versions reports (master & minion)
Minion:
Pillar / config used
Bug details
Describe the bug
When running the logrotate formula with an hourly logrotate job, everything is laid down correctly but if rotation is not forced to run the first time (i.e. "initialize" the job) it stays stuck in a state of returning
log does not need rotating (log has been already rotated)
when evaluating status forever, thus filling up the disk space and crashing my app. :(I think this has something to do with the /var/lib/logrotate/logrotate.hourly.status file not already existing before the job is populated.
Steps to reproduce the bug
Pretty much just "lay down logrotate for a fresh application with an hourly config option, watch to see if
logrotate -d /etc/logrotate.d/job_name
ever returnslog needs rotating
, even after it should rotate the log. In my experience, it never does.Expected behaviour
Logfiles rotate, even if they have never done so before.
Attempts to fix the bug
The only thing that fixes this is manually running
logrotate -f /etc/logrotate.d/my_app
because that forces rotation and after that, the status file is created/set correctly.That, or adding a
-f
flag to the actual logrotate line in/etc/cron.daily/logrotate
(or wherever your system has the cronjob definition).Additional context
n/a
The text was updated successfully, but these errors were encountered: