Red Hat Enterprise Linux Server release 5.4 (Tikanga)
2.6.18-164.el5
I am trying to use the watch command combined with the netstat to see the 2 programs using certain ports.
However, with the command I using below doesn't work for both words:
watch -n1 "netstat -upnlt | grep gateway\|MultiMedia"
Is this the correct way to grep for both program names.
If I use one its ok, but both together doesn't work.
For the grep you need:
"grep gateway\|MultiMedia"
So perhaps try:
watch -n1 'netstat -upnlt | grep "gateway\|MultiMedia"'
There's also the new way of doing things... grep -E is nice and portable (Or egrep, which is simply quick for grep -E on linux&bsd) so you don't have to escape the quote. From the man pages:
-E Interpret pattern as an extended regular expression (i.e. force
grep to behave as egrep).
So...
watch "netstat -upnlt | grep -E 'gateway|multimedia'"
or
watch "netstat -upnlt | egrep 'gateway|multimedia'"
I had a similar problem monitoring an ssh connection.
> netstat -tulpan|grep ssh
tcp 0 0 192.168.2.52:58072 192.168.2.1:22 ESTABLISHED 31447/ssh
However watch -n 1 'netstat -tulpan|grep ssh' shows no output (apart from message from watch).
If I change it to watch -n 1 'netstat -tulpan|grep ":22"' I get the required output line. It seems as if the -p option is ignored when netstat is run through watch. Strange.
Related
I have "file.txt" with the following and I need to get only ip addresses that start a line.
I am using gnu utilities for windows and grep seems to be not behaving incorrectly.
Random Text Here
ABC 10.0.0.0 - 10.20.0.255
IP Ping Hostname
100.5.0.20 11ms N/S
GNU grep 2.5.4
grep -Po ^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} file.txt
10.0.0.0
10.20.0.255
100.5.0.20
Correct behavior should only allow 100.5.0.20 since i specified the start line anchor.
Any other Linux command solutions?
I ended up improvising,
grep -oP "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]{1,3} " file.txt| awk "{$1=$1};1" > file.txt
This will grab the ip addresses with 2 spaces, and then remove the spaces with awk.
I have a server which is running an apache hive service on port 9083. The thing is it doesn't support http protocol (but uses thrift protocol).so I can't simply add
HEALTHCHECK CMD http://127.0.0.1:9083 || exit 1 # this check fails
All I want is to check if that port is open. I have netstat and curl on server but not nc.
So far I tried the below options, but none of them is suitable as a health check.
netstat -an | grep 9083 | grep LISTEN | echo $? # This works
netstat -an | grep 9084 | grep LISTEN | echo $? # but so does this
The problem as I interpret from the above is it's simply telling me my syntax is correct, but not really testing if that port is really listening
because when I do netstat -an I get the following output,which clearly shows only 9083 is listening but not 9084
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0
0.0.0.0:9083 0.0.0.0:* LISTEN tcp 0 0
Though answering an old question, for future googlers, the following worked for me:
HEALTHCHECK CMD netstat -an | grep 9083 > /dev/null; if [ 0 != $? ]; then exit 1; fi;
The shorter version of it:
netstat -ltn | grep -c 9083
Used options:
netstat:
-l - display listening server sockets
-t - display TCP sockets only
-n - don't resolve names
grep
-c - returns a number of founded lines, but it also gives a useful exit code; 0 if found, 1 if not found
You can use /dev/tcp
Like this :
printf "GET / HTTP/1.1\n\n" > /dev/tcp/127.0.0.1/9083
For more information, you can check this : http://www.tldp.org/LDP/abs/html/devref1.html#DEVTCP
Piotr Perzynas answer is quite good, but it will also return 0 if there‘s a port like 19083 because it finds the substring 9083 in that line.
a better check would be:
netstat -ltn | grep -c ":9083"
I really loved Wassim Dhif answer. Mostly because it does not depend on netstat.
Netstat was obsolete before the question was asked.
From netstat's manpage:
Note
This program is obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr.
And you need netstat (or ss) installed in the container. You only want to check if a port is open. Wassim Dhif's answer just needs bash (and yes, not every image has it). In my experience, you usually want the image as light as possible.
In my compose I used it as follows:
healthcheck:
test: "bash -c 'printf \"GET / HTTP/1.1\n\n\" > /dev/tcp/127.0.0.1/8080; exit $?;'"
interval: 30s
timeout: 10s
retries: 3
start_period: 30s
Note that the string test is equivalent to specifying CMD-SHELL followed by that string (from the Compose Specification
I am trying to output the following tcpdump grep expression to a file :
tcpdump -vvvs 1024 -l -A tcp port 80 | grep -E 'X-Forwarded-For:' --line-buffered | awk '{print $2}
I understand it is related to the line-buffered option, that sends the output to stdin. However, if I don't use --line-buffered I don't get any output at all from my tcpdump.
How can I use grep so that it will send my output directly to stdout / file in this case ?
I am trying to output the following tcpdump grep expression to a file
Then redirect the output of the last command in the pipeline to the file:
tcpdump -vvvs 1024 -l -A tcp port 80 | grep -E 'X-Forwarded-For:' --line-buffered | awk '{print $2}' >file
I understand it is related to the line-buffered option, that sends the output to stdin.
No, that's not with --line-buffered does:
$ man grep
...
--line-buffered
Force output to be line buffered. By default, output is line
buffered when standard output is a terminal and block buffered
otherwise.
so it doesn't change where the output goes, it just changes when the data is actually written to the output descriptor if it's not a terminal. It's not a terminal in this case - it's a pipe - so, by default, it's block buffered, so if grep writes 4 lines of output, and that's less than a full buffer block (buffer blocks, in this context, are typically 4K bytes in most modern UN*Xes and on Windows, so it's likely that those 4 lines won't fill the buffer), those lines will not immediately be written by grep to the pipe, so they won't show up immediately.
--line-buffered changes that behavior, so that each line is written to the pipe as it's generated, and awk sees it sooner.
You're using -l with tcpdump, which has the same effect, at least on UN*X:
$ man tcpdump
...
-l Make stdout line buffered. Useful if you want to see the data
while capturing it. E.g.,
tcpdump -l | tee dat
or
tcpdump -l > dat & tail -f dat
Note that on Windows,``line buffered'' means ``unbuffered'', so
that WinDump will write each character individually if -l is
specified.
-U is similar to -l in its behavior, but it will cause output to
be ``packet-buffered'', so that the output is written to stdout
at the end of each packet rather than at the end of each line;
this is buffered on all platforms, including Windows.
So the pipeline, as you've written it, will cause grep to see each line that tcpdump prints as soon as tcpdump prints it, and cause awk to see each of those lines that contains "X-Forwarded-For:" as soon as grep sees it and matches it.
However, if I don't use --line-buffered I don't get any output at all from my tcpdump.
You'll see it eventually, as long as grep produces a buffer's worth of output; however, that could take a very long time. --line-buffered causes grep to write out each line as it's produced, so it shows up as soon as grep produces it, rather than the buffer is full.
How can I use grep so that it will send my output directly to stdout / file in this case ?
grep is sending its (standard) output to awk, which is presumably what you want; you're extracting the second field from grep's output and printing only that.
So you don't want grep to send its (standard) output directly to the terminal or to a file, you want it to send its output to awk and have awk send its (standard) output there. If you want the output to be printed on your terminal, your command is doing the right thing; if you want it sent to a file, redirect the standard output of awk to that file.
I use iperf3 version and then I get the performance result like this in terminal :
[ 4] local 10.0.1.8 port 34355 connected to 10.0.1.1 port 5201
49,49,0,0,35500
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 2.19 MBytes 18.4 Mbits/sec 0 69.3 KBytes
CPU Utilization: local/sender 2.8% (0.7%u/3.3%s), remote/receiver 1.4% (0.6%u/0.9%s)
I want to use only certain values which I will use in the bash script later. What I want is like this :
35500,18.4,2.8
As far as I know I can use grep to print bandwidth only :
./src/iperf3 -c 10.0.1.1 -d -t 1 -V | grep -Po '[0-9.]*(?= Mbits/sec)'
but is it possible to obtain "35500,18.4,2.8" using grep and how to do it?
Thank you for the answers
grep with P(Perl-regex) option allows you to include multiple regexes,
$ grep -Po '(?<=,)[0-9]+$|[0-9.]*(?= Mbits/sec)|(?<=local\/sender )[^%]*' file | paste -d, - - -
35500,18.4,2.8
So your command would be,
$ ./src/iperf3 -c 10.0.1.1 -d -t 1 -V | grep -Po '(?<=,)[0-9]+$|[0-9.]*(?= Mbits/sec)|(?<=local\/sender )[^%]*' | paste -d, - - -
The title pretty much sums it up. I have a zotonic site running with -heart, it uses lots of cpu time and I can't get an erlang shell. So, is there a way to kill the vm? killall heart and killall beam.smp are not working.
I found this question:
Stop Erlang Daemon
, but it does not really answer my question.
Just use:
init:stop().
It will kill the heart process and all applications.
I had this same issue....
And it was really hard to kill it.
I tried the normal paths and couldn't do it.
So I did this hack:
First let's get the PID
sudo netstat -tulpn |grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 931/beam.smp
So the PID is 931.
Next which program created that process?
lsof -p 931 | grep txt
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/agarcia/.gvfs
Output information may be incomplete.
beam.smp 931 yaws txt REG 8,1 2053256 22793377 /usr/lib/erlang/erts-5.8.5/bin/beam.smp
So the program is .../bin/beam.smp
so just move it
mv beam.smp old_beam.smp
And now you kill it
kill -9 931
And I finally was able to kill it :-)
It's a testament to erlangs reliability that one actually needs to hack-it in order to be able to take down the service.
ps: I originally tried yaws -I [pid] --stop but it didn't work either.
If you don't mind killing every VM on your machine:
ps aux | grep -e heart -e epmd | grep -v grep | tr -s ' ' | cut -d ' ' -f 2 | xargs kill -9
The VM and heart seem to monitor each other mutually. In case the VM is in a crash/revive loop, you may need to run this command several times quickly to kill everything dead.