Error 500: Internal Server Error in web interface

m0j0 · ‎02-19-2015

I've got a couple of 60C's in HA running 5.0.4. I tried to log in to the web interface today and it logs me in and loads the top toolbar and sits there with two empty frames for a while before it finally returns a "Error 500: Internal Server Error" in the left frame. I've tried killing all the httpsd processes but it hasn't made a difference. A diag debug on the web-ui shows the following when the error shows in the web interface:-

[httpsd 27319] http_config.c[573] ap_invoke_handler -- handler 'fastcgi-script' completed (result==500)

[httpsd 27319] http_request.c[1443] ap_internal_redirect -- internal redirect to '/p/pubredir/httperror/'

Trying to avoid rebooting the firewall at all costs. I've considered a forced failover to the secondary device but want to exhaust any other possible options before going down that road, and I'm not sure it will fix it anyway.

The web interface was working fine a day or two ago and nothing has changed since then. Firewall uptime is 223 days and looking at my Cacti graphs, memory utilisation has been sitting around 65% since November but appears to have just nudged up to 70% very recently. Not sure if this is the cause of the problem or not.

Prometheus · ‎07-24-2016

Hi Skippy,

So far so good. We did not experience the problem anymore since we installed 5.2.8. But we only installed the devices 10 days ago. It took the 5.2.7 devices like 14 days to come up with the problem, so I cannot confirm nor can I deny that 5.2.8 is the right solution.

Skippy wrote:
Prometheus wrote:
So last night we switched to the backup cluster using the 5.2.8 firmware. I'll keep you guys posted if it keeps on working or not. The faulty device also worked again after a reboot but this is still under investigation by Fortinet.

Is it normal to have something like 28GB of disk logging in roughly 10 days of operation?
Full logging enabled for all policies with four WAN interfaces and both static and policy routes as well as BGP.

I think this is quite normal. I see it with our network monitoring which collected over 2GB of logging in 12 hours. But once again i'm not sure.

View solution in original post

Stefan_H · ‎02-16-2016

Hi Slavko,

thank you for the quick information.

We will try it out and give a proper feedback.

Cheers,

Stefan

Stefan_H · ‎02-17-2016

Hi everyone,

just a short feedback.

We had to force a failover on the slave unit.

During the day it wasn't possible to use http in our company. All other services were available.

We can't reach the primary unit via browser or even SSH.

After we did this, all works fine with the slave unit.

So we made the changes you suggested.

For now it seems fine.

The disk space don't grow as it did before.

Most of the logs were Traffic logs which wrote on the local disk with a rate of ~300log/sec.

For the moment we are logging via a syslog server.

I will keep you up-to-date.

Cheers,

Stefan.

NotMine · ‎02-20-2016

Hi Stefan,

Have you tried to fail-back to the primary unit? I'm curious to see if the disk is still causing troubles. :) For one of our customers, reinstalling the firmware helped and the unit recovered nicely - it's now working in production.

Cheers,

Slavko

NSE 7

All oppinions/statements written here are my own.

Stefan_H · ‎02-29-2016

Hi Slavko,

we had to send back the 200Ds which are corrupt.

So we have no chance to do such tests.

We talked to our accountmanager in germany and mentioned the problem in detail.

They are not able to give us an information if there is a bugfix available soon.

At the moment they are working on it but there is no solution for now.

Have a good start into the week.

Cheers,

Stefan.

NotMine · ‎02-29-2016

Thanks for the feedback, Stefan. I don't think a new software release can solve this issue, it can only soften it a little. In my opinion, this is a matter of bad hardware choice. Installing an SSD disk into an I/O heavy device (hoping that the customer will not log the traffic and utilize the disk as much) is a bad design choice. But, perhaps they had a good reason for this, albeit I do not see it.

Cheers! :)

NSE 7

All oppinions/statements written here are my own.

Sanjay_P · ‎03-13-2016

We had the same issue with 100D. SSH was working but GUI was not. We issued reboot command via SSH but it did not reboot at that time and it went down after 1hr and did not come up. Finally we had to request for RMA for the same. We received the new firewall from fortigate but after few days that also showing the same error while accessing the FW.

We are using fortigate in our most of the location and every once in a week this error will popup in any of the locations.

Rebooting is not safe once error comes. Fortigate should come up with a permanent solution. Even latest firmware doesn't help for this issue..

Rafael_Rosseto · ‎06-17-2016

Hello, I have a lot of devices with same error: httpsd incomplete headers (0 bytes) received from server "/migadmin/index.py 200D - 5.2.6 3700D - 5.2.7 200D - 5.2.7 So I do not recommend upgrade firmware. Looks like something in regarding disk.

Prometheus · ‎07-07-2016

Hi all,

We have the same problem on our 100D HA cluster using firmware 5.2.7. The web interface gives error 500 Internal Server Error.

in the releasenotes of firmware version 5.2.8 there seems to be an solution to the problem. Did anybody test this yet?

dethangel · ‎07-12-2016

Is there any resolution to this issue?

I have got a 14 day old 200D that's exhibiting this issue, for now I daren't restart the unit.

Going in by SSH and doing a show command - only a couple of line display and the whole SSH session hangs, we'll need to close and open the session again.

Prometheus · ‎07-12-2016

Im not sure yet if it is a good solution, but we installed version 5.2.8 on our test devices and that seems to be working ok. Maybe worth a try.