OPNsense Forum

English Forums => Web Proxy Filtering and Caching => Topic started by: isJesusHere on July 30, 2022, 06:55:26 pm

Title: nginx start and configcheck extremely slow
Post by: isJesusHere on July 30, 2022, 06:55:26 pm
Haven't had this problem in at least a year. Then, upgrade to 22.7 and it's back.
Restarting nginx from webui or cli will take ages (+5min).

But as soon as I restore a snapshot from 22.1 everything works just fine. Zero changes except the update.

Running opnsense in a esxi vm.

I've submitted a crash report via the webui and put the URL to this topic in the description. Don't know if it'll help
Title: Re: nginx start and configcheck extremely slow
Post by: Fright on August 02, 2022, 08:32:43 pm
you can try to restart it step by step to find out which step takes the most time
/usr/local/opnsense/scripts/nginx/setup.php
/usr/local/etc/rc.d/php-fpm restart
/usr/local/etc/rc.d/nginx restart
Title: Re: nginx start and configcheck extremely slow
Post by: isJesusHere on August 03, 2022, 03:30:02 pm
So that seemed to have worked. Now nginx reloads quick again, but I can only access one of my two upstream servers. Both within the same subnet. If i change the IP of the faulty upstream server I can access it again. Don't know how that's possible. Haven't changed anything else.
Title: Re: nginx start and configcheck extremely slow
Post by: isJesusHere on August 05, 2022, 01:36:08 pm
ok, so i figured out what it was. Somehow routing to that one VM within the subnet isn't working anymore by default. Setting a static route to the VM in opnsense fixed it. Really weird.

A few more infos for somebody else troubleshooting or wanting to fix this:
Opnsense with VLAN 10.10.0.0/24, mgmt net 192.168.178.0/24 (local network of ISP router).
access to VMs within VLAN with routes set to mgmt address setup in ISP router
With these static routes, I could access the VMs by IP from mgmt-net, but nginx couldn't. Where it now needs a static route, it didn't before 22.7. Maybe this is wanted for more granular routing control.

also this was the reason why nginx reload took so long, for anybody asking.