Hi, Well, the issue is all in the title Basically, I have noticed that websites older than 4 years are stuck with an always growing error.log file, and only one error.log.1.gz file, from 2016... Some of them don't even have one .gzip archive actually. To me, it looks like it got stuck at this moment (maybe after an update of ISPConfig) and now the rotation is no longer being done for these domains. Newer websites are behaving correctly and we have a nice 10-day history, as we might expect. What do you suggest to get these error logs back on track with the rotation? Thanks!
Can you try running Code: php /usr/local/ispconfig/server/cron_debug.php --cronjob=200-logfiles.inc.php as root?
Thanks Th0m, Here's what it gives us: Code: finished cron debug. And nothing changed in the logs, I still have one gigantic error log file for older websites.
Can you share the content of /etc/fstab? (you might want to remove domain names, but make sure it is still understandable.)
Hey Th0m, I actually notice the domains that are posing problem are absent from fstab! I think that explains it all, right? If so, how do you think it can be fixed? Thanks!
Yes, that would be the problem. I just installed a nginx test system to check it, and a correct entry would look like this: Code: /var/log/ispconfig/httpd/example.com /var/www/clients/client0/web1/log none bind,nofail 0 0 Replace example.com with the correct domain, client 0 with the correct client ID, and web1 with the correct web ID. Then run the debug cronjob. If a lot of sites are affected, you might want to write a script for this.
Awesome! Yes, this is exactly it. Sorry I just realized I should have, at least, given you an example of the websites I have in fstab. But it looks exactly like this indeed. OK, excellent, we're going to give it a shot and I'll get back here to confirm it works. To me, this makes perfect sense anyway. Thanks again!
No problem, just wanted to double check it so I gave you the correct information. Let's hope this resolves it indeed
Hi Th0m, I've got some news It seems your suggestion worked like a charm and logs are now back on track! Thanks a lot for your precious help with this Now, we have a few questions before adding all the missing entries (we're talking about ~50 missing entries here): 1. Do you think that ISPConfig had an issue once and stopped recording new websites in fstab for some reason? Or maybe it removed a bunch of them by mistake? 2. Does ISPConfig depend on these fstab entries to function properly in other areas than log rotation? 3. To me, it looks like log rotation is working for new sites because every time I create a new site, its path is recorded properly. But I just want to confirm with you that it is the expected behaviour. 4. Last but not least, we have some concerns about all these records in the fstab as we think it might prevent our VM from rebooting properly the next time. What are your thoughts about this? Any advice or experience on your end? Thanks again
Glad to hear No problem. It probably was a bug that is resolved in the past, or someone deleted them by accident. Just for logging and accessing the logs by the client, nothing else. Yes, they should be added to the fstab file. It should not cause any trouble - I have a lot of sites, they all have such a entry, and it runs without a problem.
Thank you Th0m for all your answers, this is really reassuring and I guess we can now move on to something else Cheers!
Hey Th0m, One last question: why does ISPConfig use fstab to rotate logs and not directly logrotate? Is there a technical reason for this choice? Thanks!
Fstab is not used for the log rotation itself. fstab is used so the logs are accessible by the client. The logs are all placed in /var/log/ispconfig/httpd/example.com (where example.com is the hosted domain). This folder is not accessible by the client. Their root folder is. So a fstab entry is added to access the logs from what looks for them like "/log" (if they use FTP). The rotation is done on the /log folders in the clients webroot, so without the fstab entry, the rotation does not work.