Module links giving error

Does anything get logged to /var/webmin/miniserv.error when this happens?

I am seeing this too, in Virtualmin Pro only. Its very random, and the bind module will just sit there and require multiple clicks to open. Here are some lines from the miniserv.error log: (there are gobs more)

Possible browser / JS issue? Which browser are you using?

Chrome/IE/Firefox in Win7, same plus Edge in Win10 and my Android Phone's Chrome too. Also tried the old "Virtualmin Framed Theme", might have even been worse.

This issue also shows as a simple white screen on occasion too. For instance, just now, opening the site in Firefox, the System Information screen didn't fill in until after I clicked on a few things to wake it up.

Thinking its not a browser thing.

Just found this. Might point in the right direction. Clicked "system statistics" the screen changes, then a box pops with this: Failed to load data xml from history_data.cgi?stat=load&start=1516723680&end=1516810080&nice=1 Bad Header Click "ok" Now with "CPU 1 Minute" selected, click "show selected" and just get the "Error - Bad Header" text and nothing else.
Did this 3 times in sequence, with 2 different computers. Then it magically started working correctly, and it works fine now. miniserv.error:

That's very unusual - it looks like some of Virtualmin's scripts are crashing.

Is your system perhaps low on RAM?

Centos 7.4.1708
Webmin 1.872
Virtualmin 6.02 Pro
10.52 used of 15.30 GB RAM
249Gb used of 491GB Disk

I have another server running virtualmin GPL that isn't doing any of these things. Same specs.

I have the same problems but not al servers are affected:

https://sourceforge.net/p/webadmin/bugs/5078/

If anyone who's seeing this could give me remote access to one of their servers, that would be very useful.

access setup, sent email with this ticket referenced (from inside virtualmin)

We're seeing similar issues with our installation, just after update; here's the yum.log:

Feb 08 13:35:43 webmin-1.872-1.noarch: 100 Feb 08 14:06:22 Updated: usermin-1.734-1.noarch Feb 08 14:06:24 Updated: 2:wbt-virtual-server-theme-9.4-1.noarch Feb 08 14:06:24 Updated: 2:wbm-virtualmin-mailman-6.6-1.noarch Feb 08 14:06:25 Updated: wbm-virtualmin-git-1.8-1.noarch Feb 08 14:06:25 Updated: 2:wbm-virtualmin-registrar-2.5-1.noarch

These are the most common error lines in /var/webmin/miniserv.error:

Use of uninitialized value $en in pattern match (m//) at /usr/libexec/webmin/bind8/bind8-lib.pl line 4133. Temp file clearing is not done for the custom directory /var/

Seems like this may be the thread to post in. I'll open a support request as well.

Hrm. Looking again, those errors were happening previous to the update -- these are the ones post-update, logged as miniserv starts:

[09/Feb/2018:08:58:42 -0600] miniserv.pl started [09/Feb/2018:08:58:42 -0600] Using MD5 module Digest::MD5 [09/Feb/2018:08:58:42 -0600] PAM authentication enabled [09/Feb/2018:08:59:07 -0600] [dhcp-128-83-93-153.its.utexas.edu] / : Bad Header

Logging into webmin just returns a page with: Error - Bad Header

...aaannnnd refreshing the page occasionally works just fine. I'm thinking about downgrading wbt-virtual-server-theme-9.4-1.noarch to see if that does anything, but now that it appears to be working for the moment, I'll just continue to poke around...

any update yet? Because this bug is really annoying with the constant "Bad Header" message. The only solution is refreshing until you drop.

Same issue here with GPL - I think it is related to the Webmin theme. If I change the theme to mobile, all works as a text display without the errors. Errors on Chrome and Edge. I'm also seeing weird text in the dropdowns. See attached

Tried different theme's and browers but all give bad headers. Jamie is there a workaround?

If someone who's seeing this can give me remote access to their system, that would be really useful.

I tried to send you the remote key stuff days ago (see #13 above). Assuming you never got it? What can I do to be sure you get the authorization if I try again.

Try re-enabling support access, and just to be sure emailing me the IP address of your system at jcameron@virtualmin.com

Support Access enabled. Email sent to above address.

Thanks .. taking a look now.

I did some investigation, and was occasionally able to re-produce the "Bad Header" error. However, figuring out the cause is more complex - it seems like some of the Webmin scripts are being randomly terminated before completion.

I have made a small config change on your system that will at least provide more information when the error happens - editing /etc/webmin/miniserv.conf and adding the line forkcgis=1 , then running /etc/webmin/restart

Good news, the log shows you saw the error repeatedly, better news, since you logged out, it hasn't logged a single Bad Header, and that silly line:
Use of uninitialized value in string eq at /usr/libexec/webmin/virtual-server-theme/right.cgi line 37
went away too.
I quite literally can't seem to break it.

I am sure that this is temporary.

Let's see how it goes ..

seems to be solved. no more errors in logfile or bad header errors in browser.

Followup Report: Webmin 1.880 brought this error to 3 "just webmin" installs I have here. I had to add the forkcgis=1 line to 2 of them immediately, the 3rd took a bit of time to throw errors. (but I might have not just tried it yet)

DaveOverton - so upgrading made the problem worse!?

On the server you logged into and made the initial changes, nothing changed, its fine. On 3 others with just webmin installed. its now giving the same error. Added the above string to all 3, all is fine again.

Experiencing the same issue.

Adding forkcgis=1 does stop "Error - Bad Header" from appearing but introduces another error message: "Error - Missing Content-Type Header".

So far the easiest way to reproduce it is when accessing "Change Language" (/virtual-server/edit_lang.cgi). Appears every time.

webmin-1.880

wbm-virtual-server-6.02.gpl-2

After struggling with lots of debug code that I inserted into the perl scripts, I've nailed this one down.

Starting from 1.880, in miniserv.pl log_request() subroutine, $headers is no longer declared local. This is supposed to be used only in this function to log some of the values of the request headers.

The problem with this is that in subroutine write_to_sock(), the global $headers variable is used to accumulate response headers.

When config option "logclf" is turned on, the global $headers variable is now initially receiving some text with the referrer and user-agent request header values, and most importantly, with a leading space character. Generated response headers are then appended to that string, and the leading space character marks the first server response header as bad.

A workaround should be to turn off logclf, but the code change to fix this is trivial. (Either declare $headers as local in log_request(), or change the names of the variables used so that there is no clash.)

Thanks for pointing this out - I'll fix this in the next release of webmin.

I have been struggling with the same issue on an Ubuntu 14.04 server running Webmin 1.881. The above workarounds seem to have addressed the issue. Time will tell.