Hi Remi, David is right - a few more details:
In both fork- and vfork-mode we fork/vfork the child process and in the child process then exec() the target binary (in this case "java" itself). In posix_spawn mode, for complicated reasons, we start, via posix_spawn(), the jspawnhelper - which, depending on the glibc involved, will either vfork() or clone() the child process and then exec() the jspawnhelper binary. Then, inside the jspawnhelper, we will exec() a second time, this time the target binary. (So, small correction, we do not have an intermediate _process_ here - at any time only two processes are involved, the parent and the child - but inside the child we call exec() twice.) If you get EACCESS only in posix_spawn() mode, the only difference to fork/vfork is that we exec() jspawnhelper. That is a binary located in the jdk and should have the correct permissions set. If you have a reproducible scenario, can you strace the call? (you would probably need "strace -f", and if you see in the output the jspawnhelper path with either _vfork or _clone system calls it worked). Cheers, Thomas On Sat, May 11, 2019 at 5:15 PM David Lloyd <david.ll...@redhat.com> wrote: > On Sat, May 11, 2019 at 9:49 AM Remi Forax <fo...@univ-mlv.fr> wrote: > > > > I've seen a weird error on my CI [1] since the 15th of February when > using the jdk 13, > > i was not able to run jshell* using the programmatic API (java tool) > anymore. > > > > Yesterday, i took the time to track that issue and i believe i've found > the root cause, trying to execute the java launcher using > ProcessBuilder.start() with the jdk 13 sometimes fails with an i/o > exception (errno 13) which is weird because you are trying to execute the > same process that the one you are executing. Note that this is a spurious > bug, I was not able to find the exact condition that triggers that bug. > > So sometime it works, sometime it doesn't. > > Assuming you're running on Linux (given that the changeset only > applies to Linux), errno 13 is EACCES which would indicate a > filesystem permission issue. Are you sure you have permission to > execute `jspawnhelper` in your JVM installation? Could there be an > SELinux restriction in place? > > Here's what the man page says: > > ``` > > [EACCES] Search permission is denied for a component of > the path prefix. > > > [EACCES] The new process file is not an ordinary file. > > > [EACCES] The new process file mode denies execute > permission. > > > [EACCES] The new process file is on a filesystem > mounted with execution > > disabled (MNT_NOEXEC in <sys/mount.h>). > ``` > > > If i pass -Djdk.lang.Process.launchMechanism=fork (or vfork) when > starting the VM, the bug disappear meaning that the bug occurs when the VM > is trying to use posix_spawn, perhaps spawn is trying to do an optimization > when you try to execute the same process as the one you are running under > some conditions ? > > The posix_spawn approach executes an intermediate support process > (`jspawnhelper`) which in turn executes the target process. I believe > there's an extensive discussion on the reasons for this in the > `core-libs-dev` archive. > > > -- > - DML >
