Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
No idea what you're trying to troubleshoot exactly but if you're not suspecting trouble with systemd itself, why not configure the process for debug / verbose mode, start the process with 'strace' (see 'man strace') from the command line redirecting output to text files, then kill it and then look at its log file and strace logs?
I have a rouge java process running wild, http://javaeesupportpatterns.blogspo...-high-cpu.html, I have tested on my other servers which run WAS kill -3 and I had no process dumps, I have also tested other applications for kill -3, hoping to get an idea of what the output should look like so I can debug it as explained in the article.
I will eventually kill the process, but I was after a process dump for output, I could install jstack and other tools but, things get "political" so I am trying to use the current tools on the troublesome system.
It would be nice to use kill -3, for it but looks like the application does not respond to it..., would be good but nobody can replicate the issue hence why I am leaving this thing running until I can guarantee i get decent output. The application has been running since January and nobody noticed it and the logs have been rotated long ago.
I have looked inside the pid / child pid for more information but cmdline output cannot be decoded into which webcontainer id hence I was looking into the article pasted.
In the meantime I thought I would give kill -3 a try as I have never used it or seen it work.
It seems you think kill -3 will produce a core. But actually kill itself does not do that, it only sends the signal to the process. The core probably will be created, by the kernel, and not the kill command itself. You are not able to specify the location of the core file by that redirection.
That's why I asked you to explain what do you really expect. Is that a core file?
If you are expecting to get a core dump of the process, that is NOT the way to do it.
First the process must be running with ulimits that permit a dump to be created (see man page on ulimit, normally core dumps are disabled).
Second, when the signal is given to the process, a core dump will be written... if and only if the working directory is writable by the process. I believe the usual name is Core.<pid> (uppercase C, but it has been a while).
For a Java program, a core dump is not that useful - the information in it is more related to the JVM, and tracing out what the application was doing in the first place gets tricky. Normally such debugging would be done through an IDE such as Eclipse. Of course, if you are debugging the JVM I suspect otherwise, but am now out of my depth.
Based on the link you posted this is a special feature of jvm (to produce a thread dump on kill -3). It was also mentioned dump is put into a logfile or in a separate file. That is defined by the jvm, and you cannot specify the output using the kill command.
You can try strace -f strace.log <your java app>, execute kill -3 and check that log. You will need to find to location of the dump in that strace.log