You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When Ruby applications are used as the top process in a system (which can happen in certain containers), they must "reap" child processes.
Moreover, it's a good practice for web application servers to implement child reaping where the proficiency of the app developer is an unknown. Otherwise, a poorly designed app might result is a high zombie count that the kernel won't reap until the server is restarted.
When a developer / server implements this "reaping" in order to prevent zombie processes, the execjs gem will fail.
This failure will be caused by the gem's reliance on the special $? virtual variable that might be empty when a child process is reaped before pidwait is called (in the IO class, the IO#close calls pidwait).
An alternative approach to the $? testing is required to avoid this issue.
The text was updated successfully, but these errors were encountered:
When Ruby applications are used as the top process in a system (which can happen in certain containers), they must "reap" child processes.
Moreover, it's a good practice for web application servers to implement child reaping where the proficiency of the app developer is an unknown. Otherwise, a poorly designed app might result is a high zombie count that the kernel won't reap until the server is restarted.
When a developer / server implements this "reaping" in order to prevent zombie processes, the
execjs
gem will fail.This failure will be caused by the gem's reliance on the special
$?
virtual variable that might be empty when a child process is reaped beforepidwait
is called (in the IO class, theIO#close
callspidwait
).An alternative approach to the
$?
testing is required to avoid this issue.The text was updated successfully, but these errors were encountered: