Is there any way to check whether Neo4J is running using pidof command? I tried doing
pidof /path/to/neo4j/bin/neo4j
But it didn't seem to work.
I need it to set up a script that I will then launch with cron to make sure that if the database crashes I can restart it again.
Thank you!
bin/neo4j status is the command you are looking for.
For a more general use, checking whether neo4dj is running or not, use the following command:
service neo4j-service status
In Ubuntu 16 04 I can execute the following:
sudo service neo4j status
That won't work since neo4j is being run by java command.
Here's a workaround if you want to do something by yourself:
if test -z "$(ps -A | grep neo4j)"
then
echo "no neo4j instance running"
else
echo "neo4j up and running"
fi
But since, as you may probably know, noe4j launcher already does something like that, we may just look at how it's done there:
detectrunning() {
if [ $DIST_OS = "solaris" ] ; then
## SmartOS has a different lsof command line arguments
newpid=$(lsof -o $NEO4J_SERVER_PORT | grep '::' | head -n1 | cut -d ' ' -f 1)
else
## This could be achieved with filtering using -sTCP:LISTEN but this option is not available
## on lsof v4.78 which is the one bundled with some distros. So we have to do this grep below
newpid=$(lsof -i :$NEO4J_SERVER_PORT -F T -Ts | grep -i "TST=LISTEN" -B1 | head -n1)
newpid=${newpid:1}
fi
}
This is an excerpt from the bin/neo4j script inside neo4j distribution directory.
You can use these following ways to get neo4j service status in Windows:
Powershell:
Get-Service neo4j
CMD/Powershell:
service neo4j
Related
I am trying to get the service status (for a /bin/sh script) and start it if is not running.
I found some scripts, but does not work for centos 7.
There are, as usual, multiples ways to do this. Just one example, that check if postfix is running:
#!/bin/sh
PID=`cat /var/spool/postfix/pid/master.pid`
# echo $PID
PS=`/bin/ps axu | grep $PID | grep -v grep`
# echo $PS
if [ "$PS" = "" ]
then
/sbin/service postfix restart
fi
You could use "pid" file, or try to detect if process is running (parsing output of "ps axu |grep process_name"), or parse output of "service process status" command, etc, etc.
How to get all process ids (pid) (similar to: $ ps aux) but without using ps.
One example of when this would be used is when developing a dotnet 5 application to run on a docker host. The dotnet runtime image is a very cut-down Linux image, with bash, but without ps. When diagnosing an issue with the application, it's sometimes useful to see what processes are running and if separate processes have been spawned correctly. ps is unavailable on this image. Is there an alternative?
On Linux, all running process have "metadata" stored in the /proc filesystem.
All running process ids:
shopt -s extglob # assuming bash
(cd /proc && echo +([0-9]))
Further to the comment by #FelixJongleur42, the command
ls -l /proc/*/exe
yields a parseable output with additional info such as the process user, start time and command.
This one-liner will give you the pid and the cmd with args:
for prc in /proc/*/cmdline; { (printf "$prc "; cat -A "$prc") | sed 's/\^#/ /g;s|/proc/||;s|/cmdline||'; echo; }
Based on Ivan's example with some filtering:
for prc in /proc/*/cmdline; {
(printf "$prc "; cat -A "$prc") | sed 's/\^#/ /g;s|/proc/||;s|/cmdline||' | grep java ; echo -n;
}
I am trying to create a Bash .sh script for a cronjob that starts the OpenSSH server if it is down or failed.
Last night the SSH server was down and when I tried to access it today (from work) the connection was refused ofc.
No traces in the /var/log/messages for the failure.
So the question is - how to determine is sshd running so if it is not to "sudo service ssh start" it?
Thanks in advance!
Fellas, I believe that I have managed to do the task:
#!/bin/bash
service="ssh"
if (( ! $(sudo service ssh status | cut -d" " -f 3 | cut -d"." -f 1) == "running" ))
then
sudo /etc/init.d/ssh restart
fi
I have changed the LogLevel to Verbose, I hope the next time I will track more clues regarding the failure of the sshd.
I'm implementing the following:
[ $(sudo service ssh status | grep running | grep -v grep | wc -l) == 0 ] && sudo /etc/init.d/ssh restart
as other people said It's Incorrect to start it without finding what caused this problem, but I wrote some help for the script you want
first you should check the status of your openssh server for example:
ps -aux | grep ssh
then write an if to check if it is down or not
you can check it with the result of previous step.
if that was down, start it
sudo service ssh start
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.
Check this
ps aux | grep "aa.sh"
The simplest and efficient solution is :
pgrep -fl aa.sh
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
Check this
ps -ef | grep shellscripname.sh
You can also find your running process in
ps -ef
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:
getscript() {
pgrep -lf ".[ /]$1( |\$)"
}
Example use:
# 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.
pgrep -f aa.sh
To do something with the id, you pipe it. Here I kill all its child tasks.
pgrep aa.sh | xargs pgrep -P ${} | xargs kill
If you want to execute a command if the process is running do this
pgrep aa.sh && echo Running
I was quite inspired by the last answer by mklement0 - I have few scripts/small programs I run at every reboot via /etc/crontab. I built on his answer and built a login script, which shows if my programs are still running.
I execute this scripts.sh via .profile -file on every login, to get instant notification on each login.
cat scripts.sh
#!/bin/bash
getscript() {
pgrep -lf ".[ /]$1( |\$)"
}
script1=keepalive.sh
script2=logger_v3.py
# test if script 1 is running
if getscript "$script1" >/dev/null; then
echo "$script1" is RUNNING
else
echo "$script1" is NOT running
fi
# test if script 2 is running:
if getscript "$script2" >/dev/null; then
echo "$script2" is RUNNING
else
echo "$script2" is NOT running
fi
here a quick script to test if a shell script is running
#!/bin/sh
scripToTest="your_script_here.sh"
scriptExist=$(pgrep -f "$scripToTest")
[ -z "$scriptExist" ] && echo "$scripToTest : not running" || echo "$scripToTest : runnning"
Give an option to ps to display all the processes, an example is:
ps -A | grep "myshellscript.sh"
Check http://www.cyberciti.biz/faq/show-all-running-processes-in-linux/ for more info
And as Basile Starynkevitch mentioned in the comment pgrep is another solution.
I have a script that I mean to be run from cron that ensures that a daemon that I wrote is working. The contents of the script file are similar to the following:
daemon_pid=`ps -A | grep -c fsdaemon`
echo "daemon_pid: " $daemon_pid
if [ $daemon_pid -eq 0 ]; then
echo "restarting fsdaemon"
/etc/init.d/fsdaemon start
fi
When I execute this script from the command prompt, the line that echoes the value of $daemon_pid is reporting a value of 2. This value is two regardless of whether my daemon is running or not. If, however, I execute the command with back quotes and then examine the $daemon_pid variable, the value of $daemon_pid is now one. I have also tried single stepping through the script using bashdb and, when I examine the variables using that tool, they are what they should be.
My question therefore is: why is there a difference in the behaviour between when the script is executed by the shell versus when the commands in the script are executed manually? I'm sure that there is something very fundamental that I am missing.
You're very likely encountering the grep as part of the 'answer' from ps.
To help fully understand what is happening, turn off the -c option, to see what data is being returned from just ps -A | grep fsdameon.
To solve the issue, some systems have a p(rocess)grep (pgrep). That will work, OR
ps -A | grep -v grep | grep -c fsdaemon
Is a common idiom you will see, but at the expense of another process.
The cleanest solution is,
ps -A | grep -c '[f]sdaemon'
The regular expression syntax should work with all greps, on all systems.
I hope this helps.
The problem is that grep itself shows up... Try running this command with anything after grep -c:
eple:~ erik$ ps -a | grep -c asdfladsf
1
eple:~ erik$ ps -a | grep -c gooblygoolbygookeydookey
1
eple:~ erik$
What does ps -a | grep fsdaemon return? Just look at the processes actually listed... :)
Since this is Linux, why not try the pgrep? This saves you a pipe, and you don't end up with grep reporting back the daemon script itself running.
Aany process with arguments including that name will add to the count - grep, and your script.
psing for a process isn't really reliable, you should use a lock file.
As several people have pointed out already, your process count is inflated because ps | grep detects (1) the script itself and (2) the subprocess created by the backquotes, which inherits the name of the main script. So an easy solution is to change the name of the script to something that doesn't include the name you're looking for. But you can do better.
The "best-practice" solution that I would suggest is to use the facilities provided by your operating system. It's not uncommon for an init script to create a PID file as part of the process of starting your daemon; in other words, instead of just running the daemon itself, you use a wrapper script that starts the daemon and then writes the process ID to a file somewhere. If start-stop-daemon exists on your system (and I think it's fairly common these days), you can use that like so:
start-stop-daemon --start --quiet --background \
--make-pidfile --pidfile /var/run/fsdaemon.pid -- /usr/bin/fsdaemon
(obviously replace the path /usr/bin/fsdaemon as appropriate) to start it, and then
start-stop-daemon --stop --quiet --pidfile /var/run/fsdaemon.pid
to stop it. start-stop-daemon has other options that might be useful to you, which you can investigate by reading the man page.
If you don't have access to start-stop-daemon, you can write a wrapper script to do basically the same thing, something like this to start:
echo "$$" > /var/run/fsdaemon.pid
exec /usr/bin/fsdaemon
and this to stop:
kill $(< /var/run/fsdaemon/pid)
rm /var/run/fsdaemon.pid
(this is pretty crude, of course, but it should normally work).
Anyway, once you have the setup to generate a PID file, whether by using start-stop-daemon or not, you can update your check script to this:
daemon_pid=`ps --no-headers --pid $(< /var/run/fsdaemon.pid) | wc -l`
if [ $daemon_pid -eq 0 ]; then
echo "restarting fsdaemon"
/etc/init.d/fsdaemon restart
fi
(one would think there would be a concise command to check whether a given PID is running, but I don't know it).
If you don't want to (or can't) create a PID file, I would at least suggest pgrep instead of ps | grep, since pgrep will search directly for a process by name and won't find anything that just happens to include the same string.
daemon_pid=`pgrep -x -c fsdaemon`
if [ $daemon_pid -eq 0 ]; then
echo "restarting fsdaemon"
/etc/init.d/fsdaemon restart
fi
The -x means "match exactly", and -c works as with grep.
By the way, it seems a bit misleading to name your variable daemon_pid when it is actually a count.