Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not getting SIGCHLD when a child process dies #3283

Closed
auroranockert opened this issue Aug 25, 2015 · 3 comments
Closed

Not getting SIGCHLD when a child process dies #3283

auroranockert opened this issue Aug 25, 2015 · 3 comments

Comments

@auroranockert
Copy link

You do not get a signal when a child process dies, you should get SIGCHLD.

Example, the following code works on MRI (and is differently broken on pre-9k JRuby, where you do get SIGCHLD, but the processed is reaped by Java)

https://gist.github.com/jensnockert/05e03714f57ee04ec2da

@auroranockert
Copy link
Author

Okay, running dtrace on this

dtrace -qn '
proc:::signal-discard
{
        printf("Process %d discarded signal %d\n",
        args[1]->pr_pid,args[2]);
}'

I get Process 26312 discarded signal 20 so we're discarding the SIGCHLD.

@auroranockert
Copy link
Author

@headius helped me find that if you add java.lang.UNIXProcess to the top of the script, it starts working. That class should probably be loaded early.

@headius
Copy link
Member

headius commented Aug 25, 2015

Root problem was that java.lang.UNIXProcess initializes after the user's trap is installed, and it then proceeds to reset SIGCHLD handling to default. According to sigaction man page, default behavior for SIGCHLD is to discard, so we silently lose the trap and the signal.

I have a fix that forces java.lang.Process and java.lang.UNIXProcess to load before setting up the Signal module. That should guarantee the JVM's SIGCHLD handler has been installed and that it will be overwritten by the user's trap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants