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.
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
execjsgem 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 beforepidwaitis called (in the IO class, theIO#closecallspidwait).An alternative approach to the
$?testing is required to avoid this issue.