Killing an unknown self restarting server on port 80 Mac OSX - macos

I have a server running on port 80, but I do not know what it is or where it came from. When I run
sudo lsof -i :80 | grep LISTEN
I get
httpd 80 root 5u IPv6 0x91f5a9de62859cfd 0t0 TCP *:http (LISTEN)
httpd 694 _www 5u IPv6 0x91f5a9de62859cfd 0t0 TCP *:http (LISTEN)
I have tried to enter get the process name using the PID, but all I ever get in return is "httpd" or "FOREGROUND".
When I kill the PID, the process simply restarts with a new PID. I assume I will have to stop it at launch.
How can I stop this server from running at startup?
If it helps any, I am trying to free up port 80 to use the apache server on MAMP.

This is just a guess, but it might be the built-in version of apache, being launched (& restarted) by launchd (OS X's daemon manager). It's disabled by default, but might've gotten enabled somehow. You can try disabling it with:
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
If that doesn't do it (it'll say something like "Could not find specified service"), you can check to see if it's some other launch daemon item by looking for the PID of the master process (the one running as root, not _www):
sudo launchctl list | grep <masterPID>
That won't necessarily tell you exactly what's going on, but might point you in the right direction.

Like Gordon suggested, that's the built-in version of the Apache web server.
You can stop it with
sudo apachectl stop
btw, the configuration for this webserver can be found in the /etc/apache2/httpd.conf directory.

This happens to me a lot.
As #Gordon Davisson explains it is most likely the launchdeamon process conflicting with the service you have set up.
Definitely stop the apachetl server.
sudo apachetl -k stop
Try to find all the httpd process, they should be the last ones
sudo lsof -i :80 // without grep
Then get the first process (most likely in the 1000s) should also be the lowest one.
sudo kill <firstHttpdPID>
This should kill ALL the processes running that httpd instance and then you get simply start back up your server.
Must stop it first though or it will continue running again.

Mac OSX comes bundled with Apache, however it is deactivated. You might have activated it somehow. In my case, I have previously install XAMPP and configured something in the /etc/apache2/httpd.conf that leads my port localhost:80 to leads to html page with It Works!.
TLDR, the solution is to deactivate the Apache2 server.
Go to your terminal, and type this
sudo apachetl -k stop
In my case, it returns the following:
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using Shafies-MacBook-Pro.local. Set the 'ServerName' directive globally to suppress this message
httpd (no pid file) not running
if you typed localhost on your browser, the port 80 is not active anymore and you will not see It Works! anymore.
For context, I have deleted XAMPP long time ago and not aware that my localhost:80 is still active. I am not able redirect dummy domain -- posts.com to my localhost port for my kubernetes YAML config files.
This is my ingress-srv.yaml file:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress-srv
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/use-regex: 'true'
spec:
rules:
- host: posts.com
http:
paths:
- path: /?(.*)
backend:
serviceName: client-srv
servicePort: 3000
and I have tricked the operating system to redirect my posts.com to localhost:80 by adding below line in the hosts file located at /etc/hosts
127.0.0.1 posts.com
by SM

Related

Macbook M1 Apache seems to be always running

It seems like there's some kind of apache is always running on my Macbook with M1 Pro chip. It always shows "It works!" page on by the localhost address with no ability to change it. Even if I run sudo apachectl stop - it's still running, taking my 80 port. Can I stop it somehow? I can't really create any virtual host because of that
In a terminal, type
sudo lsof -i -n -P | grep TCP
find out which app (may not be the Apache Server) is listening on TCP 127.0.0.1:80 and then stop/kill it.

Docker / Postgres - Error starting userland proxy: listen tcp4 0.0.0.0:5432: bind: address already in use [duplicate]

When I run docker-compose up in my Docker project it fails with the following message:
Error starting userland proxy: listen tcp 0.0.0.0:3000: bind: address already in use
netstat -pna | grep 3000
shows this:
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN -
I've already tried docker-compose down, but it doesn't help.
In your case it was some other process that was using the port and as indicated in the comments, sudo netstat -pna | grep 3000 helped you in solving the problem.
While in other cases (I myself encountered it many times) it mostly is the same container running at some other instance. In that case docker ps was very helpful as often I left the same containers running in other directories and then tried running again at other places, where same container names were used.
How docker ps helped me:
docker rm -f $(docker ps -aq) is a short command which I use to remove all containers.
Edit: Added how docker ps helped me.
This helped me:
docker-compose down # Stop container on current dir if there is a docker-compose.yml
docker rm -fv $(docker ps -aq) # Remove all containers
sudo lsof -i -P -n | grep <port number> # List who's using the port
and then:
kill -9 <process id> (macOS) or sudo kill <process id> (Linux).
Source: comment by user Rub21.
I had the same problem. I fixed this by stopping the Apache2 service on my host.
You can kill the process listening on that port easily with one command below :
kill -9 $(lsof -t -i tcp:<port#>)
ex :
kill -9 $(lsof -t -i tcp:<port#>)
or for ubuntu:
sudo kill -9 `sudo lsof -t -i:8000`
Man page for lsof : https://man7.org/linux/man-pages/man8/lsof.8.html
-9 is for hard kill without checking any deps.
(Not related, but might be useful if its PORT 5000 mystery) - the culprit process is due to Mac OS monterery.
The port 5000 is commonly used to serve local development servers. When updating to the latest macOS operating system, I was unable the docker to bind to port 5000, because it was already in use. (You may find a message along the lines of Port 5000 already in use.)
By running lsof -i :5000, I found out the process using the port was named ControlCenter, which is a native macOS application. If this is happening to you, even if you use brute force (and kill) the application, it will restart itself. In my laptop, lsof -i :5000 returns that Control Center is being used by process id 433. I could do killall -p 433, but macOS keeps restarting the process.
The process running on this port turns out to be an AirPlay server. You can deactivate it in
System Preferences › Sharing, and unchecking AirPlay Receiver to release port 5000.
I had same problem,
docker-compose down --rmi all (in the same directory where you run docker-compose up)
helps
UPD: CAUTION - this will also delete the local docker images you've pulled (from comment)
For Linux/Unix:
Simple search for linux utility using following command
netstat -nlp | grep 8888
It'll show processing running at this port, then kill that process using PID (look for a PID in row) of that process.
kill PID
In some cases it is critical to perform a more in-depth debugging to the problem before stopping a container or killing a process.
Consider following the checklist below:
1) Check you current docker compose environment
Run docker-compose ps. If port is in use by another container, stop it with docker-compose stop <service-name-in-compose-file> or remove it by replacing stop with rm.
2) Check the containers running outside your current workspace
Run docker ps to see list of all containers running under your host.
If you find the port is in use by another container, you can stop it with docker stop <container-id>.
(*) Because you're not under the scope of the origin compose environment - it is a good practice first to use docker inspect to gather more information about the container that you're about to stop.
3) Check if port is used by other processes running on the host
For example if the port is 6379 run:
$ sudo netstat -ltnp | grep ':6379'
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 915/redis-server 12
tcp6 0 0 ::1:6379 :::* LISTEN 915/redis-server 12
(*) You can also use the lsof command which is mainly used to retrieve information about files that are opened by various processes (I suggest running netstat before that).
So, In case of the output above the PID is 915. Now you can run:
$ ps j 915
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 915 915 915 ? -1 Ssl 123 0:11 /usr/bin/redis-server 127.0.0.1:6379
And see the ID of the parent process (PPID) and the execution command.
You can also run: $ pstree -s <PID> to a visual display of the process and its related processes.
In our case we can see that the process probably is a daemon (PPID is 1) - In that case consider running: A) $ cat /proc/<PID>/status in order to get a more in-depth information about the process like the number of threads spawned by the process, its capabilities, etc'.
B) $ systemctl status <PID> in order to see the systemd unit that caused the creation of a specific process. If the service is not critical - you can stop and disable the service.
4) Restart Docker service
Run: sudo service docker restart.
5) You reached this point and..
Only if its not placing your system at risk - consider restarting the server.
In my case it was
Error starting userland proxy: listen tcp 0.0.0.0:9000: bind: address already in use
And all that I need is turn off debug listening in php storm
Most probably this is because you are already running a web server on your host OS, so it conflicts with the web server that Docker is attempting to start.
So try this one-liner before trying anything else:
sudo service apache2 stop; sudo service nginx stop; sudo nginx -s stop;
I had apache running on my ubuntu machine. I used this command to kill it!
sudo /etc/init.d/apache2 stop
I was getting the below error when i was trying to launch a new container -
listen tcp 0.0.0.0:8080: bind: address already in use.
To check which process is running on port 8080, run below command:
netstat -tulnp | grep 8080
i got the output below
[root#ip-112-x6x-2x-xxx.xxxxx.compute.internal (aws_main) ~]# netstat -tulnp | grep 8080 tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN **12749**/java [root#ip-112-x6x-2x-xxx.xxxxx.compute.internal (aws_main) ~]#
run
kill -9 12749
Then try to relaunch the container it should work
If redis server is started as a service, it will restart itself when you using kill -9 <process_id> or sudo kill -9 `sudo lsof -t -i:<port_number>` . In that case you will need to stop the redis service using following command.
sudo service redis-server stop
I upgraded my docker this afternoon and ran into the same problem. I tried restarting docker but no luck.
Finally, I had to restart my computer and it worked. Definitely a bug.
Check docker-compose.yml, it might be the case that the port is specified twice.
version: '3'
services:
registry:
image: mysql:5.7
ports:
- "3306:3306" <--- remove either this line or next
- "127.0.0.1:3306:3306"
Changing network_mode: "bridge" to "host" did it for me.
This with
version: '2.2'
services:
bind:
image: sameersbn/bind:latest
dns: 127.0.0.1
ports:
- 172.17.42.1:53:53/udp
- 172.17.42.1:10000:10000
volumes:
- "/srv/docker/bind:/data"
environment:
- 'ROOT_PASSWORD=secret'
network_mode: "host"
I ran into the same issue several times. Restarting docker seems to do the trick
A variation of #DmitrySandalov's answer: I had tomcat/java running on 8080, which needed to keep going. Looked at the docker-compose.yml file and altered the entry for 8080 to another of my choosing.
nginx:
build: nginx
ports:
#- '8080:80' <-- original entry
- '8880:80'
- '8443:443'
Worked perfectly. (The only wrinkle is the change will be wiped if I ever update the project, since it's coming from an external repo.)
At first, make sure which service you are running in your specific port. In your case, you are already using port number 3000.
netstat -aof | findstr :3000
now stop that process which is running on specific port
lsof -i tcp:3000
I resolve the issue by restarting Docker.
It makes more sense to change the port of the docker update instead of shutting down other services that use port 80.
Just a side note if you have the same issue and is with Windows:
In my case the process in my way is just grafana-server.exe. Because I first downloaded the binary version and double click the executable, and it now starts as a service by user SYSTEM which I cannot taskkill (no permission)
I have to go to "Service manager" of Windows and search for service "Grafana", and stop it. After that port 3000 is no longer occupied.
Hope that helps.
The one that was using the port 8888 was Jupiter and I had to change the configuration file of Jupiter notebook to run on another port.
to list who is using that specific port.
sudo lsof -i -P -n | grep 9
You can specify the port you want Jupyter to run uncommenting/editing the following line in ~/.jupyter/jupyter_notebook_config.py:
c.NotebookApp.port = 9999
In case you don't have a jupyter_notebook_config.py try running jupyter notebook --generate-config. See this for further details on Jupyter configuration.
Before it was running on :docker run -d --name oracle -p 1521:1521 -p 5500:5500 qa/oracle
I just changed the port to docker run -d --name oracle -p 1522:1522 -p 5500:5500 qa/oracle
it worked fine for me !
On my machine a PID was not being shown from this command netstat -tulpn for the in-use port (8080), so i could not kill it, killing the containers and restarting the computer did not work. So service docker restart command restarted docker for me (ubuntu) and the port was no longer in use and i am a happy chap and off to lunch.
maybe it is too rude, but works for me. restart docker service itself
sudo service docker restart
hope it works for you also!
I have run the container with another port, like... 8082 :-)
I came across this problem. My simple solution is to remove the mongodb from the system
Commands to remove mongodb in Ubuntu:
sudo apt-get purge mongodb mongodb-clients mongodb-server mongodb-dev
sudo apt-get purge mongodb-10gen
sudo apt-get autoremove
Let me add one more case, because I had the same error and none of the solutions listed so far works:
serv1:
...
networks:
privnet:
ipv4_address: 10.10.100.2
...
serv2:
...
# no IP assignment, no dependencies
networks:
privnet:
ipam:
driver: default
config:
- subnet: 10.10.100.0/24
depending on the init order, serv2 may get assigned the IP 10.10.100.2 before serv1 is started, so I just assign IPs manually for all containers to avoid the error. Maybe there are other more elegant ways.
I have the same problem and by stopping docker container it was resolved.
sudo docker container stop <container-name>
i solved with this sudo service redis-server stop

Valet (Laravel): DNS address can not be found

I'm trying out Valet, it looks really nice from what I've heard.
I've been trough the "whole" installation process, Valet is succesfully installed.
But when I cd into my projects file and enter valet park and browse to http://blog.dev, I get "The DNS server address of blog.dev can not be found."
I have no idea what I'm doing wrong. :)
When you run valet install it attempts to install dnsmasq. It requires sudo privileges.
You can check that it's installed and running using
brew services list
You should see something like
dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
You may however need to tap brew/services first
brew tap homebrew/services
If it's not there, run
brew install dnsmasq
brew services start dnsmasq
Run valet install again to set up dnsmasq and keep an eye out for any errors. What this should do is append a line to the bottom of /usr/local/etc/dnsmasq.conf similar to
conf-file=/Users/{YOURUSER}/.valet/dnsmasq.conf
/Users/{YOURUSER}/.valet/dnsmasq.conf then should contain
address=/.dev/127.0.0.1
Check that your dns server is responding to requests
dig testing.dev #127.0.0.1
You should see a response like
;; ANSWER SECTION:
testing.dev. 0 IN A 127.0.0.1
To actually ensure that your Mac knows that it should resolve *.dev using your local DNS server, it need to be told to do so. Valet also handles this for you but you can check if it's done it's job by doing the following.
Inside the directory /etc/resolver, there should be a file entitled dev with the following contents
nameserver 127.0.0.1
This creates a custom DNS resolver for *.dev and points all requests at your local DNS server.
Restart dnsmasq with either of the following commands and then give it a try again.
// this
brew services restart dnsmasq
// or this
sudo launchctl stop homebrew.mxcl.dnsmasq
sudo launchctl start homebrew.mxcl.dnsmasq
If this is all working, you should be able to ping anything.dev
ping anything.dev
PING anything.dev (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.039 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.081 ms
That ensures the DNS related bits are working.
Ultimately the question is about DNS related problems but as this started off as a here's everything you need to have tried, I'll leave this below. That said, if you're unable to ping something.dev or get an error like "The DNS server address of blog.dev can not be found." as per the OP, it's something above to do with DNS which needs resolving.
Since Caddy serves websites on port 80, you need to ensure that nothing else is running on port 80.
sudo lsof -n -i:80 | grep LISTEN
Ideally this should return caddy if valet is running as expected. You want to see the example below or nothing ideally; nothing because it means we can just start Valet.
caddy 76234 root 3u IPv6 0x4f871f962e84fa95 0t0 TCP *:http (LISTEN)
You may see other webservers, such as Apache or Nginx (and their child processes, _www and nobody) in the example below.
httpd 79 root 4u IPv6 0xf4641199930063c5 0t0 TCP *:http (LISTEN)
httpd 239 _www 4u IPv6 0xf4641199930063c5 0t0 TCP *:http (LISTEN)
nginx 4837 root 6u IPv4 0xf4641199a4e8e915 0t0 TCP 127.0.0.1:http (LISTEN)
nginx 4838 nobody 6u IPv4 0xf4641199a4e8e915 0t0 TCP 127.0.0.1:http (LISTEN)
Assuming you've installed Nginx with homebrew you can run the following to stop it.
brew services stop nginx
OSX ships with Apache installed so you can stop with with the following if it's running.
sudo apachectl stop
At this point you can likely start Valet with valet start and it'll work.
You may get a further error which is caused by PHP being installed without FPM. You can check this using
brew info php70 | grep php70-fpm
Which should yield something along the lines of
The control script is located at /usr/local/opt/php70/sbin/php70-fpm
If it doesn't appear to be installed, use the following.
brew uninstall homebrew/php/php70
brew install homebrew/php/php70 --with-fpm
valet restart
I had the same problem - getting stuck at ping foobar.dev - and fixed it by restarting my Macbook (after valet install). I am sure this is not an exact solution and I reckon there is a way to do this without restarting. Yet, it worked for me. I did not have to do any other steps.
[Edit - Additionally, before restarting I made sure to try the installing with fpm tip, and to follow all brew's suggestions upon installing php70 (tweaking the path, making sure php70 starts on system start. I cannot say whether these things helped, so probably want to try just restarting, first. If it's really just a restart that's required, or some other additional step to properly start services, I think the laravel documentation probably needs some clarification.]
I had the same problem, post installation I got stuck at pinging foo.dev.
I checked for running services.
> brew services list
Name Status User Plist
dnsmasq stopped
nginx stopped
php71 stopped
Started all the three services manually with
> brew services start dnsmasq
> brew services start nginx
> brew services start php71
Ran valet install.
Ping successfully to foo.dev
If you are a Windows user,
Perform the Acrylic Configuration then restart your adapter(Disable and Enable)
http://mayakron.altervista.org/wikibase/show.php?id=AcrylicWindows10Configuration
Worked For Me

The port 80 in Mac is used

We have to use port 80 for our server. But when I was trying to use it in Mac, it always said that the 80 is used, but I don't know which program uses it.
I searched it in Google, and someone said it's about apache, but I tried, which is not working. I found this: https://gist.github.com/kujohn/7209628 , but seems it's not working visiting our server by IP address.
I really don't know what's going on and how can I find out which program using port 80 and stop it.
Many thanks if anyone can help, I'm new using Mac. Thanks.
To find out what process is using port 80
go to Applications
open utilities.
open Activity Monitor.
click on the Memory tab,
look at the ports and the processes using them. Find port 80 and select it
go to the view on the menu bar and choose Quit process.
This will just kill the process, it will not stop a server instance that is already running from continuing to run.
(Correction: the Ports column shows the number of open ports (and files?), not the port number)
It is not clear if you are using a database management system or not and which one but one method that has worked for me using MAMP is as follows.
stop the server by using sudo apachectl stop command.
then change the port to port 80.
then restart your servers.
type the following in Terminal
sudo lsof -i -n -P | grep TCP
you will get a list - e.g. dropbox listens on 80
you can copy the output to a text editor, etc to search
On Mac ports below 1024 can only be bound by the root user.
Try launching your server as root user (with sudo), or try to use a port above 1024.
You can also try to add root permissions to your user in /etc/sudoers
# root and users in group wheel can run anything on any machine as any user
root ALL = (ALL) ALL
%admin ALL = (ALL) ALL
your_user_here ALL = (ALL) ALL
I was having this issue, apache was disabled via launchctl, but was still tying up port 80 after launch, I could start up apache and it would work, but after unloading it, I couldn't start up anything on port 80. I was using the built in web server for Python as an easy test. It would work on port 81, but not on port 80.
sudo python -m SimpleHTTPServer 80 -- wouldn't work
sudo python -m SimpleHTTPServer 81 -- would work
Here are the symptoms:
$ launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
/System/Library/LaunchDaemons/org.apache.httpd.plist: Could not find specified service
$ sudo lsof -i ':80'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Python 3353 root 3u IPv4 0xe455777a82799f05 0t0 TCP *:http (LISTEN)
The fix for me (after way too much searching) was simple:
sudo pfctl -F all
This flushed the packet filter, releasing port 80 (and others I assume 8080, 443, whatever ports apache might be tying up)
After that, and relaunching the python server, it came right up.
Might be Skype that is using port 80. If you have Skype installed and running try to change to a different port in the settings.
Port numbers in the range from 0 to 1023 are classified as 'well-known' and port number 80 is reserved for HTTP. Typically you have servers listening on port 80 to handle HTTP requests.
Source:
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

Phusion passenger can't free port

Ok, i'm running passenger standalone, and made a dumb mistake, now I need help fixing.
So a test app directory was running standalone passenger on a specific port, and I deleted the directory so that I could pull a new app in place of it (and use the same port). Well, not thinking about passenger at all, I should have stopped the daemon first. Well, now the port is tied up somewhere, and I cannot figure out for the life of me how to stop it. I found the process that the port started on, and killed it, but to no avail. The address is still bound and unusable.
Short of restarting the server (not really a viable solution for me), how can I kill that nginx / passenger process all together so that I can start a new instance of passenger on that port?
Run lsof -i :portnumber e.g. lsof -i :3000
You will get something like this ...
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Passenger 10514 USERNAME 5u IPv4 0xea95336b89bfa931 0t0 TCP *:hbci (LISTEN)
Passenger 10515 USERNAME 5u IPv4 0xea95336b89bfa931 0t0 TCP *:hbci (LISTEN)
Stop the processes using kill PID ... something like kill 10514
Passenger Standalone starts Nginx for you, and that is what is actually bound to the port. Because you deleted the directory, Passenger Standalone cannot access Nginx's lock file or PID file, and that's why upon killing Passenger Standalone it could cannot kill Nginx for you. You should kill Nginx manually.

Resources