I'm running Solr 8.2 on OSX 10.13.5. The Solr dashboard is accessible in my browser (via http://localhost:8983), yet when I run the terminal command "bin/solr create -c test" to create a core, after a few moments I end up with:
ERROR: Connection reset
I've tried booting Solr as sudo, and the result is the same. I'm at a bit of a loss here. How can I resolve this connection error and create a core? Thanks!
I figured this out. It turns out that port 8983 was still in TIME_WAIT mode. I obtained the port's PID with:
sudo lsof -i :8983
Then closed the port with:
kill PID
Where 'PID' is the numerical PID of the port. With the port now being free of traffic, the core creation worked just fine. I'm leaving this posted in case any other Solr beginners hit this snag!
Related
I just find out that when I simply type 'localhost' in the url without anything more in the path, the browser displays a message from a local backend test project in Express that I've made days ago.
I'm trying to stop this process.
I was sure that to have started this server on port 3001 but when I try to kill it , it says that there is no process running on this port.
I tried to kill 8080 as well, but the message is still displayed.
Obviously, I refreshed the page, I tried on several different browser, even restarted my computer.
How can i determine which port is running?
How can I stop the process?
[Edit]:
Here's what I keep receiving :
<html><head></head><body><h1>It works!</h1>
</body></html>
You could use lsof:
lsof -i #localhost
Can you try this command :
sudo lsof -nP -i4TCP:80
Attempting to kill port and locate possible process paths
I'm trying to use the Postgres.app to utilize the database, but keep running into the "Port in use" issue. I had originally brew installed postgres, but opted to use the app instead. So I brew removed postgres and installed Postgres.app. But now when I try to connect, it says that the port is in use. From everything that I've read, postgresql is the only process that listens at that port (I'm not using any other databases like MySQL). So, I was going to try to use the sudo launchctl unload -w /path_to/process command, but as you can see above...when I use which postgres or which postgresql, there's no path found. I also tried killing the connection to the port, but the ghost postgresql automatically connects right afterwards. Any tips on how to find out what the heck is listening on the port and prevent it from auto-connecting?
Edit: I tried using the Activity Monitor to see if I had accidentally installed a second version of the postgres.app. I checked to see what was the PID of the process listening in on the port. But it's not listed in the activity monitor. So I still have no idea how to find whatever is listening on the port
PID not listed in Activity monitor screen
I have been following this tutorial to try and setup a single node mesosphere cluster from their
official tutorial:
http://mesosphere.com/docs/getting-started/developer/single-node-install/
I followed all the commands without any issues, and I also added the ports 5050 and 8080 to my security group. When I try to access the console for mesos/marathon, I get a "Internet Explorer cannot display the webpage" message.
They also recommend checking it the following way:
MASTER=$(mesos-resolve `cat /etc/mesos/zk`)
mesos-execute --master=$MASTER --name="cluster-test" --command="sleep 5"
But that comes up with an error:
WARNING: Logging before InitGoogleLogging() is written to STDERR
F0106 17:03:08.126703 20993 process.cpp:1561] Failed to initialize, gethostbyname2: Unknown host
*** Check failure stack trace: ***
I am not really sure how to troubleshoot this either, and there are not many tutorials I could find on how to install mesos on ubuntu.
I checked the contents of the zk file, seems to be the default value.
$ cat /etc/mesos/zk
zk://localhost:2181/mesos
I would really appreciate any clues on how to go about this one.
Edit: The process is definitely running too - just an fyi:
root 31545 8.5 5.9 187464 35604 ? Ssl 17:28 0:00 /usr/local/sbin/mesos-slave --master=zk://localhost:2181/mesos --log_dir=/var/log/mesos
root 31563 28.5 2.1 116304 12856 ? Rs 17:28 0:00 /usr/local/sbin/mesos-master --zk=zk://localhost:2181/mesos --port=5050 --log_dir=/var/log/mesos --quorum=1 --wo
Mesos uses gethostbyname2 to resolve hostnames to IPs. The first thing I would recommend, is to try "ping localhost" and "ping hostname", and verify that there are no strange settings in /etc/hosts. If you're doing a multi-node cluster, I'd recommend that hostname map to the public IP address (not 127.0.x.1).
If that doesn't help, you can try setting the --ip and --hostname flags when starting mesos-master and mesos-slave, to bypass the gethostbyname2 resolution. These can also be set by writing to the file-based parameters, e.g. /etc/mesos/mesos-master/ip
For additional troubleshooting, try running wget http://localhost:5050 (or curl -L) from the mesos master, to verify that it is locally visible. Also try wget http://<public_ip>:5050 to verify that the web server is up and serving to the public IP. Depending on how your (EC2?) node is setup, you may need to expose/forward the port, or connect to a VPN.
Thanks Adam. I ran the wget and curl commands, and nothing was actually listening on port 8080 or 5050. I did open those ports in the ec2. A simple reboot did the trick however, once I ssh'ed into the ec2 instance after the reboot, both mesos and marathon were running and both ports are now showing after I ran
netstat -ntln.
I have run into a number of cases where the postgresql connection is in a bad state. OK, I'll make this complicated by having a master with a couple of slave servers... And to complicate matters even more, the master is on OS X with postgresql installed via homebrew
So things like
pg_basebackup: could not connect to server: could not connect to server: Connection refused
Is the server running on host "XX.XX.XX.XX" and accepting
TCP/IP connections on port 5432?
crop up. The master postgres/server.log was showing
FATAL: pre-existing shared memory block (key xx, ID yyy) is still in use.
this notwithstanding running
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
to start and stop the service. [head scratch] Got we worrying... So I run
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
I query the master's application and can edit data! WAIT postgresql was supposed to be unloaded!
So launctl is NOT working as expected... This explains why some synching up has fallen by the wayside.
Question 1: How can we ensure that postgres is really stopped on OS X because although it may be risky, the only alternative appears to be to kill the postmaster.pid
Then things went probably haywire in the flow... master's log states:
LOG: could not send data to client: Broken pipe
and effectively one of the VPS is complaining
$ service postgresql stop
Error: pid file is invalid, please manually kill the stale server process.
Question 2: how can those be killed (Ubuntu 14.04) without harming the database and the WAL process that should be updating the slave? (or is there a more effective/saner way of handling master-slave replication?)
I have a Sinatra app that I run as a daemon, using Apache port-forwarding to mediate between port 80 and port 7655. This has been working fine in the past. Today, not so well. I cannot figure out why.
Problem: sudo ruby my_process.rb returns:
/var/lib/gems/1.9.1/gems/eventmachine-1.0.0/lib/eventmachine.rb:526:in `start_tcp_server': no acceptor (port is in use or requires root privileges) (RuntimeError)
Tried: updating all system packages, updating all gems. No help (except for the more clear error message from eventmachine).
When I run sudo lsof -i :7655 I get nothing back. When I run sudo ps aux I don't see any Ruby processes at all. Which I find highly irregular, given the nature of the error message!
So is there something I'm missing in finding out why the port is unavailable?
Also:
Tried changing ports, nothing. I wonder if it is related to "localhost"? When I ping localhost I get all dropped packets. That doesn't seem normal.
Turns out these two lines in the main Sinatra script provided the most information:
set bind: "localhost"
set port: 7655
The problem was with localhost. The loopback interface was not properly configured. ifconfig showed the lo interface, but it hadn't been assigned the IP 127.0.0.1. To resolve, ran the following commands in the shell (on an Ubuntu Linux system):
ifdown lo
ifup lo
When you close term sometime you forget to stop [CTRL+C] the actual server, just run the following command to kill all ruby process like sinatra, and run-it again
killall ruby
You can see your actual ruby process by running
ps -ef | grep ruby