WebGUI went down. Just sharing my story.
Short story: In trying to troubleshoot a problem with a (very) remote pfSense router, I managed to do something to lock up the pfSense webConfigurator. Luckily, I was able to access the pfSense router via SSH, both as myself and root. Restarting the webConfigurator didn't help. Restarting the pfSense router worked (but man was that nerve-racking).
Long story: We noticed really bad downstream throughput at the site yesterday. Narrowed down the problem to something creating a significant draw locally (ie. a P2P client), a bad cable, failing NIC, or a failing port on the ISP's switch. To eliminate a local source of the downstream demand, I began shutting down local interfaces and using the firewall to block all traffic from the remaining local interface that wasn't from a test machine. (The symptoms of the problem persisted despite everything being down, so we are thinking this is a cabling issue.) This was all done very carefully as it is a 3 hour drive to the site and there was freezing rain between here and there. Some of the roads are currently closed.
All of a sudden, I couldn't access the web interface. This was at least a minute or two after I changed anything, which always make me look at DNS, but I really have no idea. After a short freak-out, I noticed that I could SSH to the single remaining interface on the local side. I restarted the webConfigurator but it did nothing. Restarting the pfSense router did the trick and I began
This is the first time the webConfigurator has locked up on me and I'm a bit shaken. I'm about to confirm that we can SSH into all of the pfSense routers across our WAN in case this happens again.
Just thought I'd share with the hope that it might help save someone else who puts all their faith in the webConfigurator.
I too have had that happen. As it turned out, it was waiting on a timeout cause I left it alone to take a support call (it was in a lab), and when I got back around to it, the WebGUI was active. I think it was autoupdate checking on the dashboard, but I am unsure. This is a 2.1 beta1 test also, and I was able to turn off dashboard checking. I have not had a problem since, but I am still not sure if that was the true cause.
I have had the webgui stop responding several times but it has turned out to be my own doing. On each occasion it was caused by a rogue php process. Mostly this was some experimental code in a package but can also be caused by running a command, in the gui command prompt box, that never finishes. You can usually recover from that via the console with 'killall php'.