pfSense GUI unresponsive when WAN drops
-
That is indeed strange behavior then. I would expect it to be sporadically slow, especially when
dpinger(if enabled) goes into its "alarm" mode and restarts things in an attempt to recover connectivity. But to eventually spin down to a complete hang is strange.That particular URL requested in your posted log snippet is strange as well. Were you actively trying to view that page, or do you have some kind of automated logging set up? What device was using the 192.168.0.194 IP address? Was it your workstation?
-
Wasn't this setting a workaround , for the "Gui issue" if was is down ?
One of the things the gui does (eagerly) , is to check if there are any updates.
And you need a working WAN for that.This one disables that check. I suppose you might loose the automatic update check, if disabling
Edit: I have not seen a real timeout here on wan down , just a super slow gui response.
/Bingo
-
@bmeeks Yes I was actively trying to view that page. I was just randomly clicking on things watching the GUI get slower and slower until I got the 504 Gateway Time-out. It's nothing to do with that particular page the whole GUI is affected.
192.168.0.194 was firefox on my Mac.
-
If you haven('t already done so, enable the SSH access.
Or use the console.
Menu option 8.
Optional, as it looks better/nicer :pkg install htop'top' is installed by default.
No use top or htop
Have it sorted on CPU utilsation (hit F6 and select CPU percentage).Now, make the WAN go down. Look at what processes are using the CPU - these are at the top.
Btw : when your uplink connection goes down, is it the pfSense WAN interface that goes down, or the link upstream becomes bad while the pfSEnse WAN interface stays up ?
-
@bingo600 Ok I'll test with auto-update check disabled. Thanks for the suggestion.
-
@gertjan thanks but as I said above it's not an issue of CPU utilisation and the box being busy. CPU utilisation is always close to 0%. There is no process causing any problem like that. The GUI simply stops responding and I have to "Restart PHP-FPM". Then it works again for a few minutes before it gives me a 504 Gateway Time-out again.
-
It's not the cpu utilisation, but more what processes are running at that moment. These will rise to the top of the queue.
It's time to find out if it's related to the web server (nginx) or the PHP engine.
What does the System log mentions when the issue happens ?
And the DNS log ?
DHCP log nothing special ?Btw, : I'm also using the NUT package.
-
@gertjan Ok thanks I'll check what htop shows. I'm pretty sure there is nothing in dns/dhcp/system logs of interest apart from the "fastcgi://unix:/var/run/php-fpm.socket" error above.
-
What you could try is this :
Backup your config.
Go to the console or SSH access and use option 4 : 'reset to default'.
Don't change any settings. If needed, make WAN work. WAN is set up to be a DHCP client, so pfSense could work out of the box.
Do not change anything else.
( ok for changing the password )Now, test.
Same behaviour ?Go go back to the set up with issues : import your backed up config back in again.
-
@gertjan Yep reset to default. Then try disconnecting WAN. I suppose I will have to try that. Just surprised I'm the only one apparently having this problem. I will try reset to default and see if I get the same behaviour.
-
@flarednostril said in pfSense GUI unresponsive when WAN drops:
@gertjan Yep reset to default. Then try disconnecting WAN. I suppose I will have to try that. Just surprised I'm the only one apparently having this problem. I will try reset to default and see if I get the same behaviour.
We all agree the GUI may get a bit sluggish with no WAN connection, especially so if the Dashboard "home page" is being viewed and "Check for Updates" is checked. But I personally have never seen the pfSense GUI just basically slowly die as you describe.
