The problem is that I cannot find the process ID of a script that has been executed using source. I am able to do so when they are launched with bash using ps -ef.
If I run a script using bash, I can figure the process ID using ps -ef | grep "test1.sh" | grep -v "grep". However, if I run the script using source, I cannot search for it and hence cannot find the process ID.
I have read the difference between the bash and source commands from this link.
This is my testing procedure:
I have 2 terminals. In one of them, I am searching for process IDs using ps -ef. In the other one, I run a script which prints 'Hello' every one second (an infinite while loop with sleep of 1 second). With bash, PID is searchable, but with source, grep doesn't get any results.
I am working on an Ubuntu 18.04.2 LTS machine
If you do not want to terminate the sourcing bash and are satisfied with the script being stopped only after a command (such as sleep) finishes, you can kill -INT the bash process.
Related
I have a centos server in which I have install perl package to run some perl scripts. today I run some perl scripts, and when I run ps -ef | grep perl it shows nothing although the scripts are working properly.
When I use pkill -f (name_of_script) the perl process stopped however they are not shown at all.
Note that yesterday I deleted a user ( X ) which was affected to folder /home/scripts. What do you think the problem is from?
The reason for not showing the process in ps -ef might be due to the process being run as a background process. In that case, the process won't be associated with the terminal where you started it from and thus won't be shown in the output of ps -ef. To see all processes running on the system, including background processes, you can use ps aux instead.
I have seafile (http://www.seafile.com/en/home/) running on my NAS and I set up a cron tab that runs a script every few minutes to check if the seafile server is up, and if not, it will start it
The script looks like this:
#!/bin/bash
# exit if process is running
if ps aux | grep "[s]eafile" > /dev/null
then exit
else
# restart process
/home/simon/seafile/seafile-server-latest/seafile.sh start
/home/simon/seafile/seafile-server-latest/seahub.sh start-fastcgi
fi
running /home/simon/seafile/seafile-server-latest/seafile.sh start and /home/simon/seafile/seafile-server-latest/seahub.sh start-fastcgi individually/manually works without a problem, but when I try to manually run this script file, neither of those lines execute and seafile/seahub do not start
Is there an error in my script that is preventing execution of those 2 lines? I've made sure to chmod the script file to 755
The problem is likely that when you pipe commands into one another, you don't guarentee that the second command doesn't start before the first (it can start, but not do anything while it waits for input). For example:
oj#ironhide:~$ ps -ef | grep foo
oj 8227 8207 0 13:54 pts/1 00:00:00 grep foo
There is no process containing the word "foo" running on my machine, but the grep that I'm piping ps to appears in the process list that ps produces.
You could try using pgrep instead, which is pretty much designed for this sort of thing:
if pgrep "[s]eafile"
Or you could add another pipe to filter out results that include grep:
ps aux | grep "[s]eafile" | grep -v grep
If the name of this script matches the regex [s]eafile it will trivially always take the exit branch.
You should probably be using pidof in preference of reinventing the yak shed anyway.
turns out the script itself was working ok, although the change to using pgrep is much nicer. the problem was actually in the crontab (didn't include the sh in the command)
I am very new to shell scripting, can anyone help to solve a simple problem: I have written a simple shell script that does:
1. Stops few servers.
2. Kills all the process by user1
3. Starts few servers .
This script runs on the remote host. so I need to ssh to the machine copy my script and then run it. Also Command I have used for killing all the process is:
ps -efww | grep "user1"| grep -v "sshd"| awk '{print $2}' | xargs kill
Problem1: since user1 is used for ssh and running the script.It kills the process that is running the script and never goes to start the server.can anyone help me to modify the above command.
Problem2: how can I automate the process of sshing into the machine and running the script.
I have tried expect script but do I need to have a separate script for sshing and performing these tasksor can I do it in one script itself.
any help is welcomed.
Basically the answer is already in your script.
Just exclude your script from found processes like this
grep -v <your script name>
Regarding running the script automatically after you ssh, have a look here, it can be done by a special ssh configuration
Just create a simple script like:
#!/bin/bash
ssh user1#remotehost '
someservers stop
# kill processes here
someservers start
'
In order to avoid killing itself while stopping all user's processes try to add | grep -v bash after grep -v "sshd"
This is a problem with some nuance, and not straightforward to solve in shell.
The best approach
My suggestion, for easier system administration, would be to redesign. Run the killing logic as root, for example, so you may safely TERMinate any luser process without worrying about sawing off the branch you are sitting on. If your concern is runaway processes, run them under a timeout. Etc.
A good enough approach
Your ssh login shell session will have its own pseudo-tty, and all of its descendants will likely share that. So, figure out that tty name and skip anything with that tty:
TTY=$(tty | sed 's!^/dev/!!') # TTY := pts/3 e.g.
ps -eo tty=,user=,pid=,cmd= | grep luser | grep -v -e ^$TTY -e sshd | awk ...
Almost good enough approaches
The problem with "almost good enough" solutions like simply excluding the current script and sshd via ps -eo user=,pid=,cmd= | grep -v -e sshd -e fancy_script | awk ...) is that they rely heavily on the accident of invocation. ps auxf probably reveals that you have a login shell in between your script and your sshd (probably -bash) — you could put in special logic to skip that, too, but that's hardly robust if your script's invocation changes in the future.
What about question no. 2? (How can I automate sshing...?)
Good question. Off-topic. Try superuser.com.
I have a bash script running on Ubuntu.
Is it possible to see the line/command executed now without script restart.
The issue is that script sometimes never exits. This is really hard to reproduce (now I caught it), so I can't just stop the script and start the debugging.
Any help would be really appreciated
P.S. Script logic is hard to understand, so I can't to figure out why it's frozen by power of thoughts.
Try to find the process id (pid) of the shell, you may use ps -ef | grep <script_name>
Let's set this pid in the shell variable $PID.
Find all the child processes of this $PID by:
ps --ppid $PID
You might find one or more (if for example it's stuck in a pipelined series of commands). Repeat this command couple of times. If it doesn't change this means the script is stuck in certain command. In this case, you may attach trace command to the running child process:
sudo strace -p $PID
This will show you what is being executed, either indefinite loop (like reading from a pipe) or waiting on some event that never happens.
In case you find ps --ppid $PID changes, this indicates that your script is advancing but it's stuck somewhere, e.g. local loop in the script. From the changing commands, it can give you a hint where in the script it's looping.
I have a script that runs from a newly created shell.
OS is Red Hat Enterprise Linux Server release 5.4 (Tikanga).
In certain point when the script detects that some application (started by the script) is hanging the script tries to terminate all the procesess it started. I assumed that the correct command for terminating all processes started by current user in current shell is:
pkill /?
The problem is that it kills sshd that is started in parent shell (by init.d) and the putty console disconnects showing error message.
I wonder:
How is it possible for specific user in specific shell to terminate process started by other user in parent shell?
What would be correct command to terminate all processes started by the script currently running?
I have found some solution where i store all the PIDs and when the script needs to terminate them I run in the loop the following:
[ws#RHDev ~]# pkill $(ps aux | grep $pid | awk '{print $2}')
However, I am looking for one-liner that simply terminates all the processes started by the current script.
You can filter subprocesses by the current process pid. The ps command can do this using the --ppid parameter.
ps opid --ppid=7051 | tail -n +2 | xargs kill
here tail -n +2 is to strip the ps headers.
I assumed that the correct command for terminating all processes started by current user in current shell is:
pkill /?
This command matches every single process in the system because it effectively requires only 0 symbols from process name to match. pgrep -l /? demonstrates that.
How is it possible for specific user in specific shell to terminate process started by other user in parent shell?
From man kill(2):
For a process to have permission to send a signal it must either be
privileged (under Linux: have the CAP_KILL capability), or the real or
effective user ID of the sending process must equal the real or saved
set-user-ID of the target process. In the case of SIGCONT it suffices
when the sending and receiving processes belong to the same session.
Do you invoke pkill from user root?
What would be correct command to terminate all processes started by the script currently running?
When bash starts it creates its own process group. Child processes it creates are put in the same process group. Hence:
kill -- -$$
Kills all processes started by the current script. Provided that those processes didn't become group leaders.