I’ve updated Local to version 5.2.3 on MacOS High Sierra lately. Alongside that I also use DDEV. Firing up the latter brought to my attention that a process is blocking port 443. Running lsof showed that a nginx process is actually occupying that port. Turned out that the process is originated in /Applications/Local.app/Contents/Resources/extraResources/lightning-services/nginx-1.16.0+3/bin/darwin/sbin/ and is even running as root. Fun fact Local.app wasn’t running at all. So what is the reasoning to keep nginx running at all if the Local.app is quit and what other process keep running aside those two nginx ones??? If I quit an app I consider all associated services quit alongside. I also prefer to have an informed decision if services and process have to be kept alive otherwise. Hope this bug is fixed soon. 
This is very frustrating. It makes it difficult to use Local alongside another server. In my case, I want to run MAMP Pro and Local side by side.
Here’s how MAMPs servers work, for comparison:
When the MAMP front-end application is launched, it starts the servers (NGINX/Apache/MySQL/etc.). Like Local, the servers will continue to run after the MAMP application is closed. The difference is that in MAMP there is a big button labelled “Servers”, which will stop and start the servers.
Local has no such button, so once NGINX is running there is no GUI to stop it, and thereby free up ports for MAMPs servers.
In addition, Local has a launch daemon that starts NGINX on system boot, which means even if you haven’t started Local, it hijacks the ports anyway.
Currently if you want to free up those ports you need to kill Local’s NGINX processes. On macOS:
sudo /Applications/Local.app/Contents/Resources/extraResources/lightning-services/nginx-1.16.0+3/bin/darwin/sbin/nginx -c "/Users/username/Library/Application Support/Local/run/router/nginx/conf/nginx.conf" -p "/Users/username/Library/Application Support/Local/run/router/nginx" -s stop
(You will need to change “username” to your macOS username. And note that the path to NGINX might change in future versions of Local).
After issuing that command NGINX will gracefully shutdown, and ports 80 and 443 become available.
However, you will need to manually restart Local’s NGINX server if you want to use Local again (or reboot your computer, ugh):
sudo nohup /Applications/Local.app/Contents/Resources/extraResources/lightning-services/nginx-1.16.0+3/bin/darwin/sbin/nginx -c "/Users/username/Library/Application Support/Local/run/router/nginx/conf/nginx.conf" -p "/Users/username/Library/Application Support/Local/run/router/nginx" -g "user root staff;" &
(Again, change “username” to your macOS username).
I humbly request that Local’s developers:
- Add a “start/stop servers” button inside the application.
- Add an options allowing the user to decide if Local’s servers should start on system boot.
EDIT: I have made a feature request. Please vote for it is you think this functionality is important.
I found that quitting Local frees up the ports.
netstat -an -ptcp | grep LISTEN
Not for me I’m afraid 
I still see:
tcp4 0 0 *.443 . LISTEN
tcp6 0 0 *.80 . LISTEN
tcp4 0 0 *.80 . LISTEN
I have to manually stop NGINX to kill the processes (using the command in my earlier post, or by stopping the processes in Activity Monitor).
I installed Local on another computer, and this time everything works smoothly…
As @afragen described, Local’s NGINX processes are stopped when Local closes.
Also, the LaunchDaemon I described was not created on this computer, so NGINX doesn’t start when the system boots.
So on this computer, everything works exactly as I would expect.
The only obvious difference between the two systems is that the faulty one runs High Sierra macOS, and this one runs Mojave. I think both are running Local 5.2.5.
I would chalk this up as a localised error, but the fact that a LaunchDaemon was created only on one system seems super odd? Maybe the devs couldn’t get NGINX to start/stop when Local starts/stops on High Sierra, so they opted to launch NGINX at system startup instead?
Blockquote I found that quitting Local frees up the ports.
netstat -an -ptcp | grep LISTEN
Nope. Quitting Local doesn’t help on MacOS. Nginx is still occupying the particular ports as I described cuz Nginx is still running after Local is quit.
@jnicol followed your suggestion and took a look on High Sierra. In /Library/Launchdaemons/com.getflywheel.local.router.plist Nginx is listed and started there no matter if Local.app is started or not. Is it the same on Mojave or is that plist entry for Nginx missing there?
The launch daemon wasn’t created when I installed Local 5.2.5 on Mojave, only on my High Sierra machine.
You mentioned in your first post that you are using Local 5.2.3. Have you upgraded to 5.2.5, and does that make any difference? I will double check what version I’m running on my High Sierra machine when I’m in the office later on - it should be 5.2.5, since I only installed Local 3 days ago.
When I’ve noticed the issue I was running 5.2.3, there I also checked the LaunchDaemon. Afterwards the in app updater found version 5.2.5 when I’ve started the Local.app. I’ve updated but that hasn’t changed anything. The LaunchDaemon is still there and Nginx running.
You can’t delete the launch daemon either. Local will recreate it next time you start a site.
On Mojave the opposite is true: if you manually create com.getflywheel.local.router.plist in /Library/Launchdaemons/, Local will delete it!
This is increasingly seeming like an issue specific to High Sierra.
If any Flywheel team members are following this thread, I would love to know in what circumstances Local adds & removes the launch daemon, and why?
I’ve already expected that Local would recreate the launch daemon on its next start in case it is deleted. But it is indeed odd that on High Sierra and Mojave things are handled in the exact opposite way.
Well, I upgrade to Mojave… 
After upgrading I deleted the LaunchDaemon, and that didn’t immediately fix things (Local complained about a router problem), but after uninstalling and reinstalling Local everything works correctly.
Local also now correctly detects when another application is listening on port 80 or 443 (e.g. MAMP), and warns about the conflict. Previously that wasn’t the case.
It’s obviously not a tidy solution, but as long as it’s only for WordPress, I have been running MAMP Pro and Local concurrently using MAMP’s standard ports instead of 80 and 443. I seem to recall I was even able to migrate sites from MAMP to Local using Migrate DB Pro (maybe it only worked with Push the other way round, it’s been a while).
hm my solution was simply deleting Local and stop using it.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.