@till what does mean "too big"? I have error.log files from apache (/var/log/ispconfig/httpd/<domain>/error.log) with over 500 MB and they haven't been rotated for years (! e.g. since 2015). Despite the error.log, the daily access.log files get rotated, but not compressed -> where can I enable compression and set the number of days that should be kept? (Instead of having > 1000 files per domain...) Thanks
This indicates that there are issues with your ISPConfig install, as access.log files always get compressed after 1-2 days. Most likely, the ISPConfig cron system does not run or something similar. Which ISPConfig version do you use?
I am running version 3.2.10p2 with multi server installation. I see on some sites the access.log gets gzipped and the error.log gets rotated (whereas the access.log is prefixed with a date and the error.log is just appeneded a suffix number and gzipped). max. 10 files for both. Looks as it has something to when the site (all on the same server) has been created?
Check /etc/fstab, most likley a the mount line for the log folder of the affected site is missing. Add it and then run: mount -a to mount it. The issue should be solved then on next log rotation.
Thanks for the hint. I see the line in fstab, but it doesn't get mounted. And I see that there are many that do not get moutned and all have as options: "bind,nobootwait" whereas the entries that work have as options "bind,nofail" So I can go and replace nobootwait with nofail, but the question is why isn't it working and why has the option changed? And how can I make sure that the fstab list is "complete" with all needed entries/sites?
As you mentioned, the system has been installed quite some time ago and the options in fstab changed, normally the old option should still work, but as this does not seem to be the case on your system, just replace it in all lines and run 'mount -a' to mount all missing directories. There should be nothing missing unless you manually removed lines.
@till: the mount option in fstab didn't matter, the directories have already been mounted, i just didn't see them because in the mount list the show up differently, not with the "domainname" in the target. I think I found now the difference which may be the in issue. In the /var/www directory, the symlinks from the domains where the log rotation works are absolute, e.g. /var/www/clients/client10/web484/, whereas the ones that do not work are relative symlinks, e.g. clients/client15/web48 --> does that ring a bell? Was that symlink creation and log rotation behaviour changed over time? Is there a simple "fix" to re-create the symlink the with the correct path or do I need to update them manually? I have changed now one of the non-working log-rotation symlinks and will see if it resolves it for that directory/domain.
If symlinks are created relative or absolute is set under System > server config > web. But this should not make any difference for the log rotation.
@till Thanks. Symlinks: If I change it in the server config, I assume the existing symlinks do not get re-created, so that I would have consistent symlinks? The logs still have not been rotated. The daily access.log files are created, but not rotated. And the error.log is appended "since ever". How can I debug the issue?
Yes, existing symlinks will not change. But these symlinks should not have any infliuence on log rotation, whether relative or absolute, as long as they point to the right directory. You can test it like this: ls -la /var/www/domain.tld/log/ if this shows you the log files of that site, then symlink is correct.
The log rotation is done by a corn plugin. See this thread for an example: https://forum.howtoforge.com/threads/awstats-in-multi-server.91347/ In your case, the corn plugin is not the awstats plugin but the plugin 200-logfiles.inc.php
I think I see what is common on all the directories that do not work: the have at least one "Subdomain (vhost)". The log-symlink of a host that works points directly to the right log directory. But if I have for a domain "Subdomain (vhost)" added, the log-symlink points to a directory which has subfolders as the log-directories of the subdomains. No idea how the structure usually would look like with subdomain vhosts?
I see two cases on my server for hosts with subdomains: - the main site logs into the /log folder and the subdomains into /log/<subdomain> --> files get rotated fine - the main site logs into the /log/web folder and the subdomains into /log/<subdomain> --> files get rotated fine only for the subdomains so for whatever reason some of the "main domain hosts" got the mount/fstab pointing to the /log/web instead of /log directory. I will manually change one of them and see what happens. Can I enforce the log rotation process or is it just run daily?
That a mail domain logs into a web subfolder is strange indeed. Have to check that on a test system, but I don't think I've ever seen that on any system. is this an Apache or Nginx server? Or maybe the mount in /etc/fstab is wrong? It must point to ...../log and not ...../log/web
apache I have changed the mount-point in fstab know and will see what happens on the next logrotate run. As the not rotated log files are over 3 years old, I cannot tell if, for whatever reason, I would have changed the fstab file manually. I found another domain that didn't have any fstab entry and wasn't rotated either. Is there a good way to manually re-generate/validate the fstab file?
This might help you: https://forum.howtoforge.com/threads/recreate-fstab-content-for-log-files-in-one-go.77267/
Thanks @till The changes done yesterday helped, logrotation works for these directories. Thanks for the script. I have run it, but had to modify it as it create duplicate entries as it expects a specific existing fstab line. It seems that the log directory for subdomains changed at some point in time -> this script maps to a subdirectory with the FQDN of the subdomain, whereas on my system I had only the "subdomain" without the domain name as directory. Can you verify this on your side? Thanks
