Is there any command that will list all background threads in a GHCi session? And next question is, how to kill one (or all) of them?
Related:
Is there a way to kill all forked threads in a GHCi session without restarting it?
How to be certain that all threads have been killed upon pressing Ctrl+C
No. If you want the ThreadIds of running threads, it is your responsibility to keep track of them when you forkIO.
Related
In Linux & C, will not waiting (waitpid) for a fork-execve launched process create zombies?
What is the correct way to launch a new program (many times) without waiting and without resource leaks?
It would also be launched from a 2nd worker thread.
Can the first program terminate first cleanly if launched programs have not completed?
Additional: In my case I have several threads that can fork-execve processes at ANY TIME and THE SAME TIME -
1) Some I need to wait for completion and want to report any errors codes with waitpid
2) Some I do not want to block the thread and but would like to report errors
3) Some I don't want to wait and don't care about the outcome and could run after the program terminates
For #2, should I have to create an additional thread to do waitpid ?
For #3, should I do a fork-fork-execve and would ending the 1st fork cause the 2nd process to get cleaned up (no zombie) separately via init ?
Additional: I've read briefly (not sure I understand all) about using nohup, double fork, setgpid(0,0), signal(SIGCHLD, SIG_IGN).
Doesn't global signal(SIGCHLD, SIG_IGN) have too many side effects like getting inherited (or maybe not) and preventing monitoring other processes you do want to wait for ?
Wouldn't relying on init to cleanup resources leak while the program continues to run (weeks in my case)?
In Linux & C, will not waiting (waitpid) for a fork-execve launched process create zombies?
Yes, they become zombies after death.
What is the correct way to launch a new program (many times) without waiting and without resource leaks? It would also be launched from a 2nd worker thread.
Set SIGCHLd to SIG_IGN.
Can the first program terminate first cleanly if launched programs have not completed?
Yes, orphaned processes will be adopted by init.
I ended up keeping an array of just the fork-exec'd pids I did not wait for (other fork-exec'd pids do get waited on) and periodically scanned the list using
waitpid( pids[xx], &status, WNOHANG ) != 0
which gives me a chance report outcome and avoid zombies.
I avoided using global things like signal handlers that might affect other code elsewhere.
It seemed a bit messy.
I suppose that fork-fork-exec would be an alternative to asynchronously monitor the other program's completion by the first fork, but then the first fork needs cleanup.
In Windows, you just keep a handle to the process open if you want to check status without worry of pid reuse, or close the handle if you don't care what the other process does.
(In Linux, there seems no way for multiple threads or processes to monitor the status of the same process safely, only the parent process-thread can, but not my issue here.)
In the documentation for Node's Child Processes, there is this sentence in the section on child_process.spawn():
On Windows, setting options.detached to true makes it possible for the
child process to continue running after the parent exits.
That makes it sound like (at least on Windows) when you leave options.detached to the default value of false, spawn()'d processes will automatically be killed. That's actually the behavior I want in my application, and in fact I was calling myChildProcess.kill( "SIGINT" ) in my code, but commented it out, and the child processes still went away when my app quit. So that's great, but:
(1) My understanding is that it's necessary to do some tricky stuff with "job objects" as discussed here in order to make this work on Windows. Do you know if Node is doing something tricky like that to make child processes go away? Or perhaps it's more simple than that and Node just keeps a list of the spawned process IDs and kills any of them that are still around when shutting down? Which leads to the closely related question...
(2) If Node is indeed doing something special to kill child processes, do you know if there are cases (e.g., some kind of app crash) that would defeat what it's doing and leave the child processes running?
UPDATE: To clarify, the child processes I'm launching in my case are Python web server processes, not other Node processes. I don't know if there's a difference in behavior between a Node child process and some other child process for the purpose of this question.
A Node instance will quit as long as there is nothing left in the event queue (and no async code pending), so as long as you aren't leaving anything open then naturally a Node process will quit when it's done.
In terms of the process hanging on a crash, unless you are explicitly handling uncaught exceptions the the process will exit immediately.
If you want a child process to be long-running and to survive the termination of the node process itself, as you know you set options.detached = true.
This business of stopping a child process when a parent process stops is operating-system behavior. A parent process (running any programming language system, not just node) owns a non-detached child process. The OS cleans up child processes upon the termination of their parent.
Detaching a process tells the OS to make it no longer a child process, so the OS won't clean it up automatically.
A good practice for node child processes: whenever possible, have them do their assigned task and then exit. In other words, in most cases you should not need to rely on this child / detached behavior.
Is it possible to stop a PID from being reused?
For example if I run a job myjob in the background with myjob &, and get the PID using PID=$!, is it possible to prevent the linux system from re-using that PID until I have checked that the PID no longer exists (the process has finished)?
In other words I want to do something like:
myjob &
PID=$!
do_not_use_this_pid $PID
wait $PID
allow_use_of_this_pid $PID
The reasons for wanting to do this do not make much sense in the example given above, but consider launching multiple background jobs in series and then waiting for them all to finish.
Some programmer dude rightly points out that no 2 processes may share the same PID. That is correct, but not what I am asking here. I am asking for a method of preventing a PID from being re-used after a process has been launched with a particular PID. And then also a method of re-enabling its use later after I have finished using it to check whether my original process finished.
Since it has been asked for, here is a use case:
launch multiple background jobs
get PID's of background jobs
prevent PID's from being re-used by another process after background job terminates
check for PID's of "background jobs" - ie, to ensure background jobs finish
[note if disabled PID re-use for the PID's of the background jobs those PIDs could not be used by a new process which was launched after a background process terminated]*
re-enable PID of background jobs
repeat
*Further explanation:
Assume 10 jobs launched
Job 5 exits
New process started by another user, for example, they login to a tty
New process has same PID as Job 5!
Now our script checks for Job 5 termination, but sees PID in use by tty!
You can't "block" a PID from being reused by the kernel. However, I am inclined to think this isn't really a problem for you.
but consider launching multiple background jobs in series and then waiting for them all to finish.
A simple wait (without arguments) would wait for all the child processes to complete. So, you don't need to worry about the
PIDs being reused.
When you launch several background process, it's indeed possible that PIDs may be reused by other processes.
But it's not a problem because you can't wait on a process unless it's your child process.
Otherwise, checking whether one of the background jobs you started is completed by any means other than wait is always going to unreliable.
Unless you've retrieved the return value of the child process it will exist in the kernel. That also means that it's pid is bound to it and can't being re-used during that time.
Further suggestion to work around this - if you suspect that a PID assigned to one of your background jobs is reassigned, check it in ps to see if it still is your process with your executable and has PPID (parent PID) 1.
If you are afraid of reusing PID's, which won't happen if you wait as other answers explain, you can use
echo 4194303 > /proc/sys/kernel/pid_max
to decrease your fear ;-)
Hi all~ I have a problem boring me so much.
Sometimes when I exit my program, there are some thread still running, in Linux system, it will cause crash after I quit the main loop. Is there any method that can kill all threads when I quit main loop?
It would help a lot if you specified your programming language and threading library of choice.
The usual way to control this type of situation (that is for a parent thread to wait until children complete before terminating) is to call a function supplied by the library, usually named join or wait.
pthread supplies you with pthread_join, for example.
If you're spawning processes via fork, you should use wait or waitpid in the parent to halt until the child completes - try man waitpid or take a look at this.
This way you can inform your children that you are about to exit via the usual means, wait until they wrap up and terminate, then cleanly exit the main loop.
Does this help? This is the least brutal way of synchronizing termination, if you want to actively kill the children threads there are alternatives, of course (like pthread_kill for pthreads, for example).
If you are using java try using the jconsole (Java Monitoring & Management Console) shipped with jdk6u23 in my case. You can get the thread name that is not killed. You can use join for that thread to complete.
But there can be program issue like, in my case i had a timer thread hanging [Timer-0] java.util.Timer to make an a timer.cancel() which closed that timer.
I have big process running. It spawns two threads. I want to debug those two threads separately. But there is only one gdb prompt. How to do this? Means I want to parallely see the execution of the threads.
You can not run just some of the threads under the debugger. They will all run and they will all stop. Some thread may progress more than other, that depends on the scheduler of the OS and is out of the reach of the debugger. With that said, once you stop inside a break point you can review the threads one at a time. You can also set conditional breakpoints which will stop the execution only if a certain thread pass by them.
I think you will find that article useful:
http://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_24.html#SEC25