I have written a script, which checks for process, if its running or not. If not then it starts the process.
Lets say I have few processes running like this :
root 5780 0.0 2.2 3168184 85828 ? Sl 09:02 0:15 /usr/bin/java -jar /home/vtermina/private/crons/jar/consumer-1.0.jar promotionalSecond
root 5780 0.0 2.2 3168184 85828 ? Sl 09:02 0:15 /usr/bin/java -jar /home/vtermina/private/crons/jar/consumer-1.0.jar promotionalSecond backup
root 8989 0.0 1.4 2966364 57540 ? Sl 09:04 0:07 /usr/bin/java -jar /home/vtermina/private/crons/jar/update-report-1.0.jar Rb1 backup
So I use following command to check if a process is runnig or not :
ps uax|grep -w "consumer-1.0.jar promotionalSecond" |grep -v grep|wc -l
This command returns me one, if it finds a process running.
It was working fine till recently, when I started using some backup consumers also.
Now if a backup consumer is running,this command returns 1,even if consumer is not running,
How can I grep for exact words in ps aux.
So that my command gives correct result.
Doing some research , I got the answer. Using "$" in search-term, does,what is required. $ tells that the search term ends there.
Like, if I want to check only promotionalSecond and not backup, following command works perfectly.
ps uax|grep -w "consumer-1.0.jar promotionalSecond$" |grep -v grep|wc -l
Related
I have installed grakn on unix and earlier it was working fine but now giving issues as it is not able to start.
I tried to run it using below command:
./grakn server start
Getting below error.
Starting Storage-FAILED!
Unable to start Storage
Please run 'grakn server status' or check the logs located under 'logs' directory.
There may be lot of things happening under the hood. Without looking into logs this is hard to tell what exactly happening. You can try killing all the processes and then remove associate pids from /tmp/ directory. Then retry starting grakn server.
$ for KILLPID in `ps ax | grep 'grakn' | awk '{print $1}'`; do kill -9 $KILLPID; done
$ ps -ef | grep defunct | grep -v grep | cut -b8-20 | xargs kill -9
$ rm -rf /tmp/grakn-*
Let me know if it helps.
I'm leveraging Zabbix with a custom low-level-discovery that discovers a REST/API endpoint using Python. When the polling is on, the CPU utilization goes through the roof. All the CPU usage is caused by setroubleshootd as show in top:
top - 13:51:56 up 15:33, 1 user, load average: 1.52, 1.43, 1.37
Tasks: 127 total, 3 running, 124 sleeping, 0 stopped, 0 zombie
%Cpu(s): 35.8 us, 6.7 sy, 0.0 ni, 57.3 id, 0.1 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 8010508 total, 6211020 free, 397104 used, 1402384 buff/cache
KiB Swap: 1679356 total, 1679356 free, 0 used. 6852016 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7986 setroub+ 20 0 424072 130856 11548 R 77.4 1.6 7:12.16
Zabbix calls the agent and requests to execute a "UserParameter" which is shorthand for a script. That script is a bash file that calls my python script. and the call looks like this:
#!/usr/bin/env bash
/usr/bin/python /etc/zabbix/externalscripts/discovery.py $1 $2 $3 $4 $5
When zabbix calls the script, it passes the unique filters, like a server ID or network card ID, as one of the arguments. The python script opens up an https session using requests, leveraging a bearer token if the token file exists. If the token file doesn't exist it creates it.
The script works fine and does everything it is supposed to but setroubleshoot is rebooting a slew of issues, specifically around file folder access. The huge number of setroubleshootd responses is causing the CPU to go nuts. Here is an example of the error:
python: SELinux is preventing /usr/bin/python2.7 from create access on the file 7WMXFl.
The file name is random and changes with every execution. I've tried adding an exception using the selinux tools such as:
ausearch -c 'python' --raw | audit2allow -M my-python
But since the file name is random, the errors persist. I've tried uninstalling setroubleshootd, selinux just reinstalls it. Unfortunately, I need to run enforcing mode, so dropping to permissive or disabling are not options.
I've tried changing so that I'm not running a bash script, that zabbix calls the python script directly, or declaring shebang /usr/bin/python, but passing arguments doesn't seem to work properly. I get an error stating the $1 $2... are unknown arguments.
At a loss at this point. It is running, but I'd really like to get the CPU usage down as 60% of 4 cores is unreasonable for 30-40 HTTPS calls.
I ended up writing an SEModule for this that allows the zabbix user write access to the /tmp folder where these files are being created and managed. CPU usage dropped from 75% to 2%. #NailedIt
$>sudo ausearch -m avc | grep zabbix | grep denied | audit2allow -m zabbixallow > my_script.te
$>checkmodule -M -m -o zabbixallow.mod my_script.te
$>semodule_package -o zabbixallow.pp -m zabbixallow.mod
$>sudo semodule -i zabbixallow.pp
Hopefully this helps someone else if they run across this issue.
External scripts will have to complete within your timeout value, this sounds like it's too big for that. You could convert it to zabbix_sender and schedule it via cron. Then it's just a script with performance problems.
I am running jar using nohup command
nohup java -jar Test.jar
I can't find PID of the jar I am running. I try with:
ps ax | grep java
but it is not listing, then I tried with
ps -ef | grep nohup
and I got this output
root 8503 7529 0 21:52 pts/0 00:00:00 grep nohup
which of the PIDs is PID of nohup process? The first one 8503 is always diffrent, while the second one is the same.
Maybe the program test.jar is finished. See output in nohup.out. To avoid to display grep as a process, use the following pattern:
ps -aux | grep 'j[a]va'
or
ps -aux | grep java | grep -v grep
The following command in your terminal may help you out to run the script using nohup and redirect the output in your desired file.
General Syntax
nohup some_command &> nohup_log_file.out &
Example
nohup python script.py &> nohup_log_script.out &
On Oracle Solaris 11 console when ps -ef | grep java command is issued I can see running some java process PID, which was started on other console window and then it (console window) was closed (.jar application output then was visible). Is it some way to grab again that application output without restarting .jar file?
Application was started like this (as a root user):
java -jar SomeFile.jar &
Write output to file is not an option in this case.
Yes, you can do that, but it involves some mad skills with gdb. Here is how to do that in Linux and I believe you can do the same in Solaris (since it has gdb and it has all needed system calls I'm gonna use further).
There are 3 file descriptors for standard streams:
stdin: 0
stdout: 1
stderr: 2
You are interested in stdout and stderr (both are console output), so you need file descriptors with numbers 1 and 2, just keep it in mind.
Now I'm gonna show you how to do what you ask for "okular" application (instead of your "java" application) for stderr stream.
Run "okular" in terminal, like this:
$ okular &
and then close this terminal. This is just to simulate your situation.
Open another terminal
Look for "okular" process:
$ ps aux | grep okular
Output:
joe 27599 2.2 0.9 515644 73944 ? S 23:46 0:00 okular
So "okular" PID is 27599.
Look for open file descriptors of "okular" process:
$ ls -l /proc/27599/fd
Output:
lrwx------ 1 joe joe 64 Feb 18 23:46 0 -> /dev/pts/0 (deleted)
lrwx------ 1 joe joe 64 Feb 18 23:46 1 -> /dev/pts/0 (deleted)
lrwx------ 1 joe joe 64 Feb 18 23:46 2 -> /dev/pts/0 (deleted)
You see that all 3 streams are deleted.
Now let's attach to our process with gdb:
$ gdb -p 27599 /usr/bin/okular
Inside of gdb perform next operations:
(gdb) p close(2)
(gdb) p creat("/tmp/okular_2", 0600)
(gdb) detach
(gdb) quit
Here we invoked 2 system calls:
close(), to close file for stderr stream of our process
creat(), to create new file for stderr stream of our process
p is gdb command, it prints (in our case) system calls return values.
Now all new stderr output of our process will be appended to text file /tmp/okular_2. We can read it constantly this way:
$ tail -f /tmp/okular_2
Conclusion
Ok, that's it, we revived stderr stream. You can do the same for stdout stream, the only difference is that you need to call "close(1)" instead of "close(2)" in gdb. Also, in your case be sure to replace all "okular" words with your "java" word.
The most of answer was inspired by this article.
If you need to revive stdin stream, you can attach it to pipe (FIFO) file, see details here.
Yes, it is possible to snoop any process output with Solaris native tools.
One way would be using dtrace which allows tracing processes even when they are already grabbed by a debugger or similar tool.
This dtrace script will display a given process stdout:
#!/bin/ksh
pid=$1
dtrace -qn "syscall::write:entry /pid == $pid && arg0 == 1 /
{ printf(\"%s\",copyinstr(arg1)); }"
You should should pass the process id of the java application to trace as its first argument, eg. $(pgrep -f "java -jar SomeFile.jar").
Replace arg0 == 1 by arg0 == 2 if you want to trace stderr vs stdin.
Should you want to see non displayable characters (in octal), you might use this slightly modified version:
#!/bin/ksh
pid=$1
dtrace -qn "syscall::write:entry /pid == $pid && arg0 == 1 /
{ printf(\"%s\",copyinstr(arg1)); }" | od -c
Another native way is to use the truss command. The following script will show all writes from your process to any file descriptors, and will include a full detailed trace for both stdout and stderr (3799 is your target process pid):
truss -w1,2 -t write -p 3799
dtrace:
http://docs.oracle.com/cd/E18752_01/html/819-5488/gcgkk.html
truss:
http://docs.oracle.com/cd/E36784_01/html/E36870/truss-1.html#scrolltoc
I know that I can run tmux -V to find the version of tmux that is in my PATH, but how can I get the version of tmux that is currently running?
As pointed out in a comment, tmux -V returns the version:
$ tmux -V
tmux 3.0a
Tested on Centos 7 and OSX 12.5.
Most obvious, but not 100% correct way is to execute this command in console
$ tmux -V
and receive output like this tmux 2.9a with version of tmux INSTALLED, not currently running.
In 99% cases it is enough, but there can be subtle nuances.
Command tmux -V will return version of tmux installed at /usr/bin/tmux or any other directory inside your PATH variable. If you have tmux already running, it is possible that tmux can be started from binary of other version and from different place (for example, tmux can be started from /home/user/bin/tmux).
In this case, you have to call
$ ps -e | grep tmux
to see PID of all tmux processes currently running. It will output something like this
[vodolaz095#ivory ~]$ ps -e | grep tmux
19699 pts/0 00:00:00 tmux: client
19701 ? 00:00:00 tmux: server
Here, number 19701 depicts process id (PID) of currently running tmux server.
After getting PID of tmux server, you can ran command
$ lsof -p 19701
to get information about CURRENTLY RUNNING tmux server process (in my case its 19701) that will output something like this (Figure 1)
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tmux:\x20 19701 vodolaz095 cwd DIR 8,33 4096 22544385 /home/vodolaz095
tmux:\x20 19701 vodolaz095 rtd DIR 8,1 4096 2 /
tmux:\x20 19701 vodolaz095 txt REG 8,1 677760 3675332 /usr/bin/tmux
tmux:\x20 19701 vodolaz095 mem REG 8,1 6406312 131327 /var/lib/sss/mc/group
as you can see, tmux currently running was executed from binary placed in /usr/bin/tmux.
Or, you can call one liner
lsof -p `pgrep 'tmux: server'`
to achieve the same output as Figure 1
After you get path to tmux binary CURRENTLY RUNNING, (in my case, it was /usr/bin/tmux), you can execute this binary with flag -V to get its version
/usr/bin/tmux -V
or, if tmux was installed by limited user into /home/user/bin/tmux,
/home/user/bin/tmux -V
And, as result, you'll get version of tmux currently running, not the one, that was installed.
To get the version of the tmux server you can use display-message.
./tmux2.3 display-message -p "#{version}"
Will show the version of the server (2.7 in my case)
-p will direct the output of stdout so you can script with it and {version} can be anything from the FORMATS section in the man page.
The following will give you the executable of your tmux server, on linux:
realpath /proc/$(tmux display-message -p "#{pid}")/exe
And on macos, proc_pidpath can be used, see https://stackoverflow.com/a/8149380
To find the actual version of the tmux that is running, you have to find the PID of the tmux:
pgrep tmux
With this info, you can check the version by running:
lsof -p $tmuxPID | grep REG | grep -i -e deleted -e "tmux$"
If there is not a (deleted) next to the tmux file listed, you can just run that file with a -V.
If it results in files that are "(deleted)", you are running an old, uninstalled version. If you are on linux, you can figure out what it is by running:
/proc/$tmuxPID/exe -V`
If you are on OS X, you are stuck with whatever information is in the path to the filename, possibly something like Cellar/tmux/<version number>/bin/tmux.
You can combine many of these steps into the following one-liner:
for tmuxPID in $(pgrep tmux); do lsof -p $tmuxPID | grep REG | grep -i -e deleted -e "tmux$"; done
Or if you are on Linux, this always works:
for tmuxPID in $(pgrep tmux); do /proc/$tmuxPID/exe -V; done