Why am I getting a "failed to connect to server" message from tmux when I try to list sessions? - linux
Here's what's happening to me: I start tmux sessions using tmux -L name1, tmux -L name2; then I detatch them using ctrl+B+d. Then I try to get a list of the currently running sessions on my computer. However, when I run tmux ls, I get an error message:
failed to connect to server: Connection refused
Is this a bug? I'm familiar with screen; I regard screen -ls as a very useful function since I might start a session and leave it running for weeks before the next time I attach to it. Because of this, the ability to list current running tmux sessions is quite important for me. Why does tmux ls return a "connection refused" error when I know tmux is running?
TL;DR: Try sending SIGUSR1 signal to the tmux server process.
In my case, after about 8 days of inactivity, I was not able to reattach:
$ tmux attach
no sessions
However, a grep for tmux process got me this output:
$ ps -aef | fgrep -i tmux
hari 7139 1 1 2016 ? 2-20:32:31 tmux
hari 25943 25113 0 22:00 pts/0 00:00:00 fgrep --color=auto -i tmux
As suggested by #7heo.tk, this indicates that tmux server is still running, but tmux ls was giving failed to connect to server: Connection refused error. I verified that the tmp directory that belonged to the tmux session existed and lsof -p 7139 (the pid of tmux server) showed that the socket file is open:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tmux 7139 hari 5u unix 0x0000000000000000 0t0 1712879255 /tmp/tmux-50440/default
I also tried explicitly specifying the -S /tmp/tmux-50440/default to tmux but it didn't help. However, I read in the tmux man page that sending SIGUSR1 would make tmux recreate the socket file, so I tried that and I was able to immediately find the session and reattach:
$ kill -s USR1 7139
$ tmux ls
0: 12 windows (created Mon Apr 18 21:17:55 2016) [198x62]
This happens to me when I do not have any sessions running. I'm just starting to use tmux and didn't realize that if you restart your computer you lose your sessions which surprised me at first.
For those of you who are thinking the same thing: Restore tmux session after reboot. A summary of the post: Use shell scripts to build your tmux sessions or create a fancy shell history tracker.
This happened to me when the Ubuntu desktop crashed and my gnome-terminal windows exited. I could still see the tmux process was running (ps aux | grep tmux) but for some reason tmux commands would not work to list the existing sessions. Apparently it wasn't finding the existing Unix socket of the still-running tmux process. The fix in this scenario is to locate the existing Unix socket and specify that to tmux using the -S flag; here's how:
You can find the PID of your still-running tmux process with this:
ps -p $(pidof tmux)
Now take your PID (in my case, 6876) and run this to list any open Unix sockets:
sudo lsof -Uap 6876
Hopefully you see output like this:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tmux 6876 abe 3u unix 0x0000000000000000 0t0 408477 socket
tmux 6876 abe 4u unix 0x0000000000000000 0t0 408478 socket
tmux 6876 abe 6u unix 0x0000000000000000 0t0 408479 /tmp/tmux-1000/default
Now you can specify that existing Unix socket to your tmux command (using the -S flag), and you should be able to list-sessions and attach properly:
tmux -S /tmp/tmux-1000/default list-sessions
tmux -S /tmp/tmux-1000/default attach -t 0
You get this error indeed if there are no session open. If there are no sessions open there is no tmux server running so it can't connect to it.
With the -L option, you change the socket name the tmux server uses, it's not a way to name your sessions. You better use the following commands:
tmux new -s name1
tmux new -s name2
These will create 2 sessions on a server with the default socket name. Now you can do:
$ tmux ls
name1: 1 windows (created Mon Sep 22 10:34:40 2014) [158x40] (attached)
name2: 1 windows (created Mon Sep 22 10:34:43 2014) [158x40] (attached)
And you see all the sessions running on the server on the default socket. You can reattach one of them using:
tmux attach -d -s name1
-s specifies the name of the session
-d will detach it from it's previous client (if it is attached)
You can also switch between sessions inside tmux with the choose-tree command which by default is assigned to the keystroke C-s (prefix key + s). This is what I usually do.
You may have an error in your .tmux.conf. I had this problem until i took out this line from my .tmux.conf:
set-window-option -g xterm-keys on
You could also try tmux -v and then look at the logs it prints.
One easy fix is to delete the tmp files left by the tmux server, for example, by doing $ rm -rf /tmp/tmux-xxx/.
The way TMUX(1) works is by having a client process (tmux) connect to a server process (tmux too, but not attached to a TTY), as shown in the following ps output:
PID TTY STAT TIME COMMAND
19229 pts/1 S+ 0:00 tmux
19231 ? Ss 0:00 tmux
That shows that the client actually starts before the server (one could assume it forks it).
After detach/re-attach, the same ps command outputs:
PID TTY STAT TIME COMMAND
19231 ? Ss 0:00 tmux
19290 pts/1 S+ 0:00 tmux attach
This shows the tmux client as tmux attach, thus being a bit easier to understand.
Now, if we look at the output of pstree in both of the above cases, we get in both cases (ignoring the pid change for tmux attach):
pstree -p
init(1)─┬─acpid(1824)
├─cron(1859)
⋮
├─sh(14146)───tmux(19229)
└─tmux(19231)───sh(19233)───pstree(19234)
Clearly showing that the commands typed (pstree in this case) in the client process (PID 19229) get executed by the server one (PID 19231), thus allowing them to continue without SIGHUP in the event where the client terminal is lost (over ssh, for example).
Now, to the question OP asked: what happens in the case where tmux returns failed to connect to server: Connection refused is that the server process (pid 19231 in our case) is unreachable, whatever the reason (it can be because the server process died; but also because the user executing the tmux client doesn't have the permissions to access the tmux socket, etc.)
The solution in that case is to grep for the tmux processes (via ps for example), and pray that you didn't get this error because the server died (so you can attach to it by using lsof to get what sockets it listens to). Otherwise, there is no way to attach to the server, as it is as dead as after a reboot.
TL;DR:
This error can be given for multiple reasons, ranging from bug to critical failure (program died). In a nutshell, use the UNIX tools at your disposal to determine what socket does tmux use, if it is still running (there should be at least two processes if you have the tmux client running - that happens after invoking tmux or tmux attach from the shell) and thus if you lost your session or not.
Note: as other answers pointed out, if the reason for this error to be shown is a socket error, you can use the -L flag to tell tmux to use a specific socket.
This may happen if you or any cleaning process delete files in /tmp/*. All your sessions data are lost if you can't recover those files. Killing all tmux instances and restart it is the only choice left, unfortunately.
I was using another program inside of tmux (reattach-to-user-namespace), and I was getting this error when I switched computers because reattach-to-user-namespace was not installed. The fix was to simply run brew install reattach-to-user-namespace.
This happened to me because I ran tmux with another user (was root), and I tried to list sessions with my normal user..
So you might want to check the user with which you ran your tmux first.
To do so:
$ ps -aef | fgrep -i tmux
root 7139 1 1 2016 ? 2-20:32:31 tmux
centos 25943 25113 0 22:00 pts/0 00:00:00 fgrep --color=auto -i tmux
See the username in the first column: here it's root
Try tmux -L name1 list-session.
Related
How to terminate an ssh command that was ran from a remote host?
I ran an ssh command doing the following: ssh user#remote "my command &". Now the process seems to be running in the background, but I cannot find it, and I want to end it. I've used netstat, but cannot find the process.
Didn't you expect it to run in the background? Thats what the & does. You can use ps af to show all of the processes running under your username. You can then kill it by PID.
Thanks everybody. I found the process doing ps aux. For some reason, the port that it was using wasn't being display in netstat.
I suggest some methods sudo killall ssh It may not be the best method to use this method, it is better to filter first and then close it or ps -o pid,cmd | grep ssh kill -QUIT (pid) To stop a program, send the QUIT signal.
Nodemon Error: listen EADDRINUSE: address already in use :::3000 [duplicate]
I have a simple server running in node.js using connect:
var server = require('connect').createServer();
//actions...
server.listen(3000);
In my code I have actual handlers, but thats the basic idea. The problem I keep getting is
EADDRINUSE, Address already in use
I receive this error when running my application again after it previously crashed or errors. Since I am not opening a new instance of terminal I close out the process with ctr + z.
I am fairly certain all I have to do is close out the server or connection. I tried calling server.close() in process.on('exit', ...); with no luck.
First, you would want to know which process is using port 3000 sudo lsof -i :3000 this will list all PID listening on this port, once you have the PID you can terminate it with the following: kill -9 <PID> where you replace <PID> by the process ID, or the list of process IDs, the previous command output.
You can also go the command line route: ps aux | grep node to get the process ids. Then: kill -9 PID Doing the -9 on kill sends a SIGKILL (instead of a SIGTERM). SIGTERM has been ignored by node for me sometimes.
I hit this on my laptop running win8. this worked. Run cmd.exe as 'Administrator': C:\Windows\System32>taskkill /F /IM node.exe SUCCESS: The process "node.exe" with PID 11008 has been terminated.
process.on('exit', ..) isn't called if the process crashes or is killed. It is only called when the event loop ends, and since server.close() sort of ends the event loop (it still has to wait for currently running stacks here and there) it makes no sense to put that inside the exit event...
On crash, do process.on('uncaughtException', ..) and on kill do process.on('SIGTERM', ..)
That being said, SIGTERM (default kill signal) lets the app clean up, while SIGKILL (immediate termination) won't let the app do anything.
Check the PID i.e. id of process running on port 3000 with below command : lsof -i tcp:3000 It would output something like following: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME node 5805 xyz 12u IPv6 63135 0t0 TCP *:3000 (LISTEN) Now kill the process using : kill -9 5805
For macOS Monterey(12.0): Apple introduced some changes for AirPlay on macOS Monterey. Now, it uses 5000 and 7000 ports. If you are using these ports in your project, you need to disable this feature. System Preferences > Sharing > untick AirPlay Receiver For macOS Ventura(13.0) and above users: System Settings > General > disable AirPlay Receiver
I found this solution, try it Give permission use sudo sudo pkill node
I usually use npx kill-port 3000 or on my mac. killall node
Rewriting #Gerard 's comment in my answer: Try pkill nodejs or pkill node if on UNIX-like OS. This will kill the process running the node server running on any port. Worked for me.
Linux Run ps and determine the PID of your node process. Then, run sudo kill PID Windows Use tasklist to display the list of running processes: tasklist /O Then, kill the node process like so (using the PID obtained from the tasklist command): taskkill /pid PID
Here is a one liner (replace 3000 with a port or a config variable): kill $(lsof -t -i:3000)
For windows open Task Manager and find node.exe processes. Kill all of them with End Task.
I was getting this error once and took many of the approaches here. My issues was that I had two app.listen(3000); calls in the same app.js script. The first app.listen() succeeded where the second threw the error. Another useful command I came across that helped me debug was sudo fuser -k 3000/tcp which will kill any rogue processes you might have started (some processes may restart, e.g. if run with forever.js, but it was useful for me).
For Visual Studio Noobs like me You may be running the process in other terminals! After closing the terminal in Visual Studio, the terminal just disappears. I manually created a new one thinking that the previous one was destroyed. In reality, every time I was clicking on New Terminal I was actually creating a new one on top of the previous ones. So I located the first terminal and... Voila, I was running the server there.
Windows by Cmd 1/2. search => write cmd => open node.js command prompt 2/2. Run windows command: taskkill Ends one or more tasks or processes. taskkill /f /im node.exe /f - force ended /im - Specifies the image name of the process to be terminated. node.exe - executable file Windows - Mannualy by Task Manager This command is the same as going to Task Manager under the details tab & select node tasks (Tidy in my opinion). And end task Visual studio Sometimes there is more than one terminal/task (client/server and so on). Select and close by ctrl + c.
You may run into scenarios where even killing the thread or process won't actually terminate the app (this happens for me on Linux and Windows every once in a while). Sometimes you might already have an instance running that you didn't close.
As a result of those kinds of circumstances, I prefer to add to my package.json:
"scripts": {
"stop-win": "Taskkill /IM node.exe /F",
"stop-linux": "killall node"
},
I can then call them using:
npm run stop-win
npm run stop-Linux
You can get fancier and make those BIN commands with an argument flag if you want. You can also add those as commands to be executed within a try-catch clause.
FYI, you can kill the process in one command sudo fuser -k 3000/tcp. This can be done for all other ports like 8000, 8080 or 9000 which are commonly used for development.
ps aux | grep node kill -9 [PID] (provided by above command) Description: ps will give the process status, aux provide the list of a: all users processes, u: user own processes, x: all other processes not attached to terminal. pipe symbol: | will pass the result of ps aux to manipulate further. grep will search the string provided(node in our case) from the list provided by ps aux.
First find out what is running using: sudo lsof -nP -i4TCP:3000 | grep LISTEN You will get something like: php-fpm 110 root 6u IPv4 0x110e2ba1cc64b26d 0t0 TCP 127.0.0.1:3000 (LISTEN) php-fpm 274 _www 0u IPv4 0x110e2ba1cc64b26d 0t0 TCP 127.0.0.1:3000 (LISTEN) php-fpm 275 _www 0u IPv4 0x110e2ba1cc64b26d 0t0 TCP 127.0.0.1:3000 (LISTEN) Then you can kill the process as followed: sudo kill 110 Then you will be able to run without getting the listen EADDRINUSE :::3000 errors
Really simply for all OS's ..
npx kill-port 3000
Although your problem is as mentioned above you need to catch the different ways node can exit for example
process.on('uncaughtException', (err, origin) => {
console.log(err);
});
// insert other handlers.
bash$ sudo netstat -ltnp | grep -w ':3000' - tcp6 0 0 :::4000 :::* LISTEN 31157/node bash$ kill 31157
PowerShell users: Taskkill /IM node.exe /F
UI solution For Windows users: I found that the top answers did not work for me, they seemed to be commands for Mac or Linux users. I found a simple solution that didn't require any commands to remember: open Task Manager (ctrl+shift+esc). Look at background processes running. Find anything Node.js and end the task. After I did this the issue went away for me. As stated in other answers it's background processes that are still running because an error was previously encountered and the regular exit/clean up functions didn't get called, so one way to kill them is to find the process in Task Manager and kill it there. If you ran the process from a terminal/powerShell you can usually use ctrl+c to kill it.
Task Manager (ctrl+alt+del) -> Processes tab -> select the "node.exe" process and hit "End Process"
Just in case check if you have added this line multiple times by mistake
app.listen(3000, function() {
console.log('listening on 3000')
});
The above code is for express but just check if you are trying to use the same port twice in your code.
In windows users: open task manager and end task the nodejs.exe file, It works fine.
On Windows, I was getting the following error: EADDRINUSE: address already in use :::8081. Followed these steps: Opened CMD as Admin Ran the folowing command netstat -ano|findstr "PID :8081" got the following processes: killed it via: taskkill /pid 43144 /f On MAC you can do like this: raghavkhunger#MacBook-Air ~ % lsof -i tcp:8081 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME node 23722 username 24u IPv6 0xeed16d7ccfdd347 0t0 TCP *:sunproxyadmin (LISTEN) username#MacBook-Air ~ % kill -9 23722
With due respect to all the answers in the form, I would like to add a point. I found that when I terminate a node app on error using Ctrl + Z, the very next time when I try to open it got the same error EADDRINUSE. When I use Ctrl + C to terminate a node app, the next time I opened it, it did without a hitch. Changing the port number to something other than the one in error solved the issue.
using netstat to get all node processes with the port they are using and then kill the only one you want by PID netstat -lntp | grep node you will get all node processes tcp6 0 0 :::5744 :::* LISTEN 3864/node and then when you get the PID (3864) just kill the processes by PID kill -HUP PID
You may use hot-node to prevent your server from crashing/ run-time-errors. Hot-node automatically restarts the nodejs application for you whenever there is a change in the node program[source] / process[running node program]. Install hot-node using npm using the global option: npm install -g hotnode
listen EADDRINUSE: address already in use :::5000
In my application, I use concurrently to run both backend and front end simultaneously. After ctrl + c, strill the port 5000 is running. Also, port 3000 is running. I have to manually kill processes. How can I solve this?
Run cmd.exe as 'Administrator': C:\Windows\System32>taskkill /F /IM node.exe
run pa -xa | grep node you will get result with processid 4476 pts/0 Sl+ 0:01 node index.js then kill the process with kill -9 4476 as simple as that
lsof -ti finds open files(sockets are files in nix based systems) -t removes the headers, so that we can pipe into kill(We just want the process id), -i lets lsof find the file based off the internet address. We do not have to provide the full address, we can just search by port, by using the pattern :port. Some commands accept input from stdin, and we can pipe directly to them, kill is not one of those commands, so we must use xargs(It reads from stdin, and calls the specified command with the input from stdin). Finally the ; lets us execute both commands irrespective of one another. Regardless of whether lsof -ti:3000 | xargs kill succeeds or fails, lsof -ti:5000 | xargs kill will run, and vice versa. lsof -ti:3000 | xargs kill; lsof -ti:5000 | xargs kill
Restart your laptop/server, it will release all the busy ports, then try again... you can also use ps aux | grep node and then kill the process using: kill -9 PID.. You can kill all the processes that are using node it can also kill a system process Not preferred: killall -9 node but most of the times it wont work for nodemon, and didnt work for me.
You can fix this issue by killing the address in use or may simply restart your device. 1- For Linux to Kill the address in use, use the following command sudo kill $(sudo lsof -t -i:8080) where replace 8080 with your app address.
you can simply restart your laptop or change the port number it should work
Killing Stanford core nlp process
I launch Stanford Core NLP server using the following command (on Ubuntu 16.04): java -mx4g -cp "*" edu.stanford.nlp.pipeline.StanfordCoreNLPServer -port 9000 -timeout 15000 I would like to kill this server once I am done using it. Simply closing terminal does not help. It does not release memory. Is there way to kill it and release memory without rebooting computer?
You can always CTRL-C in the terminal window to stop the server. You could also ps aux | grep StanfordCoreNLPServer to find the pid and then kill the process manually. When the server is started it should create a shutdown key and you can send that message to the server to close the server. This isn't working on my Macbook Pro (maybe a permission issue ??) but I've seen it work on other machines. Here is the command: wget "localhost:9000/shutdown?key=`cat /tmp/corenlp.shutdown`" -O - Note the shutdown key is stored at /tmp/corenlp.shutdown If you use the the -server_id server0 option the shutdown key will be stored at this path /tmp/corenlp.shutdown.server0
If you just want to kill the process. You can use lsof command. #install lsof if missing sudo apt install lsof You can find the pid of CoreNLP using lsof -i:9000 Replace 9000 with the port you used to run the server. The output looks like COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java 15867 XXXX XXX IPv6 XXXXXX 0t0 TCP *:9000 (LISTEN) Use the pid from here and run. kill 15867 PID of my server process is 15867.
How to get a list of programs running with nohup
I am accessing a server running CentOS (linux distribution) with an SSH connection. Since I can't always stay logged in, I use "nohup [command] &" to run my programs. I couldn't find how to get a list of all the programs I started using nohup. "jobs" only works out before I log out. After that, if I log back again, the jobs command shows me nothing, but I can see in my log files that my programs are still running. Is there a way to get a list of all the programs that I started using "nohup" ?
When I started with $ nohup storm dev-zookeper , METHOD1 : using jobs, prayagupd#prayagupd:/home/vmfest# jobs -l [1]+ 11129 Running nohup ~/bin/storm/bin/storm dev-zookeeper & NOTE: jobs shows nohup processes only on the same terminal session where nohup was started. If you close the terminal session or try on new session it won't show the nohup processes. Prefer METHOD2 METHOD2 : using ps command. $ ps xw PID TTY STAT TIME COMMAND 1031 tty1 Ss+ 0:00 /sbin/getty -8 38400 tty1 10582 ? S 0:01 [kworker/0:0] 10826 ? Sl 0:18 java -server -Dstorm.options= -Dstorm.home=/root/bin/storm -Djava.library.path=/usr/local/lib:/opt/local/lib:/usr/lib -Dsto 10853 ? Ss 0:00 sshd: vmfest [priv] TTY column with ? => nohup running programs. Description TTY column = the terminal associated with the process STAT column = state of a process S = interruptible sleep (waiting for an event to complete) l = is multi-threaded (using CLONE_THREAD, like NPTL pthreads do) Reference $ man ps # then search /PROCESS STATE CODES
Instead of nohup, you should use screen. It achieves the same result - your commands are running "detached". However, you can resume screen sessions and get back into their "hidden" terminal and see recent progress inside that terminal. screen has a lot of options. Most often I use these: To start first screen session or to take over of most recent detached one: screen -Rd To detach from current session: Ctrl+ACtrl+D You can also start multiple screens - read the docs.
If you have standart output redirect to "nohup.out" just see who use this file lsof | grep nohup.out
You cannot exactly get a list of commands started with nohup but you can see them along with your other processes by using the command ps x. Commands started with nohup will have a question mark in the TTY column.
You can also just use the top command and your user ID will indicate the jobs running and the their times. $ top (this will show all running jobs) $ top -U [user ID] (This will show jobs that are specific for the user ID)
sudo lsof | grep nohup.out | awk '{print $2}' | sort -u | while read i; do ps -o args= $i; done
returns all processes that use the nohup.out file