-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Logrotate #1387
Comments
ideas:
https://serverfault.com/questions/189320/how-can-i-monitor-what-logrotate-is-doing |
So I suppose mine is a known issue... Here is what I've tried:
I've tried to force root ownership of the log files:
If I restart the container, the ownership of the pihole.log is restored to the previous values:
I'm running pihole using the following
and this is my
|
Do you see the same behavior if you remove |
@rdwebdesign yes, even if I remove those variables and recreate the container, I see almost the same behaviour.
instead, here is the ownership with the two variables set:
In both cases
|
I went to "mirror" my PiHole to another server and I saw that my There is a Initially, I got an error, but it wanted the files to be "root" created so I did that. Then I tested logrotate with command Hope this helps someone... UpdateAnother error I got was that there is no |
Have just checked my running v6 container and logrotate certainly appears to be working correctly here:
Which is fired nightly by
Looking at the command that is run ( And the same in my v5 container:
|
Does anyone in this thread still have problems with the logs not being rotated? |
@PromoFaux yes, the problems I reported earlier are still there:
|
What does your compose file look like? (Also, have you tried the beta v6 image?) |
my compose file:
my
No, I haven't tried the beta v6 image. |
Here in lies the root cause of the issue. See the Experimental Variables section of the README file. |
Thank you, I hadn't seen that... |
Ah, Synology NAS: Actually, at this stage I'd recommend using the v6 beta image instead as it's fairly "close" to release, which removes the I'm currently running the v6 images on my Synology with Take a read over the new Readme first, though, as you'll need to make a few changes to your environment variables |
Thank you for pointing that out. |
Going back to the original issue raised, what should happen if the system detects that logrotate isn’t running properly? |
It's a good question - I'm not 100% sure there is an answer to it. I suppose we could set a cron script to periodically check the size of the logs - but this does not seem like an ideal solution. I created this issue before I'd really looked into whether or not logrotate was working in the image... as it happens, it appears to be. Do you have any suggestions? |
The more I think of it, with a properly configured container - there shouldn't be an issue with logrotate. That diagnosis table is populated by FTL - not sure it would be a good idea for FTL to monitor the size of logs / log rotation status. Certainly on size, what is large for one user is tiny for another. @buxm's issue appears to be caused by some permission issues on the filesystem - and I've a feeling it would be sorted out with the v6 image in any case |
My initial thought was a script to check that the logrotate location was writable by the proper user, write something to the log, force a rotate, and check it's non-zero. If any of those fail, error and alert the user somehow. The more I think about it though, the less I think anything should be done. This is a giant container doing a lot of things. If logrotate works in the base image, no need to overcomplicate its setup and end up scaring off a newcomer who can't diagnose what logrotate is and why it might be throwing an error. |
We need a mechanism to ensure logrotate is working
The text was updated successfully, but these errors were encountered: