Part of my application (preferably a daemon) required to log the list of process names that have got core dumped. It would be great, if someone points which mechanism that I can use?
If the processes are truly dumping core, you could use the following trick:
Set /proc/sys/kernel/core_pattern to |/absolute/path/to/some/program %p %e
This will cause the system to execute your program (with the faulting process' pid and executable name), and pipe the core dump into its standard input. You may then log and store the core dump file.
Note that the program will run as the user and group root
See man 5 core for more information, and an example core dump handling program
Related
i have to realize a program that, among other things, have to kill itself (in response to a received command) and restart after a timeout set before abort; moreover it have to log that the restart is due to this kind of operation. In linux this could be done quite easily using a fork and managing the different pid, but unfortunately i have to realize this program in windows, using plain C. I have read several article, saying that a clone of fork in windows is a real pain. I have tried to understand createProcess but it appears not so indicated in this case. A solution could be realize a second program and passing it the timeout trough createProcess and command line argument but it is a soultion that i wish to avoid if possible.
If you need the fork() semantics, then your options are:
Windows Subsystem on Linux, which already has a fork()
Cygwin, which also has a fork()
Write your own... this is not easy... at all
If you can "cheat", an option would be to create and kill threads instead of processes. For transient data, you can use TLS (Thread Local Storage).
Another cheat would be to create a dump file. Say, save a file with MiniDumpWriteDump before terminating a process, later read it with MiniDumpReadDumpStream when starting a new process. This is also not so easy and it fails if you rebuild your application and use an old dump file. But, at least it's a well known Windows API.
If none of the above works for you, the only remaining option is to use CreateProcess(), which is a spawn(), not a fork(), then add code to support the fork() features that you need.
I'm sure my question has probably been answered previously but I didn't find anything specific to my situation after searching for a while.
Background:
I have written a suite of data acquisition tools in C that run on an embedded system running Debian Wheezy. There is a main module, called Dispatch, whose job is to launch the rest of the modules and pass messages between them. I put a trivial bash script in /etc/init.d that executes Dispatch when the system boots since this system runs unattended. This system runs without any local user interaction so Dispatch should really be written to function as a daemon but it is not. The startup script simply executes /opt/bcdispatch &.
There's a bug in one of the other modules that causes it to crash every few days. I'm trying to hunt down that bug but in the meantime I am trying to write a watchdog program that will detect the crash, kill off all of my processes, then relaunch Dispatch. For reasons I won't go into it is not sufficient to just relaunch the crashed process, the whole suite of tools needs to be restarted.
What I'm trying to do:
I wrote a simple watchdog program that periodically executes popen("ps aux | grep bc") (all of my process names start with "bc" which makes it easy to find them with grep), finds that one of the modules has crashed by looking for anything with a "zombie" status in any of the lines read from popen(), kills all of my processes by calling system("kill <PID>"), then executes the startup script in /etc/init.d and exits. I modified the startup script so that it launches the watchdog after launching Dispatch. The startup script now looks like:
/opt/bcdispatch &
/opt/mywatchdog &
Everything is being run as root. There are no other user accounts on the system.
Problem
The watchdog process works fine if I run it from the command line. It kills off all of the processes it's supposed to, launches the startup script, then exits. However, when the watchdog is launched by the startup script at boot time it doesn't do its thing. It's running, one of the processes it's monitoring has crashed, but it doesn't kill the rest of them off. It just sits there like a giant turd. I can start another instance of it from the command line and that one works just fine.
Question
So my question (finally!) is: why can't my program kill other processes when launched via a startup script? I suspect it has something to do with the fact that the watchdog process no longer has a terminal associated with it? I tried substituting the call to system("kill <PID>") with kill(PID) but that didn't change anything.
EDIT
It just occurred to me that it's not the kill()ing part that doesn't work (well, that might be broken as well), the call to popen("ps aux | grep bc") must not be working since the watchdog should exit after it finds the zombie process but it isn't. Its PID is still the same as it was when the system booted. I guess this means the title of this question isn't very good.
Found the problem. The output of my watchdog's call to popen("ps aux | grep bc") was being truncated to 80 columns, presumably because it was no longer attached to a terminal and that's the default terminal width. That truncation was causing problems for the way the program was parsing the results of the ps command so it never found the crashed process. Changing the command to popen("ps -w aux | grep bc") was all that was needed to fix it.
I have a situation here, a few days back I was able to see a core- dump file on my target board, I have enabled the core-dump generation by adding "ulimit -c unlimited" to my /etc/profile.
But then someone told me, this will only take affect for program launched from a login shell, not for processes/services started by systemd, etc. and the ulimits are set at another location.
So I changed /etc/limits file and added ulimit -c unlimited line, but still I could not see core-dump file.
I am running kill -9 $$ to generate segmentation fault and it in turn will generate core-dump file as it was doing earlier.
We tried changing "/proc/sys/kernel/core_pattern" file and running ulimit -c unlimited explicitly but this was not enough.
Where we are going wrong?
kill -9 will not generate a core file. The command kill -l gives a list of supported signals. kill -6 or kill -SIGABRT should produce a core file. As well as most other signals such as kill -BUS, kill -SEGV, etc.
kill -11 always works for me. 11 is SIGSEGV (invalid memory reference)
You have to first off enable user limits settings to ensure that core files can be created.
ulimit -c unlimited
Application user must run as and before you start the application in the same session. This setting is inherited by the application, so what ever the ulimit is set as before starting the application is what the ulimit setting will be for the application (unless a start script changes it).
In addition of the other answers, you might also use gcore(1) to generate a core dump of some running process.
But if using kill(1) command (or the underlying kill(2) syscall, e.g. from some ad-hoc program), I recommend using SIGABRT (the signal that abort(3) send to itself after unblocking it), as documented in the signal(7).
Beware, a program can usually forbid core dumping, e.g. by calling setrlimit(2) with RLIMIT_CORE set to 0 or handling or ignoring some signals (with e.g. sigaction(2)...).
I have been playing around lately with memory dumping and stumbled upon something that I didn't fully understand.
If I have a process and dump its memory contents by using VirtualQueryEx & ReadProcessMemory to grab the data and dump it to a file everything is ok. Meanwhile, I have tried doing the same thing by being internal to the process and doing VirtualQuery and just dumping the contents of the pointers it returns.
I was able to do this by proxying one of the DLLs of the process I am testing on.
Now, the problem is that these two memory dumps are different ( missing areas from the dump created from inside the process )
Could somebody enlighten me as to why this is happening ?
Windows XP SP3 + Visual Studio 2008
Thank you very much.
What do you need to dump? Speaking about all the memory pages that are allocated by the process then I think that you can get different values because of the internal process state that is (in general) unique per time. Also, if you are dumping process's memory outside the process then the dumper's code is not in the dumping process address space while if you are dumping process from inside the process, the process now includes the dumper's code. So, it may be useful to dump only certain number of pages belongs to process application or DLL's.
My fedora12 installed a tool called ABRT that comes probably with GNOME. This
tool operates at the background and reports at realtime any process that has crashed.
I have used a signal handler that was able to catch a SIGSEGV signal, ie it could report
crashed.
What other ways exist in order a process to get information about the state (especially a core) of an other process without having parent-child connection?
Any ideas? It seems a very interesting issue.
ABRT is open source, after all, so why not look at their code. The architecture is explained here -- it looks like they monitor $COREDUMPDIR to detect when a new core file appears.
Your question is not entirely clear, but it is possible to get a core of a running process using gcore:
gcore(1) GNU Tools gcore(1)
NAME
gcore - Generate a core file for a running process
SYNOPSIS
gcore [-o filename] pid
DESCRIPTION
gcore generates a core file for the process specified by its process
ID, pid. By default, the core file is written to core.pid, in the cur‐
rent directory.
-o filename
write core file to filename instead of core.pid