I am using JMeter for load testing and some of my threads just hang. I want to do a thread dump but none of the following work from my linux machine
First get JMeter process id using
jps -l
Then did
sudo -u <username> jstack <pid>
and get the following msg
15141: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
even
kill -3 15141
comes up with nothing
After lot of googling and trial and error found the solution
To take thread dumps, start JMeter using command line.
Open terminal (A)
$ cd /media/9260C06E60C05A9D/Downloads/jakarta-jmeter-2.4/bin
$ ./jmeter > temp
In another terminal (B)
Get the process id of JMeter
$ jps -l
$ kill -QUIT 21735
Now check temp file for thread dump.
In order to use jstack make sure the user and group user are the same as the user running jstack
Related
I have a script which does the following:
Script executes fine in GUI mode:
jmeter -q C:/Users/503289283/Downloads/eml_base.properties -t Service_Names.jmx
When executed in Non-GUI mode i.e.
jmeter -q C:/Users/503289283/Downloads/eml_base.properties -n -t Service_Names.jmx
We receive the below message:
Have added an entry in the log4j2.xml file. Restarted JMeter.
Executed the script again in Non-GUI mode. Still see the same message. Didn't find anything suspicious in the log file.
Not sure where is the issue. Please help.
Regards,
Ajith
Script executes fine in GUI mode:
jmeter -q C:/Users/503289283/Downloads/eml_base.properties -t Service_Names.jmx
it doesn't mean that the "script executes fine", it means that you're just opening Service_Names.jmx test plan in JMeter GUI, the script is being "executed" when you click this button:
Or press CTRL+R
Your test cannot be finished successfully (in fact there are no successful Sample Results) because SSH Command sampler is still waiting for the response from the SSH server.
I don't know what eml status command does and how does the output look like,try running it via new instance of Bash (or whatever is your shell) interpreter as:
/bin/bash -c "eml status"
If the command is interactive, i.e. the output never ends until you press the button, you will need to reconsider your approach.
More information: How to Run External Commands and Programs Locally and Remotely from JMeter
This used to be runnable but recently I'm encounter the following issue.
By running the following command:
node --inspect-brk ./node_modules/.bin/jscodeshift mod.js file.
I am encountering this problem
Debugger listening on ws://127.0.0.1:9229/7e57a2d3-0885-44b3-b51e-b47dc8417d87
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Processing 1 files...
Spawning 1 workers...
Sending 1 files to free worker...
Starting inspector on 127.0.0.1:9229 failed: address already in use
All done.
Results:
0 errors
0 unmodified
0 skipped
0 ok
Time elapsed: 0.035seconds
What worked for me:
Start node-inspector
Install jscodeshift in my local repo as a dev dependency.
put debugger statement in my script
run jscodeshift via node with --debug-brk arg and added --run-in-band jscodeshift param.
For example :-
I entered node
--debug-brk ./node_modules/jscodeshift/bin/jscodeshift.sh -t my-refactor-script.js --run-in-band
If you add a file pattern at the end, it works fine, which in the case of debugging is helpful when you want to test just one trouble file.
I did not test debugging jscodeshift installed via npm -g
The answer that worked for me was installing ndb, https://github.com/GoogleChromeLabs/ndb, and prefixing the command with it.
ndb node --inspect-brk ./node_modules/.bin/jscodeshift mod.js
The reason inspect mode doesn't work is because another process (e.g. another instance of the inspector) is already using the default port (9229), so they're conflicting. Either use a different port for the inspector or kill the process that's currently using the port.
If you use a different port, you'll be able to start the inspector. Just pass the desired port-number (e.g. 39479) to --inspect-brk.
Your example:
node --inspect-brk ./node_modules/.bin/jscodeshift mod.js file.
Could for example be: node --inspect-brk=39479 ./node_modules/.bin/jscodeshift mod.js file.
DANGER: If you need the port 9229, you can kill the process/inspector that's currently using that port, but if you don't know what that process is doing you could damage things: lsof -i TCP:9229 | grep LISTEN | awk '{print $2}' | xargs kill -9
I have a unix script that invokes another script on a remote unix server.
amongst other commands i am stopping a service. The stop command essentially translates to
ssh -t -t -q ${AEM_USER}#${SERVERIP} 'bash -l -c "service aem stop"'
The service is getting stopped but when i start back the service it just creates the .pid file and does not perform the start up. When i run the command for start i.e.
ssh -t -t -q ${AEM_USER}#${SERVERIP} 'bash -l -c "service aem start"'
it does not show any error. On going to the server and checking the status
service aemauthor status
Below message is displayed
aem dead but pid file exists
Also when starting the service by logging in to the server, it works as expected along with the message
Removing stale pidfile (pid: 8701)
Starting aem
We don't know the details of the service script of aem.
I guess the problem is related to the SIGHUP signal. When we log off from a shell or disconnect from ssh, the OS will send HUP signal to all processes that started in this terminated shell. If the process didn't handle the HUP signal, it would exit by default.
When we run a command via ssh remotely, the process started by this command will receive HUP signal after ssh session is terminated.
We can use the nohup command to ignore the HUP signal.
You can try
ssh -t -t -q ${AEM_USER}#${SERVERIP} 'bash -l -c "nohup service aem start"'
If it works, you can use nohup command to start aem in the service script.
As mentioned at the stale pidfile syndrome, there are different reasons for pidfiles getting stalled, like for instance some issues with the way your handles its removal when the process exits... but considering your only experiencing when running remotely, I would guess it might be related to what is being loaded or not by your profile... check the most voted solid answer at the post below for some insights:
Why Does SSH Remote Command Get Fewer Environment Variables
As described in the comments of the mentioned post, you can try sourcing /etc/profile or ~/.bash_profile before executing your script to test it, or even trying to execute env locally and remotelly to compare variables that are being sourced or not.
I was successfully running psexec to open application on remote PC using the following command:
psexec -s -i 1 \\135.20.230.160 -u administrator -p force calc
But suddenly today I found that 'calc' is not opening in the remote machine. Instead it is just running on the process list in task manager.
After some experiments when I changed '-i 1' to '-i 2' I found it working again.
Can anyone explain why this happened and how can I decide that the session number needs to be changed?
I need to build automation script for different users, so this is important to resolve.
Thanks.
You can use tasklist to display all tasks and see what session they are currently running on under the session# section.
The Psexec -i is asking for the session you would like to use.
Therefore as users log in to the machine the session numbers can be anywhere from 0 and up. To find out use tasklist with and check a process you know is running and view its session number.
I am trying to do a profiling on my embedded Linux box. This is running a software.
I want to do a profiling on my software using strace.
The application is the main software that keeps running forever.
How can I run the strace and log the outputs to a file.
In my rcS script.
I run the application like this
./my_app
Now, with strace.
strace ./my_app -> I want to log these outputs on a file, and I should be able to access the file without killing the application. Remember this application never terminates.
Please help!
Instead of a target filename, use the -p option to strace to specify the process ID of an already running process you wish to attach to.
Chris is actually right. Strace takes the -p option, which enables you to attach to a running process just by specifying the processes PID.
Let's say your 'my_app' process runs with PID 2301 (you can see the PID by logging into your device and us 'ps'). Try doing 'strace -p 2301', and you will see all system calls for that PID. You can throw it to a file by redirecting everywhere: 'strace -p 2301 > /tmp/my_app-strace'.
Hope this helps.