I need to dump the each and every process stack in linux kernel when the system hangs.
I am currently trying to implement in one of my kernel module based on the watchdog timer timeout.
Watchdog timer is reset by a user daemon for every timeslice.
When the system hangs, there's no one up to reset the timer.
Hence it expires and generates an interrupt.
I wrote an interrupt handler where I should dump the stack of every process running.
So, my question is how can I dump stack of every process in kernel?
Thanks
Venkatesh
show_state() (include/linux/sched.h) will do this for you. BTW, this function is already available from the sysrq handler, which you might be able to make use of if it's enabled. See Documentation/sysrq.txt
Also, there are some other kernel debugging options you might be able to enable to help find your problem. Check out the Kernel Hacking menu in make menuconfig. In particular, CONFIG_LOCKUP_DETECTOR ("Detect Hard and Soft Lockups" in the menu) might be helpful.
Related
I learned that when an interrupt occurs, the process goes to the ready queue rather than going through the Blocked Queue. However, in this picture, the interrupted process has moved to the blocked queue(which is a circle with pink color). I'm confused that which case goes to the ready queue and which goes to the blocking queue.
Process management in general is much more complex than this. A task is often tied to one specific processor core. Several tasks are tied to the same processor core and each of these tasks can be blocked waiting for IO. It means that any task can be interrupted at any time by an interrupt triggered by a device controller even if the task currently running on the core had nothing to do with that specific interrupt.
The diagram is thus incomplete. It doesn't take in account the complete process lifecycle. In your diagram, the process goes on the blocked queue if it is waiting for IO (after a syscall like read()). It goes to the ready queue if it was preempted by the kernel for another process to have some time on that core.
I think people often have the misconception that each process will run all the time until completion. It cannot be that way otherwise most processes would never get time on any core. Instead, if the amount of processes is higher than the amount of cores, the kernel uses the per core local APIC's timer (local APIC is on x86-64 but you will have similar mechanisms on every architecture) to give every process tied to that core a time slice. When a certain process is scheduled for a certain core, the kernel starts the timer with its time slice. When the time slice has elapsed, the local APIC triggers an interrupt letting the kernel know that another process should be scheduled on that core. This is why a process can be preempted in the middle of its execution. The process is still considered to be ready to run. It is simply that its time slice was exhausted so the kernel decides to give some time to another process. The preempted process will be given some more timer later. Since, in human terms, the time slice of each process is very short, it gives the impression that each process is running consistently without interruption when it is not really the case. (By the way this diagram is very Linux kernel specific)
Is there a way to listen or wait for a specific time (e.g. 11:30 am) every day. The only way I know how is to set a timer that checks for the current time every 60 seconds which I have actually implemented using a backgroundworker. But is there a way to just wait and listen for the specified time (similar to monitoring for directory changes) and then take some action?
Thanks in advance.
Typically, rather than having a program resident in memory waiting, you would setup a Scheduled Task for this (or a cron job on linux). The scheduled task will run the program at the appropriate time. The program can still check (validate) the expected time if needed, but it shouldn't just always sit in the background using up resources if it's only going to run once per day.
The scheduled task is also better because it will recover automatically from computer reboots, crashes, etc. If something happens that interrupts your program's normal running, the scheduled task will still be able to run.
This is especially important in the .Net world, because .Net requires you to be very careful writing long-lived programs to avoid address space fragmentation. The .Net garbage collector is good at freeing up and returning old memory to the operating system, but over time your program's virtual address space can become fragmented and eventually you will not be able to allocate new memory any longer.
Even if this is part of a larger program, where there are also other things happening based on user interactions, it's still a good idea to split this off into a separate process.
Review Question
Consider the Program
#include <stdio.h>
int main(){
putchar('X');
exit(0);
}
Suppose it is compiled an an a.out file is generated. now suppose that a user in a local console window types a.out and hits the return key. what happens? be sure to describe a plausible but detailed and comprehensive sequence of operating system actions and events, not just what the user sees.
My answer
First, the shell will create a process in User Space
Then it will perform the system call 'putchar' Which simulates input, and the process will switch to kernel mode
It will then add the process (thread) to the long term scheduler where it will join the set of all processes that are ready to run
Once it is selected, it will move to the short term scheduler, where it will receive some processing time (ready -> running)
Since this process is an IO bound process, it will then head to the IO queue, where it will be stored in a buffer where it awaits execution (running -> waiting)
Once the IO is complete, the putchar call will print the X on the peripheral for which it is applied (the monitor) (waiting -> running)
Once the process returns to the short term scheduler it will again receive more processing time. Since there is nothing left to do but terminate, the process terminates (running -> terminated)
Is this valid understanding? Am I missing some critical concepts for process creation? I know it is relatively simple process, but please advise anything I am missing.
Thanks for reading, and thanks in advance for assistance.
First, the shell will create a process in User Space
// A lot of things happen before this!!
//The program will be loaded by the loaded.
//VM areas will be created for this process.
//Linking for library files will be done.
//Then a series of pagefault will occur will happen to bring your file on physical and virtual memory
Then it will perform the system call 'putchar' Which simulates input, and the process will switch to kernel mode
//putchar in not at all a system call!!!!
//putchar will call its library implementation, which will further call a write() system call and your program will get trapped inside the kernel
It will then add the process (thread) to the long term scheduler where it will join the set of all processes that are ready to run
//Totally depends upon the scheduling algorithms.. might be possible your process will be first to run!!
Once it is selected, it will move to the short term scheduler, where it will receive some processing time (ready -> running)
//Right, waiting on RunQ
Since this process is an IO bound process, it will then head to the IO queue, where it will be stored in a buffer where it awaits execution (running -> waiting)
//Sort of, it will be waiting on I/O queue, waiting for an interrupt, to write on o/p device
Once the IO is complete, the putchar call will print the X on the peripheral for which it is applied (the monitor) (waiting -> running)
//Correct
Once the process returns to the short term scheduler it will again receive more processing time. Since there is nothing left to do but terminate, the process terminates (running -> terminated)
//Before this it will again get trapped inside the kernel when your program will execute RETURN statement.
//It will call the back the startup function which was responsible for calling the main() function.
//Then startup() function will return 0 to operating system, and hence OS will kill this process and moce it to terminated state..
I still don't think its a complete version as 100's of machine instruction will be executed for this program and its difficult to pin point each and everyone..
But, still if you have some doubt post your comment!!]
Hope this will help!!!
When using NSThread's detachNewThreadSelector:toTarget:withObject:, I'm finding that the thread will fully complete its execution before the application is terminated normally if the user were to attempt to quit the application while the background process was executing.
In this case, this is the behavior I desire, but I couldn't find anything in Apple's docs that suggests that this will always be the case. The only relevant information I was able to find was the following, from Apple's Threading Programming Guide:
Important: At application exit time, detached threads can be terminated immediately but joinable threads cannot. Each joinable thread must be joined before the process is allowed to exit. Joinable threads may therefore be preferable in cases where the thread is doing critical work that should not be interrupted, such as saving data to disk.
So from this, I know that detached threads can be terminated at the time of application exit, but will they ever be terminated automatically? Or, am I always safe to assume the thread will complete its execution before the application quits?
You cannot assume that any thread -- including the main thread -- will ever complete execution normally, regardless of the documentation.
This is because the user can quit an application at any time, the system may lose power/panic, or the app may crash.
As for detached threads, it would not be unheard of for the system frameworks to automatically terminate the app forcibly after some timeout once the main event loop has given up the ghost.
I want to write a program, that should be notified by O.S. whenever any running process on that OS dies.
I don't want to myself poll and compare everytime if a previously existing process has died. I want my program to be alerted by OS whenever a process termination happens.
How do I go about it? Some sample code would be very helpful.
PS: Looking for approaches in Java/C++.
Sounds like you want PsSetCreateProcessNotifyRoutine(). See this article to get started:
http://www.codeproject.com/KB/threads/procmon.aspx
Under Unix, you could use the sigchld signal to get notified of the death of the process. This requires, however, that the process being monitored is a child process of the monitoring process.
Under Windows, you might need to have a valid handle to the process. If you spawn the process yourself using CreateProcess, you get the handle for free, otherwise you must acquire by other means. It might then be possible to wait for the process to terminate by calling WaitForSingleObject on the handle.
Sorry, I don't have any example code for this. I am not even sure, that waiting on the process handle under Windows really awaits termination of the process (as opposed to some other "significant" condition, which causes the process handle to enter "signalled" state or something).
I don't have a code sample ready but one idea – on Linux – might be to find out the ID of the process you'd like to watch when first starting your watcher program (e.g. using $ pgrep) and then using inotify to watch /proc/<PID>/ – which gets deleted when the process dies. In contrast to polling, this doesn't cost any significant CPU resources.
Now, procfs is not completely supported by inotify, so I can't guarantee this approach would actually work but it is certainly worth looking into.