TCPServer Error: Address already in use - bind(2) - ruby

Jekyll was working fine for me few weeks back but now all of a sudden it gives me the following error:
TCPServer Error: Address already in use - bind(2)
INFO WEBrick::HTTPServer#start: pid=7300 port=4000
% lsof -i :4000
<fetches nothing>
Even though nothing is running on the port. Below are the details:
% jekyll --version
Jekyll 0.11.2
% where jekyll
/home/bhaarat/.rvm/gems/ruby-1.9.2-p290/bin/jekyll
/usr/bin/jekyll
% ruby --version
ruby 1.9.2p290 (2011-07-09 revision 32553) [i686-linux]
% rvm --version
rvm 1.10.0
Here is the output
% jekyll --server
Configuration from /home/bhaarat/blog/omnipresent.github.com/_config.yml
Auto-regenerating enabled: /home/bhaarat/blog/omnipresent.github.com -> /home/bhaarat/blog/omnipresent.github.com/_site
[2012-04-21 13:46:40] regeneration: 38 files changed
[2012-04-21 13:46:40] INFO WEBrick 1.3.1
[2012-04-21 13:46:40] INFO ruby 1.9.2 (2011-07-09) [i686-linux]
[2012-04-21 13:46:40] WARN TCPServer Error: Address already in use - bind(2)
[2012-04-21 13:46:40] INFO WEBrick::HTTPServer#start: pid=7382 port=4000
I know the address isn't in use and jekyll is probably breaking for some other reason but throwing that error. What are my options? I've tried re-installing as well.

Type this in your terminal to find out the PID of the process that's using the 3000 port:
$ lsof -wni tcp:3000
Then, use the number in the PID column to kill the process:
$ kill -9 PID

I was not qualified to post comment. So I added a new answer.
I encountered this problem on Mac OS X 10.10.3. And I had never installed/used Jekyll before. I was not able to start jekyll server with its default port number 4000. The reason was that the port was the same as what NoMachine used. With
$ sudo lsof -wni tcp:4000
Note: Running this command without sudo will have no output.
I saw this output:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nxd 449 nx 3u IPv4 0x8d22************ 0t0 TCP *:terabase (LISTEN)
nxd 449 nx 4u IPv6 0x8d22************ 0t0 TCP *:terabase (LISTEN)
The port 4000 was occupied by nxd, which was the process started by NoMachine. And
$ sudo kill -9 449
would not work, because NoMachine's nxd process would keep restarting, with a new PID.
Therefore, I had to either:
Changed my jekyll server port in the site _config.yml to another spared one. I appended the line below to _config.yml and it worked.
port: 3000 # change server port to 3000
or
Changed NoMachine's default nxd port, or Uninstall NoMachine

Ctrl-Z doesn't terminate a program, but rather suspends it and sends it to the background. You can resume the program with the "fg" command. To actually terminate it, use Ctrl-C.
The actual error message seems to be bogus and can be ignored. I am getting the same error message "address in use" but jekyll works fine anyway at the expected port.

I have met this problem recently.
I tried out all the method mentioned above, and even restarted my computer, but still couldn't solve it!!! Then I removed the jekyll and installed a new version, it just worked.
gem uninstall jekyll & gem install jekyll (maybe you need super user priviledge).
If you really get annoyed with similar bugs, this sb method is worth a try...

Based on the top answer, I came up with a simple way
lsof -wni tcp:3000 | xargs -I{} kill -9 {}
It takes the output of finding PID in which port the tcp server is running at. In this case it is 3000.
It then kills the processes running that
PID

Check that you don't have another terminal open where you are already running a server.
If that is the case, do a CTRL-C to shutdown the server, and that will free the port/address.

First you need to find PID of the process that's using the 3000 port:
$ps -ef
Output Like this:
1003 4953 2614 0 08:51 pts/0 00:00:00 -bash
1003 5634 1 0 08:56 pts/0 00:00:00 spring server | moviestore | started 2 hours ago
1003 5637 5634 0 08:56 ? 00:00:01 spring app | moviestore | started 2 hours ago | development mode
1003 6078 4953 0 09:03 pts/0 00:00:03 puma 3.6.0 (tcp://localhost:3000) [moviestore]
1003 6117 2614 0 09:03 pts/1 00:00:00 -bash
root 6520 2 0 09:57 ? 00:00:00 [kworker/u8:2]
root 6936 1225 0 11:09 ? 00:00:00 [lightdm] <defunct>
1003 7084 1 0 11:09 ? 00:00:00 /usr/bin/python /usr/share/apport/apport-gtk
1003 7475 1 0 11:10 ? 00:00:00 /usr/bin/python /usr/share/apport/apport-gtk
root 8739 1225 1 11:29 tty8 00:00:11 /usr/bin/X :1 -auth /var/run/lightdm/root/:1 -nolisten tcp vt8 -novtswitch
root 8853 1225 0 11:29 ? 00:00:00 lightdm --session-child 13 22
1002 8943 1 0 11:30 ? 00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login
1002 8954 8853 0 11:30 ? 00:00:00 gnome-session --session=ubuntu
1002 8992 8954 0 11:30 ? 00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session gnome-session --session=ubuntu
1002 8995 1 0 11:30 ? 00:00:00 /usr/bin/dbus-launch --exit-with-session gnome-session --session=ubuntu
1002 8996 1 0 11:30 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
1002 9007 8954 0 11:30 ? 00:00:00 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
1002 9015 1 0 11:30 ? 00:00:00 /usr/lib/gvfs/gvfsd
1002 9018 8954 1 11:30 ? 00:00:07 compiz
1002 9021 1 0 11:30 ? 00:00:00 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2
1002 9028 8954 0 11:30 ? 00:00:00 /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
1002 9029 8954 0 11:30 ? 00:00:01 nautilus -n
1002 9030 8954 0 11:30 ? 00:00:00 /usr/lib/gnome-settings-daemon/gnome-fallback-mount-helper
1002 9031 8954 0 11:30 ? 00:00:00 nm-applet
1002 9032 8954 0 11:30 ? 00:00:02 /opt/mTrac/mTrac
1002 9033 8954 0 11:30 ? 00:00:00 bluetooth-applet
1002 9045 9032 0 11:30 ? 00:00:00 /opt/mTrac/mTrac --type=zygote --no-sandbox
1002 9050 1 0 11:30 ? 00:00:00 /usr/lib/gvfs/gvfs-gdu-volume-monitor
1002 9054 1 0 11:30 ? 00:00:00 /usr/bin/pulseaudio --start --log-target=syslog
1002 9057 1 0 11:30 ? 00:00:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
1002 9062 1 0 11:30 ? 00:00:00 /usr/lib/gvfs/gvfs-afc-volume-monitor
here you can see :
1003 6078 4953 0 09:03 pts/0 00:00:03 puma 3.6.0 (tcp://localhost:3000) [moviestore]
localhost:3000 have pid: 6078
kill that process by
$sudo kill 6078
then run
$rails s

we can user fuser command
fuser -k 3000/tcp

work around
in /_site run: python -m SimpleHTTPServer 8080

Related

htpdate does not update time

I have two machines, a Rpi4 and Ubuntu PC. The two machines are offgrid and connected to their network. The idea is to sync the RPi4 time with the Ubuntu machine. The NTP aproach failed because port and firewall issues. So I used htpdate instead. I've noticed however that I can not set the correct system time of the Rpi4. Regardless of the command I can not get rid of the offset.
I looked elsewhere on how to sync without success:
synchronising-time-between-two-linux-machines
how-to-sync-raspberry-pi-system-clock
how-to-know-if-htpdate-has-synchronized-system-clock
htpdate.8.en.html
htpdate.php
The problem is I can not get rid of the offset. The output of my sessions are:
pi#CMPL01-003-21:~ $ sudo htpdate -qd 10.42.0.1
burst: 1 try: 1 when: 500000
10.42.0.1 80 14 Feb 2023 13:37:24 GMT (0.003) => 38
burst: 1 try: 2 when: 500000
10.42.0.1 80 14 Feb 2023 13:37:25 GMT (0.006) => 38
#: 1 mean: 38 average: 38.000
Offset 38.000 seconds
poll 1800 s
pi#CMPL01-003-21:~ $ sudo htpdate -xqd 10.42.0.1
burst: 1 try: 1 when: 500000
10.42.0.1 80 14 Feb 2023 13:39:25 GMT (0.003) => 38
burst: 1 try: 2 when: 500000
10.42.0.1 80 14 Feb 2023 13:39:26 GMT (0.003) => 38
#: 1 mean: 38 average: 38.000
Adjusting 38.000 seconds
poll 1800 s
pi#CMPL01-003-21:~ $ sudo htpdate -sd 10.42.0.1
burst: 1 try: 1 when: 500000
10.42.0.1 80 14 Feb 2023 13:40:26 GMT (0.003) => 38
burst: 1 try: 2 when: 500000
10.42.0.1 80 14 Feb 2023 13:40:27 GMT (0.005) => 38
#: 1 mean: 38 average: 38.000
Setting 38.000 seconds
Set: Tue Feb 14 14:40:27 2023
poll 1800 s
Is there a missing hidden htpdate parameter or some rules to apply to a folder maybe to clear the offset?
I upgraded the version of htpdate from 1.2.0 to 1.3.7 and tried again. The result was the same and the offset was still there with the difference that the command output noted the client machine was running the automatic ntp sync service. Afterward I was able to sync correctly with htpdate after disabling the service with sudo timedatectl -set-ntp false. Case closed.

Unable to connect to local redis docker although up and running

Using the following redis.conf
▶ cat redis.conf
bind 0.0.0.0
spinning up a redis container
▶ docker run -d --name redis-test -p 11111:6379 -v /Users/redis.conf:/redis.conf redis redis-server /redis.conf
59eb1612e8c3e2403e18ce889ce1438f6c6a23a7c70bed30b46ff765b7fe7038
logs seem healthy
▶ docker logs -f 59eb1612e8c3e2403e18ce889ce1438f6c6a23a7c70bed30b46ff765b7fe7038
1:C 18 Mar 2021 17:57:13.954 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 18 Mar 2021 17:57:13.954 # Redis version=6.2.1, bits=64, commit=00000000, modified=0, pid=1, just started
1:C 18 Mar 2021 17:57:13.954 # Configuration loaded
1:M 18 Mar 2021 17:57:13.955 * monotonic clock: POSIX clock_gettime
1:M 18 Mar 2021 17:57:13.955 * Running mode=standalone, port=6379.
1:M 18 Mar 2021 17:57:13.955 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1:M 18 Mar 2021 17:57:13.956 # Server initialized
1:M 18 Mar 2021 17:57:13.956 * Ready to accept connections
container seems up
▶ docker ps | grep -i redis
59eb1612e8c3 redis "docker-entrypoint.s…" 3 minutes ago Up 3 minutes 0.0.0.0:11111->6379/tcp redis-test
If all the above are more or less good indications, why am I unable to connect to the container
▶ redis-cli -h localhost -p 11111
Could not connect to Redis at localhost:11111: Connection refused
not connected>
▶ redis-cli -h 127.0.0.1 -p 11111
Could not connect to Redis at 127.0.0.1:11111: Connection refused
not connected>
Working on MacOS Catalina
Find the IP Address of container called redis-test by running this command (I'm in Linux, but I think that should be the same on MacOS, sorry if that's not the same):
docker inspect redis-test | grep -i ipaddress
The result should be something like this:
"IPAddress": "172.21.0.2"
Now try:
redis-cli -h 172.21.0.2 -p 11111

Redmine files upload error

I have a problem with files upload in Redmine. Error is: 500 internal server error.
In logs I have no information ( apache log & production.log ).
What I have tried:
Change rights on /usr/share/redmine/files to 777 ( no result )
Change rights on /usr/share/redmine to 777 ( no result )
Checked owner for /usr/share/redmine ( it is admin )
Checked PassengerDefaultUser ( it is admin )
Result of "ps -ef | grep Passenger | grep -v grep" command:
root 27534 26624 0 17:23 ? 00:00:00 PassengerWatchdog
admin 27537 27534 0 17:23 ? 00:00:01 PassengerHelperAgent
nobody 27543 27534 0 17:23 ? 00:00:00 PassengerLoggingAgent
admin 27588 1 0 17:23 ? 00:00:04 Passenger RackApp: /usr/share/redmine
System: Apache 2.4, Passenger Apache/2.4.10 (Debian) mod_fcgid/2.3.9 Phusion_Passenger/4.0.53, Redmine 2.5.2.stable
I tried all that I can, but have no result. :-(

Apache passenger deploy sinatra

I am using apache and passenger. I have my app in /home/git/app/public
My sites-enbled have a file called app with this content
<VirtualHost *:9292>
#ServerName www.yourhost.com
# !!! Be sure to point DocumentRoot to 'public'!
DocumentRoot /home/git/app/public
<Directory /home/git/app/public>
# This relaxes Apache security settings.
AllowOverride all
# MultiViews must be turned off.
Options -MultiViews
</Directory>
My mods-enabled have:
passenger.load
LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.3-p392/gems/passenger-4.0.21/buildout/apache2/mod_passenger.so
passenger.conf
PassengerRoot /usr/local/rvm/gems/ruby-1.9.3-p392/gems/passenger-4.0.21
PassengerDefaultRuby /usr/local/rvm/rubies/ruby-1.9.3-p392/bin/ruby
This paths were returned from to run:
passenger-install-apache2-module
All paths are working.
$>ruby -v
ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-linux]
$> which ruby
/usr/local/rvm/rubies/ruby-1.9.3-p392/bin/ruby
error.log in apache
http://pastebin.com/u50SQJ4h
Procces running
root 622 0.2 1.7 118432 8600 ? Ss 12:55 0:00 /usr/sbin/apache2 -k start
root 624 0.1 0.4 223496 2064 ? Ssl 12:55 0:00 PassengerWatchdog
root 631 0.0 0.4 503552 2424 ? Sl 12:55 0:00 PassengerHelperAgent
nobody 639 0.0 0.9 235480 4900 ? Sl 12:55 0:00 PassengerLoggingAgent
www-data 655 0.0 1.1 118504 5888 ? S 12:55 0:00 /usr/sbin/apache2 -k start
www-data 657 0.0 1.0 118456 5388 ? S 12:55 0:00 /usr/sbin/apache2 -k start
www-data 659 0.0 1.0 118456 5388 ? S 12:55 0:00 /usr/sbin/apache2 -k start
www-data 660 0.0 1.0 118456 5388 ? S 12:55 0:00 /usr/sbin/apache2 -k start
www-data 661 0.0 1.0 118456 5388 ? S 12:55 0:00 /usr/sbin/apache2 -k start
When I visit IPSERVER:9292, not load. In port 80 are running normally. If I will run my app in :9292 I need to run:
passenger start -p '9292' -e 'production' --daemon
My app has the following struct:
/home/git/app
app.rb
config.ru
public
tmp
$> cat config.ru
require 'rubygems'
require 'sinatra'
set :environment, ENV['RACK_ENV'].to_sym
disable :run, :reload
require 'app.rb'
run Sinatra::Application
$> cat app.rb
get '/hi' do
"Hello World!"
end
But I want my app to start with system. Any idea?

session.save_path incorrect in magento + memcache for session

I am trying to configure Magento to use memcache for session. I have installed memcached and also php5-memcache. I have also added "extension=memcache.so" in memcache.ini.
I have made sure the memcached instance is also running in the localhost port number 11213. However, when I try to login to Magento admin I get an error -
Warning: Unknown: Failed to write session data (memcache). Please verify that the current setting of session.save_path is correct (tcp://127.0.0.1:11213?persistent=0&weight=2&timeout=10&retry_interval=10) in Unknown on line 0
The following is the memcache configuration in local.xml -
<session_save><![CDATA[memcache]]></session_save>
<session_save_path><![CDATA[tcp://127.0.0.1:11213?persistent=0&weight=2&timeout=10&retry_interval=10]]></session_save_path>
The following are the grep for memcached,
www-data 1329 1 0 08:13 ? 00:00:00 /usr/bin/memcached -d -m 64 -p 11213 -u www-data -l 127.0.0.1
www-data 1511 1 0 08:18 ? 00:00:00 /usr/bin/memcached -d -m 64 -p 11211 -u www-data -l 127.0.0.1
www-data 1518 1 0 08:18 ? 00:00:00 /usr/bin/memcached -d -m 64 -p 11212 -u www-data -l 127.0.0.1
I have been meddling up with this for a couple of days now and I am not sure what the issue. Any help is appreciated.
Thanks,
G
Please note there is a difference between memcache and memcached. I’ve found that the Magento sessions integration expects you to use this:
<session_save><![CDATA[memcached]]></session_save>
You should install the PHP memcached libraries, as well.

Resources