Again .. Log file rotation failed! : ..

There are tons of discussions on forums and reported issues on the subject matter, and we know how to troubleshoot this. However, the persistency of this error popping up now and then makes me to file this request - can we finally get rid of this problem once and for all? All that it takes to get this resolved is to make sure Virtualmin removes traces of deleted virtual server (domain) from everywhere in the system!

Had this today again:

Setting up log file rotation ..
.. Log file rotation failed! : .. the log file /var/log/virtualmin/test.com_access_log is already being rotated at /usr/libexec/webmin/ line 1427.


This would be easy to fix, if I could re-produce it :-(

When you delete a domain, do you see any error message regarding the removal of the logrotate config?

Unfortunately, I didn't see any errors and it's not clear how and when this happens. Sometimes everything works just ok, but sometimes this same issue happens again. I have a feeling this could be related to subdomains as often times their log rotate files are not deleted.

I have a theory on when it could happen.

Sometimes for unknown reason, but mostly because the websites were moved around, edited, cloned and something went awry, the Apache record's for the websites got stuck on the Apache configuration file. Meaning even if you remove such websites they are kind of removed but giving the Apache error. And then if you check both /var/log/virtualmin/ and /etc/logrotate.d/ directories will contain the records for the removed websites.

So I believe some Virtualmin's script just exits on the Apache error during the execution of "DOMAIN_DELETE" function. So to remedy this kind of cases that pop up in the forums again and again, cleaning the relevant files in /var/log/virtualmin/ and /etc/logrotate.d/ directories could be done in the first place when removing domains. Thus, even if there is an Apache-related error (or any kind of error for that matter) ahead, we will arrive to the lesser problematic state - at least those files would be removed from the system.

In other words, the file deletion should be given more priority than dealing with others things during domain removal process.

The deletion process should never completely fail - even if the remove of the Apache config breaks for some reason, it should complete other steps (like removal of the logrotate config).

This is happening so often, so I really do wonder how you can't re-produce it: just create a virtual server, [play with it changing things, like disabling and enabling it's Apache and DNS options], delete it. Try to re-create the virtual server and you will see the error. Why? simply because its .conf file in /etc/logrotate.d was always there and never was deleted together with the domain name.

James, can you please get rid of this kind of issues which lasts in Virtualmin for years already?

Do you think, Virtualmin is not able to properly remove .conf files in /etc/logrotate.d because we always configure our servers for Apache to listen to 8080 and Varnish to 80? But then how Apache records would effect logrotate files or they do?

On my test systems I can't re-produce this, sorry.

During the deletion process that leaves this logrotate config around, do you see any error messages in the output?

Strange enough. What is the OS that you are running your tests on? Could it be about the environment? Mine is:

CentOS Linux release 7.3.1611 (Core)
Derived from Red Hat Enterprise Linux 7.3 (Source)

Alright, I have an idea. Can you please not to delete the domain, but just disable and enable DNS and Apache for the domain in Edit and see if the error will come up?

Tried that, but I still couldn't re-produce the problem. If you disable and re-enable DNS like you suggested, does it show any error messages?

Bringing up this issue of 2016, because the issue is still happens quite frequently. And to replicate it is just enough to:

  • Uncheck Apache website enabled? on a test domain and save it.
  • Go to Edit page again and try to check both Apache website enabled? and Log file rotation enabled?, save and you will get:
Setting up log file rotation ..
.. Log file rotation failed! : .. the log file /var/log/virtualmin/test.com_access_log is already being rotated at /usr/libexec/webmin/ line 1478.

Why? Because the file /etc/logrotate.d/virtualmin.conf contains:

/var/log/virtualmin/test.com_access_log /var/log/virtualmin/test.com_error_log {
rotate 5
systemctl reload httpd.service ; sleep 5

Removing references to in /etc/logrotate.d/virtualmin.conf finally allows to check the Log file rotation enabled? option. This is happening on CentOS 7.x system. Please just run the above test steps and you will see it.

I got this error while playing with apache2, installing nextcloud on an virtual server and followed some security docs from nextcloud..

I found my self with an broken apache2 so I did the quick fix and removed apache2 from lemp and reinstall it by command line.

Sure, all config files was gone for this specific virtual server so I deleted this virtual server and tried to create new one.

Since to many apache2 modules was also deleted I just did reinstall virtualmin as quick fix to avoid searching all needed modules..

All this worked fine until I start creating new virtual host with the same domain, Setting up log file rotation ..

Log file rotation failed! : .. the log file /var/log/virtualmin/” …

Editing /etc/logrotate.d/virtualmin.conf did resolv my logfile rotation issue.

Experimental server setup ubuntu 18.04 webmin/virtualmin.