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
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.
There is an application on remote machine with Linux OS(Fedora), writing to the log file when certain events occur. Some time ago I changed format of the message being written to the log file. But recently it turned out that for some reason in some seldom cases log files with old format messages appear there. I know for sure that none part of my code can write such strings. Also there is no instance of the old application running. Does anyone have some ideas why it can happen? It's not possible to check which process writes those files because anything like auditctl is not installed there, and neither package manager or yum to get it or install. Application is written in C language.
you can use fuser command to find out all the processes that are using that file
`fuser file.log`
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)...).
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
On Windows I can do CreateProcess(..., CREATE_NEW_CONSOLE, ...) and my child process (which is console app, not GUI) will be launched in a new window. What is the easiest way to emulate this on Mac OS?
open -a Terminal.app $(which program) gets a new terminal running the specified program (assuming you're using bash).
You can use execve() (possible after a fork()) to acheive the same thing in compiled code without knowing any Apple APIs (I imagine there is a proper way to do this...).
Read man open.
Edit: you don't need to specify the path to Terminal.app (the finder can figure that out).
If you have X running, it is even easier: just spawn a new xterm with xterm -e program &.
Read man xterm (which will take longer...).
I'll second Chris about the correct use (or lack thereof) of CLI for ordinary mac programs. In my buisness this is expected but the typical user will be {confused|angry|unhappy}.
The Terminal (Terminal.app, what you're referring to as "the console") is just another user-level application on Mac OS X, not a capability of the operating system. There is no direct way in the various APIs available on Mac OS X to just start an executable within a new Terminal window.
However, I believe you can open an executable with Terminal as if it was a document — whether in code or as a user — and it will run in a new session. However, this is not a normal Mac OS X user experience and should not generally be used in Mac software you're going to deliver to end users.
Mac OS X applications are applications. It's fine to provide tools that advanced users can interact with via Terminal, but Terminal is in no way, shape or form a substitute for a real application when delivering software to end users.
I'll add to this that if you're using Cocoa, you can use the NSTask class to start and interact with another process very easily.
Marc Liyanage does this neatly with "term", osascript tell application "Terminal":
http://www.entropy.ch/blog/Mac+OS+X/2005/02/28/Terminal_tricks_8220_term_8221_and_8220_clone_8221.html
(On "typical users": there are different universes, each finding the others strange.
Coming from Unix, I'm used to a process or "| pipe args" anywhere a file can be used;
this helps software componentry immensely.
But open -a does files only -- different universe).