Linux test program running

Linux command to check if a shell script is running or not

What is the linux command to find if a process say aa.sh is running or not. ps command does not seem to work and it does not show the shell script names. Please advise.

9 Answers 9

This can give you some surprises, let me give you two examples at the same time. First: it will find «aaa.sh» as well, which can cause errors. Second: grep will find itself, which you have to deal with. Pgrep is the elegant solution.

The simplest and efficient solution is :

if pgrep -fl aa.sh &>/dev/null; then do. fi 

@tutuDajuju: Helpful, thanks; slight tangent: it’s worth drawing more explicit attention to the service you link to: explainshell.com can parse arbitrary Unix command lines and explain the specific options used, based on Ubuntu man pages. Here’s the explicit URL explaining this answer: explainshell.com/explain?cmd=pgrep+-fl+aa.sh

If you’re scripting, you can then follow this with if [ $? = 0 ] to determine if the process was found (pgrep returns 0) or not (pgrep returns 1).

Adding to the answers above —

To use in a script, use the following :-

result=`ps aux | grep -i "myscript.sh" | grep -v "grep" | wc -l` if [ $result -ge 1 ] then echo "script is running" else echo "script is not running" fi 

If i run ps aux | grep -i «myscript.sh» | grep -v «grep» | wc -l alone, output is 0. If I run it in my script, result is 2 and script exits. Any suggestions whats wrong?

one is for the script and one is for the grep itself. if you try ps aux | grep hello in a terminal, you will see the grep as a process. To prevent grep showing itself I use a trick: ps aux | grep [h]ello

ps -ef | grep shellscripname.sh 

You can also find your running process in

The solutions above are great for interactive use, where you can eyeball the result and weed out false positives that way.

False positives can occur if the executable itself happens to match, or any arguments that are not script names match — the likelihood is greater with scripts that have no filename extensions.

Here’s a more robust solution for scripting, using a shell function:

# List instance(s) of script "aa.sh" that are running. getscript "aa.sh" # -> (e.g.): 96112 bash /Users/jdoe/aa.sh # Use in a test: if getscript "aa.sh" >/dev/null; then echo RUNNING fi 

• Matching is case-sensitive (on macOS, you could add -i to the pgrep call to make it case-insensitive; on Linux, that is not an option.)
• The getscript function also works with full or partial paths that include the filename component; partial paths must not start with / and each component specified must be complete. The «fuller» the path specified, the lower the risk of false positives. Caveat: path matching will only work if the script was invoked with a path — this is generally true for scripts in the $PATH that are invoked directly.
• Even this function cannot rule out all false positives, as paths can have embedded spaces, yet neither ps nor pgrep reflect the original quoting applied to the command line. All the function guarantees is that any match is not the first token (which is the interpreter), and that it occurs as a separate word, optionally preceded by a path.
• Another approach to minimizing the risk of false positives could be to match the executable name (i.e., interpreter, such as bash ) as well — assuming it is known; e.g.

# List instance(s) of a running *bash* script. getbashscript() < pgrep -lf "(^|/)bash( | .*/)$1( |\$)" >

If you’re willing to make further assumptions — such as script-interpreter paths never containing embedded spaces — the regexes could be made more restrictive and thus further reduce the risk of false positives.

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

License

linux-test-project/ltp

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Currently the log size for bpf_prog01 + bpf_prog02 is set to BUFSIZ which is defined by the libc in stdio.h. In glibc, this is set to the constant 8192. In other libc’s this may be different, e.g. in Musl this is set to 1024. For bpf_prog02, a log size of 1024 is not large enough to store the verifier log resulting in the following test breakage: [. ] bpf_common.c:123: TBROK: Failed verification: ENOSPC (28) This error is returned from kernel/bpf/verifier.c when the verifier log exceeds the user supplied buffer. Align bpf_prog01 + bpf_prog02 with other bpf tests and set the buffer size explicitly to 8192 in bpf_common.h. Since all tests use this value, use a common definition instead of redefining it in each test. Signed-off-by: Zachary Leaf Reviewed-by: Cyril Hrubis

Git stats

Files

Failed to load latest commit information.

Источник