Bandwidth Monitoring not working for one single Virtual Server

Virtualmin
21

Ok … if you go to Limits and Validation → Validate Virtual Servers, does it report any problems with this domain?

22

Nope: “All features OK” for that Virtual Server.

23

Could you post a few log lines from access_log for this domain?

24

Sure (just replacing the actual website’s name by “website”):

93.207.78.72 - - [07/Feb/2022:10:34:16 +0100] "GET /fr/ HTTP/2.0" 200 28646 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36"
93.207.78.72 - - [07/Feb/2022:10:34:16 +0100] "GET /modules/stthemeeditor/views/css/customer-s1.css HTTP/2.0" 200 2268 "https://www.website.com/fr/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36"
93.207.78.72 - - [07/Feb/2022:10:34:16 +0100] "GET /themes/website/assets/cache/theme-357bbd92.css?nocache=68694 HTTP/2.0" 200 142101 "https://www.website.com/fr/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36"
93.207.78.72 - - [07/Feb/2022:10:34:16 +0100] "GET /themes/website/assets/cache/bottom-82516491.js HTTP/2.0" 200 230924 "https://www.website.com/fr/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36"
93.207.78.72 - - [07/Feb/2022:10:34:16 +0100] "GET /modules/trustedshopsintegration/views/js/product_bottom.js HTTP/2.0" 200 801 "https://www.website.com/fr/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36"
93.207.78.72 - - [07/Feb/2022:10:34:17 +0100] "GET /img/cms/website/les-plus/les clubs.png HTTP/2.0" 200 6143 "https://www.website.com/fr/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36"
93.207.78.72 - - [07/Feb/2022:10:34:17 +0100] "GET /img/cms/website/les-plus/occasions.png HTTP/2.0" 200 14815 "https://www.website.com/fr/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36"
93.207.78.72 - - [07/Feb/2022:10:34:17 +0100] "GET /img/cms/website/les-plus/floorball.png HTTP/2.0" 200 7687 "https://www.website.com/fr/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36"
25

Did bandwidth monitoring ever work for this site? Or was it broken since it was originally created?

26

It used to work well … and it stopped at some point in July 2021:

ce
ce867×383 37.3 KB

Note that this Virtual Server has been transferred from one server to another in July 21 (via the usual “Transfer Virtual Server” functionality). So it it would seem that it worked on the previous server and not anymore on the current one.

Also note that the current server host several other Virtual Servers whose bandwidth monitoring works like a charm.

27

If you go to the directory /etc/webmin/virtual-server/bandwidth and then edit the file named after the domain’s unique numeric ID, what do the last_ lines contain? The issue may be that Virtualmin thinks that no more bandwidth data needs to be processed …

28

Here you go:

$ cat /var/webmin/modules/virtual-server/bandwidth/156689461825320 | grep last
last_web=3155760000
last_ftp=
last_unix=1626753906
last_mail=1644390001

One hour later:

$ cat /var/webmin/modules/virtual-server/bandwidth/156689461825320 | grep last
last_web=3155760000
last_ftp=
last_unix=1626753906
last_mail=1644393600

Obviously the file has been updated … but the last_web value did not change (as far as I understand, it should have since there has been significant trafic on the site meanwhile).

29

Oh boy, I’m late to the party. Sorry, but I didn’t get any notifications for updates in this thread and just came back here by chance to see if there’s something new.

Summing up my answers to all the questions asked since my last post, which are mostly exactly identical to Nico94s’ answers - except for the last!

  • Problems start after migration virtual servers from other VirtualMin hosts (via the “Transfer Virtual Server” functionality). OS change due to the move from CentOS 7 to AlmaLinux 8
  • Disabling / re-enabling bandwidth-monitoring in the system settings doesn’t help.
  • The scheduled task is there, and is getting executed. Executing it manually also doesn’t change a thing.
  • The servers are listed under “Servers and log files”/“Servers to check” select box.
  • Selecting only one or some of the “defect” servers there instead of “all servers” doesn’t change anything.
  • Problems seem to start after transferring the server, as far as I can remember.
  • The servers in question do write Apache logs to /var/log/virtualmin/_access_log (and the corresponding error_log).
  • The logfiles seem to have normal ownership / permissions: Owner is the virtual servers’ user id, with group “apache”. Permissions are 660.
  • The logfiles of servers where bandwidth monitoring doesn’t work correctly are of the same format as of servers that DO work correctly (regarding bandwidth monitoring).
  • The logfiles are configured using the default log format “combined” in the apache config file (like to working virtual servers, too), so “CustomLog /var/log/virtualmin/_access_log combined”.
  • Validation of those servers doesn’t give any error. (Limits and Validation => Validate Virtual Servers)
  • Some current lines from the access log (website name redacted to xxxxxx):
148.72.199.192 - - [09/Feb/2022:12:54:00 +0100] "POST /xmlrpc.php HTTP/1.1" 200 404 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
37.48.121.87 - - [09/Feb/2022:12:54:45 +0100] "GET / HTTP/2.0" 301 - "-" "-"
37.48.121.87 - - [09/Feb/2022:12:54:46 +0100] "GET / HTTP/2.0" 200 105875 "-" "-"
146.70.86.117 - - [09/Feb/2022:12:54:58 +0100] "GET /kontakt/ HTTP/1.0" 200 102525 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36"
146.70.86.117 - - [09/Feb/2022:12:54:59 +0100] "POST /kontakt/ HTTP/1.0" 200 102631 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36"
42.83.147.34 - - [09/Feb/2022:12:56:02 +0100] "GET / HTTP/1.1" 301 - "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/74.0.3729.169 Safari/537.36"
42.83.147.34 - - [09/Feb/2022:12:56:04 +0100] "GET / HTTP/1.1" 200 106235 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/74.0.3729.169 Safari/537.36"
34.68.241.59 - - [09/Feb/2022:12:56:06 +0100] "GET /wp-login.php HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36"
34.68.241.59 - - [09/Feb/2022:12:56:08 +0100] "GET /wp-admin/ HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36"
34.68.241.59 - - [09/Feb/2022:12:56:09 +0100] "GET /wp-login.php?redirect_to=https%3A%2F%2Fxxxxx%2Fwp-admin%2F&reauth=1 HTTP/1.1" 200 8315 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36"
190.2.132.155 - - [09/Feb/2022:12:58:41 +0100] "GET /kontakt/ HTTP/1.0" 200 108518 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4427.0 Safari/537.36"
190.2.132.155 - - [09/Feb/2022:12:58:43 +0100] "POST /kontakt/ HTTP/1.0" 200 103273 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4427.0 Safari/537.36"
185.107.80.192 - - [09/Feb/2022:13:00:19 +0100] "GET /kontakt/ HTTP/1.0" 200 108513 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36"
185.107.80.192 - - [09/Feb/2022:13:00:20 +0100] "POST /kontakt/ HTTP/1.0" 200 103358 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36"
188.34.197.114 - - [09/Feb/2022:13:02:54 +0100] "POST /wp-cron.php?doing_wp_cron=1644408174.5621900558471679687500 HTTP/1.1" 200 - "https://xxxxx/wp-cron.php?doing_wp_cron=1644408174.5621900558471679687500" "WordPress/5.9; https://xxxxx"
162.214.208.84 - - [09/Feb/2022:13:02:54 +0100] "POST /xmlrpc.php HTTP/1.1" 200 404 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
190.2.132.155 - - [09/Feb/2022:13:04:31 +0100] "GET /kontakt/ HTTP/1.0" 200 108490 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.72 Safari/537.36"
190.2.132.155 - - [09/Feb/2022:13:04:33 +0100] "POST /kontakt/ HTTP/1.0" 200 102654 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.72 Safari/537.36"
194.38.20.161 - - [09/Feb/2022:13:05:52 +0100] "GET /?file=tf2rghf.jpg HTTP/1.1" 301 - "-" "ALittle Client"
194.38.20.161 - - [09/Feb/2022:13:06:05 +0100] "GET /?file=tf2rghf.jpg HTTP/1.1" 200 105875 "-" "ALittle Client"
188.34.197.114 - - [09/Feb/2022:13:09:22 +0100] "POST /wp-cron.php?doing_wp_cron=1644408562.2709589004516601562500 HTTP/1.1" 200 - "https://xxxxx/wp-cron.php?doing_wp_cron=1644408562.2709589004516601562500" "WordPress/5.9; https://xxxxx"
185.107.80.192 - - [09/Feb/2022:13:09:21 +0100] "GET /kontakt/ HTTP/1.0" 200 108518 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36"
185.107.80.192 - - [09/Feb/2022:13:09:22 +0100] "POST /kontakt/ HTTP/1.0" 200 103302 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36"
190.2.132.155 - - [09/Feb/2022:13:10:15 +0100] "GET /kontakt/ HTTP/1.0" 200 102525 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4400.8 Safari/537.36"
190.2.132.155 - - [09/Feb/2022:13:10:17 +0100] "POST /kontakt/ HTTP/1.0" 200 102631 "https://xxxxx/kontakt/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4400.8 Safari/537.36"
184.168.96.164 - - [09/Feb/2022:13:11:51 +0100] "POST /xmlrpc.php HTTP/1.1" 200 404 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

  • Bandwidth monitoring stopped after the transfer to a new server:

    image
    image1047×218 14 KB

  • Also in my case on the same server there ARE virtual hosts for which bandwidth monitoring is working. As far as I can tell, the difference seems to be that virtual servers created there originally do work, and those that were transferred here don’t.

  • /var/webmin/modules/virtual-server/bandwidth/ does contain this:

last_unix=
last_web=3155760000
last_mail=1644408001
last_ftp=

After running the scheduled bw.pl job manually, this changes to:

last_unix=
last_web=3155760000
last_mail=1644409059
last_ftp=

Difference to Nico94s’ case is that here the last_unix is empty.

30

Ok, it looks like the issue is that last_web= line , which is set to a timestamp way into the future. This will prevent Virtualmin from processing any new Apache log entries, as it thinks they have already been read.

My guess is that at some point, an entry in the Apache for this domain has a bad timestamp somewhere in the year 2070. I will add code to Virtualmin to avoid this in future…

For now, try just changing that line to last_web=1644409059 and re-run bw.pl . This will re-start collection of bandwidth stats from the current time.

1 Like
31

Yes ! That was it ! :+1:

This will most likely also solve cmeis’ problem since both of our last_web timestamps were identical.

Thank you so much Jamie for your help and your time.

32

Hello Jamie,
thanks for looking into this, and yes - this sounds like a sensible explanation.

Before trying that out I’d like to clarify the new “last_web” timestamp though:
The value you asked us to use would be “current”. Would this mean that bandwidth usage would only be calculated for the time starting now, or also the “missing” data from the last months?

If just starting from now, would it make sense to set the “last_web” variable to a timestamp around when the calculation stopped?

Or is “last_web” just the last time it ran the job. So setting it to “now” will make it run this the next time and calculate all “missed” data anyhow?

Christian

33

Being impatient enough I just tried. Looks like it doesn’t recalculate old/missing data. But I’m too lazy right now to dig into why. I.e. is this intentional, are the necessary logfiles still there, …

For now I’m happy it’s working again.

Thanks Jamie for point to the reason!

Christian

34

It’s possible that the original logfiles have been rotated … if so it won’t be possible to re-generate.

35

I have also added few UI improvements for this sub-module for upcoming Webmin release.

1 Like
36

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.