I have followed instructions from
https://www.digitalocean.com/community/tutorials/how-to-use-ssh-keys-with-digitalocean-droplets
But my terminal looks like
ps auxw | grep ssh
milenko 21891 0.0 0.0 21292 924 pts/4 S+ 16:24 0:00 grep --color=auto ssh
Should I kill 21891?
What does grep --color auto stand for?Can someone elaborate more om this?
grep --color=auto is the grep from the line above. When you would try to kill it later, it will no longer be there, because the above command ended.
The reason why the line does not list only grep ssh is, that you have alias for grep to be nicely colored:
$ which grep
alias grep='grep --color=auto'
/usr/bin/grep
TLDR what is going on there: Your sshd server is not running.
Related
This question already has answers here:
How to get process ID of background process?
(9 answers)
Closed 1 year ago.
Below is the output of executing two commands ads2 svcd& and ps -aux|grep ads2
nvidia#nvidia-desktop:~$ ads2 svcd&
[1] 4593
nvidia#nvidia-desktop:~$ ps -aux|grep ads2
nvidia 4593 0.5 0.0 39796 23864 pts/0 Sl 08:20 0:00 /opt/ads2/arm-
linux64/bin/ads2svcd
nvidia 4603 0.0 0.0 6092 672 pts/0 S+ 08:20 0:00 grep --color=auto ads2
nvidia#nvidia-desktop:~$
nvidia#nvidia-desktop:~$
the command ads2 svcd& runs a process related to ads2 software. with ps -aux|grep ads2 i displayed the whole processes that contains the name "ads2".
Now What i'm trying to do is to get the process number of the ads2 which in this example is 4593. So i wrote the follwing bash script:
#!/usr/bin/env bash
process="$(ps -aux|grep ads | grep 'nvidia' | cut -d' ' -f 3)"
echo "The current ads2 process is " $process
The bash script outputs the following:
nvidia#nvidia-desktop:~$ ./test.sh
The current ads2 process is
As you see the process number is not filtered. So what i'm i doing wrong?
thanks in advance
List all the processes in the current shell with $$ built-in variable
ps --forest -gp $$
PID TTY STAT TIME COMMAND
3809 pts/1 Ss 0:01 bash
4896 pts/1 T 0:00 \_ vim file.json
22965 pts/1 S+ 0:00 \_ ssh dw
3607 pts/0 Ss 0:01 bash
2500 pts/0 R+ 0:00 \_ ps --forest -gp 3607
3327 tty2 Ssl+ 0:00 /usr/lib/gdm3/gdm-x-session --run-script i3
3329 tty2 Sl+ 8:12 \_ /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3
3346 tty2 S+ 0:03 \_ i3
Just see the pid of them:
ps -opid --forest -gp $$
PID
3809
4896
22965
3607
2688
3327
3329
3346
If you need to use grep for any reason, use -opid,cmd with current shell:
ps -opid,cmd -gp $$ | grep vim
3851 grep --color=auto vim
4896 vim file.json
For all, just use -e
ps -e -opid,cmd | grep vim
4141 grep --color=auto vim
4896 vim file.json
The complete one, we have to ignore the grep itself:
ps -e -opid,cmd | grep vim | grep -v grep | cut -d' ' -f 2
4896
Without double grep using comm option for ps
ps -opid,comm -gp $$ | grep vim
4896 vim
of course the simplest one is pgrep
pgrep vim
4896
NOTE for variable assignment there should NOT be any space:
# wrong
ads2ProcessId = $(pgrep ads2)
# right
ads2ProcessId=$(pgrep ads2)
I seem to have a weird issue:
I want to restart a reverse ssh tunnel on boot, I've tried it with an init script (that works fine when executed as user) and with an added line in /etc/rc.d but none of it works. What I get after boot is:
$ ps ax | grep autossh
397 pts/10 S+ 0:00 grep --color=auto autossh
1351 ? Ss 0:00 /usr/lib/autossh/autossh -M 22221 -N -o PubkeyAuthentication=yes -o PasswordAuthentication=no -i ~/.ssh/etherwan.key -R 19999:localhost:22 ubuntu#server
but I'm unable to login from server. So I did the following after boot:
$ sudo killall -KILL autossh
[sudo] password for ron:
$ /usr/bin/autossh -M 22221 -f -N -o "PubkeyAuthentication=yes" -o "PasswordAuthentication=no" -i ~/.ssh/etherwan.key -R 19999:localhost:22 ubuntu#server
upon which I can login using port 19999 just fine!
The keys permissions look like: (but root should not need to care, would it?)
$ ls -l ~/.ssh/etherwan.key
-r-------- 1 ron ron 1675 Nov 6 04:15 /home/ron/.ssh/etherwan.key
Replace ~/.ssh/etherwan.key in your rc.d script with /home/ron/.ssh/etherwan.key
The '~' character is expanded to the user's home directory by the shell, but rc.d scripts are run as root.
I'm a newbie to unix-like. And I met a weird issue that I really cannot find answers by searching.
#!/bin/bash
me=`basename "$0"`
echo $(ps -e | grep "$me" | wc -l)
ps -e | grep "$me" | wc -l
After executing that bash script, the echo shows me 2, and ps just shows me 1 which is what I want. How can this happen? Why echo shows me an extra process?
As Charles Duffy pointed out, $() creates a subshell. That answers my question. Apparently I still have a lot to learn. Thanks for all the help.
As noted by a comment by Cyrus; this script:
me=$(basename $0)
ps -ef |grep $me
when launched with "./ps.sh", prints:
auser#pc:/tmp$ ./ps.sh
auser 4425 4422 0 08:42 pts/3 00:00:00 grep ps.sh
auser#pc:/tmp$
No subshells are involved here, it is the grep(1) itself that is listed by ps(1). The same script, launched with "bash ps.sh" outputs:
auser 4426 3946 0 08:44 pts/3 00:00:00 bash ps.sh
auser 4429 4426 0 08:44 pts/3 00:00:00 grep ps.sh
This is the result the OP gets, even without subshells. Even more explicit:
auser#pc:/tmp$ ps -ef |grep grep
auser 4467 3946 0 08:49 pts/3 00:00:00 grep grep
although you are creating a sub shell by using $() you can grep this out by using grep -v grep.
So:
$(ps -e | grep "$me" | grep -v grep | wc -l)
which will return 1 instead of 2
I am trying to stop kibana on SSH with kill but it respawns immediatly
dagatsoin#dagatsoin.io [~/logstash]# ps aux | grep kibana
533 28778 0.0 0.0 9292 876 pts/2 S+ 00:16 0:00 grep kibana
dagatsoin#dagatsoin.io [~/logstash]# kill -kill 28778
-bash: kill: (28778) - Aucun processus de ce type
dagatsoin#dagatsoin.io [~/logstash]# ps aux | grep kibana
533 28780 0.0 0.0 9292 876 pts/2 S+ 00:16 0:00 grep kibana
dagatsoin#dagatsoin.io [~/logstash]#
How do you kill this process ?
As mentioned the output that you are seeing is from the ps aux | grep kibana command that you ran. I'm guessing you started kibana using by running the kibana scipt in the bin directory. In this case do something like this:
ps -ef | grep '.*node/bin/node.*src/cli'
Look for the line that looks something like this:
username 5989 2989 1 11:33 pts/1 00:00:05 ./../node/bin/node ./../src/cli
Then run a kill -9 5989 If you have multiple output rows make sure you kill the correct process.
You try to kill your grep process, not kibana service who is not running currently.
For me, nothing worked on Ubuntu 18, except this:
systemctl stop snap.kibana.kibana
You kibana process is not running. when you do run a ps aux command and pipe it with a grep command, grep will be running as a separate process. hence its shows up in the ps aux output as process no 28778 or 28780. you can observe that the process number is changing. every-time you stop the ps aux grep process also ends as it is piped with ps and it starts as a new process(id) when you rerun it. hence you are getting an error when you run kill -kill 28778 as it has already stopped.
When you start your Kibana using the start script in $KIBANA_HOME/bin/kibana, this script runs another script in $KIBANA_HOME/node/bin/node. Remember, you must search using ps command for a different name (not Kibana name).
So I use ps awwwx | grep -i ./bin/../node/bin/node | grep -v grep on new Linux versions like Ubuntu 18 (or ps -ef | grep -i ./bin/../node/bin/node | grep -v grep on older versions) to search for the Kibana node. This command will give you the accurate PID and you can kill the Kibana node via mentioned PID.
grep -v grep part of this command is just to omit the unnecessary lines from the output of the command.
When I check list of processes and 'grep' out those that are interesting for me, the grep itself is also included in the results. For example, to list terminals:
$ ps aux | grep terminal
user 2064 0.0 0.6 181452 26460 ? Sl Feb13 5:41 gnome-terminal --working-directory=..
user 2979 0.0 0.0 4192 796 pts/3 S+ 11:07 0:00 grep --color=auto terminal
Normally I use ps aux | grep something | grep -v grep to get rid of the last entry... but it is not elegant :)
Do you have a more elegant hack to solve this issue (apart of wrapping all the command into a separate script, which is also not bad)
The usual technique is this:
ps aux | egrep '[t]erminal'
This will match lines containing terminal, which egrep '[t]erminal' does not! It also works on many flavours of Unix.
Use pgrep. It's more reliable.
This answer builds upon a prior pgrep answer. It also builds upon another answer combining the use of ps with pgrep. Here are some pertinent training examples:
$ pgrep -lf sshd
1902 sshd
$ pgrep -f sshd
1902
$ ps up $(pgrep -f sshd)
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1902 0.0 0.1 82560 3580 ? Ss Oct20 0:00 /usr/sbin/sshd -D
$ ps up $(pgrep -f sshddd)
error: list of process IDs must follow p
[stderr output truncated]
$ ps up $(pgrep -f sshddd) 2>&-
[no output]
The above can be used as a function:
$ psgrep() { ps up $(pgrep -f $#) 2>&-; }
$ psgrep sshd
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1902 0.0 0.1 82560 3580 ? Ss Oct20 0:00 /usr/sbin/sshd -D
Compare with using ps with grep. The useful header row is not printed:
$ ps aux | grep [s]shd
root 1902 0.0 0.1 82560 3580 ? Ss Oct20 0:00 /usr/sbin/sshd -D
You can filter in the ps command, e.g.
ps u -C gnome-terminal
(or search through /proc with find etc.)
One more alternative:
ps -fC terminal
Here the options:
-f does full-format listing. This option can be combined
with many other UNIX-style options to add additional
columns. It also causes the command arguments to be
printed. When used with -L, the NLWP (number of
threads) and LWP (thread ID) columns will be added. See
the c option, the format keyword args, and the format
keyword comm.
-C cmdlist Select by command name.
This selects the processes whose executable name is
given in cmdlist.
Disclaimer: I'm the author of this tool, but...
I'd use px:
~ $ px atom
PID COMMAND USERNAME CPU RAM COMMANDLINE
14321 crashpad_handler walles 0.01s 0% /Users/walles/Downloads/Atom.app/Contents/Frameworks/Electron Framework.framework/Resources/crashpad_handler --database=
16575 crashpad_handler walles 0.01s 0% /Users/walles/Downloads/Atom.app/Contents/Frameworks/Electron Framework.framework/Resources/crashpad_handler --database=
16573 Atom Helper walles 0.5s 0% /Users/walles/Downloads/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --type=gpu-process --cha
16569 Atom walles 2.84s 1% /Users/walles/Downloads/Atom.app/Contents/MacOS/Atom --executed-from=/Users/walles/src/goworkspace/src/github.com/github
16591 Atom Helper walles 7.96s 2% /Users/walles/Downloads/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --type=renderer --no-san
Except for finding processes with a sensible command line interface it also does a lot of other useful things, more details on the project page.
Works on Linux and OS X, easily installed:
curl -Ls https://github.com/walles/px/raw/python/install.sh | bash
Using brackets to surround a character in the search pattern excludes the grep process since it doesn't contain the matching regex.
$ ps ax | grep 'syslogd'
16 ?? Ss 0:09.43 /usr/sbin/syslogd
18108 s001 S+ 0:00.00 grep syslogd
$ ps ax | grep '[s]yslogd'
16 ?? Ss 0:09.43 /usr/sbin/syslogd
$ ps ax | grep '[s]yslogd|grep'
16 ?? Ss 0:09.43 /usr/sbin/syslogd
18144 s001 S+ 0:00.00 grep [s]yslogd|grep
Depending on the ultimate use case, you often want to prefer Awk instead.
ps aux | awk '/[t]erminal/'
This is particularly true when you have something like
ps aux | grep '[t]erminal' | awk '{print $1}' # useless use of grep!
where obviously the regex can be factored into the Awk script trivially:
ps aux | awk '/[t]erminal/ { print $1 }'
But really, don't reinvent this yourself. pgrep and friends have been around for a long time and handle this entire problem space much better than most ad hoc reimplementations.
Another option is to edit your .bash_profile (or other file that you keep bash aliases in) to create a function that greps 'grep' out of the results.
function mygrep {
grep -v grep | grep --color=auto $1
}
alias grep='mygrep'
The grep -v grep has to be first otherwise your --color=auto won't work for some reason.
This works if you're using bash; if you're using a different shell YMMV.