I'm using TestCafe to test an app I'm working on. Today, when I went to run a TC test, I got the following message:
Error: listen EADDRINUSE: address already in use :::57664
I can usually handle these pretty easily: I issue the command:
lsof -i -P | grep -i "listen"
or
lsof -i tcp:57664
and then kill the offending task that is identified.
However, in this case, that port number isn't listed so I don't know which task to kill. also,
ps aux | grep -i "TestCafe"
doesn't show anything helpful.
Any suggestions on how to identify the hung task and kill it?
Related
I execute a command to grep a long log file on a remote server and the problem is whenever I ssh first and then execute the grep command remotely I get way more matches than if I do it in one shot as follows:
ssh host 'less file | grep something'
I was suspecting some default automatic timeout with the second version so I experimented with those options -o ServerAliveInterval=<seconds> -o ServerAliveCountMax=<int> but to no avail. Any idea what could be the problem?
The problem was related to less. It does not behave well outside of interactive mode. Using cat solved the issue.
When I am doing SSH to some machine inside the for loop it is doing the ssh but not able to execute further.
Code is like:
string=c01.test.cloud.com,c02.test.cloud.com
for i in $(echo $string | sed "s/,/ /g")
do
ssh -t -t AppAccount#$i
cd a/b/c
str2=x,y,z
done
I take it from your question that you expect cd a/b/c to run on a remote server? That's not what this script is doing. The call to ssh opens an SSH tunnel, and provides you an interactive terminal connection. It then waits for that connection to terminate. (I suspect if you pressed Control-D, the script would continue.) Your use of -t -t here is particularly strange. Why do you want to force a remote pty? This is making the problem worse (not that much, since it won't work anyway, but this seems the opposite of what you'd want).
I think this is the script you meant:
string=c01.test.cloud.com,c02.test.cloud.com
for i in $(echo $string | sed "s/,/ /g")
do
ssh AppAccount#$i 'cd a/b/c; str2=x,y,z'
done
(This won't do anything of course, but I assume your real script has more to it than setting a shell variable and exiting.) The point is that you ned to pass the script you want to run as a parameter to ssh. Otherwise it's going to spawn an interactive shell and wait for you to close it.
Note that if your script is very complicated, it can be very inconvenient to stick it all in a single-quoted string. If your internal script is in its own file, a simple way to handle this is with bash -s which reads a script from stdin:
cat some_script | ssh server 'bash -s'
You can also use bash Here docs to achieve the same thing, but that is likely getting too fancy for this use.
I tryied command from older versions, but it dont seems to work.
curl "http://localhost:5555/selenium-server/driver/?cmd=shutDownSeleniumServer"
'Old' command is not working because it's part of selenium RC which is not included in selenium 3.
You should now start your nodes with -servlet org.openqa.grid.web.servlet.LifecycleServlet included, and than you can shut it down with http://yourNodeIP:port/extra/LifecycleServlet?action=shutdown
I reported this issue few months ago and it's solved so you can check it out for more details here. https://github.com/SeleniumHQ/selenium/issues/2982
If you are on linux you can kill the process running on that port by
fuser -k 5555/tcp
or netstat -plten |grep java you will get the PID of seleniumserver process.
kill -9 PID.
Also try hitting the lifecycle of selenium grid2
http://yourHubIP:port/lifecycle-manager?action=shutdown
CTRL+c from your terminal also would help.
let me know if you are looking for anything else
Assuming you are running it on *nix and the standalone server is listening on the default port (4444)... you need to:
find the PID of the process that is bound to port 4444 (use lsof command)
send that process a SIGTERM to gracefully shutdown (use the kill command)
you can achieve this with the following one-liner:
$ lsof -t -i :4444 | xargs kill
I'm trying to automate some things on remote Linux machines with bash scripting on Linux machine and have a working command (the braces are a relict from cmd concatenations):
(ssh -i /path/to/private_key user#remoteHost 'sh -c "echo 1; echo 2; echo 3; uname -a"')
But if an ampersand is concatenated to execute it in background, it seems to execute, but no output is printed, neither on stdout, nor on stderr, and even a redirection to a file (inside the braces) does not work...:
(ssh -i /path/to/private_key user#remoteHost 'sh -c "echo 1; echo 2; echo 3; uname -a"') &
By the way, I'm running the ssh client dropbear v0.52 in BusyBox v1.17.4 on Linux 2.4.37.10 (TomatoUSB build on a WRT54G).
Is there a way to get the output either? What's the reason for this behaviour?
EDIT:
For convenience, here's the plain ssh help output (on my TomatoUSB):
Dropbear client v0.52
Usage: ssh [options] [user#]host[/port][,[user#]host/port],...] [command]
Options are:
-p <remoteport>
-l <username>
-t Allocate a pty
-T Don't allocate a pty
-N Don't run a remote command
-f Run in background after auth
-y Always accept remote host key if unknown
-s Request a subsystem (use for sftp)
-i <identityfile> (multiple allowed)
-L <listenport:remotehost:remoteport> Local port forwarding
-g Allow remote hosts to connect to forwarded ports
-R <listenport:remotehost:remoteport> Remote port forwarding
-W <receive_window_buffer> (default 12288, larger may be faster, max 1MB)
-K <keepalive> (0 is never, default 0)
-I <idle_timeout> (0 is never, default 0)
-B <endhost:endport> Netcat-alike forwarding
-J <proxy_program> Use program pipe rather than TCP connection
Amendment after 1 day:
The braces do not hurt, with and without its the same result. I wanted to put the ssh authentication to background, so the -f option is not a solution. Interesting side note: if an unexpected option is specified (like -v), the error message WARNING: Ignoring unknown argument '-v' is displayed - even when put in background, so getting output from background processes generally works in my environment.
I tried on x86 Ubuntu regular ssh client: it works. I also tried dbclient on x86 Ubuntu: works, too. So this problem seems to be specific to the TomatoUSB build - or inside the "dropbear v0.52" was an unknown fix between the build in TomatoUSB and the one Ubuntu provides (difference in help output is just the double-sized default receive window buffer on Ubuntu)... how can a process know if it was put in background? Is there a solution to the problem?
I had the similar problem on my OpenWRT router. Dropbear SSH client does not write anything to output if there is no stdin, e.g. when run by cron. I presume that & has the same effect on process stdin (no input).
I found some workaround on author's bugtracker. Try to redirect input from /dev/zero.
Like:
ssh -i yourkey user#remotehost "echo 123" </dev/zero &
It worked for me as I tried to describe at my blog page.
i want to run some command on several machine using ssh. I know it can be done by just using the command "ssh user#hostname command". However, the command i want to run print some string on the console. Is there any way that send all the strings back to the console that i'm on?
You could run the commands in a screen:
screen -S test
ssh user#hostname command1
ssh user#hostname2 command2
You can then detach (Ctrl-D) from the screen, let it run for however long it will run, then re-attach (screen -r test) to the screen and see all of the output. This assumes that you won't have a ton of output from the commands, however. Here's a link to a tutorial on screen.
ssh user#hostname command
Does just that. if 'command' outputs something, it'll show on the terminal you ran ssh from.
Try e.g. ssh user#hostname ls -l
But as others have said, GNU screen is invaluable for this type of work.
You probably want to use Gnu Screen for this. You can start a process in a "virtual" terminal, "detach" the terminal and log out for however long you want... Then you can ssh back in and re-attach the terminal to see the console output.
Also have a look at nohup, for example:
ssh user#domain.com nohup script_that_outputs_strings.py > the_strings.txt
Then if you want to go back and monitor the progress, you could check back and tail the file or scp the output back to your local machine.
Why don't you send you an email back?
Or use a log file, and scp it to your current computer?
otherwise, I don't know!