Hello, can any kernel gurus please help me out with what happens on this weird corner-case? Quoting Rich Felker at http://ewontfix.com/14/: > For common reasons it might fail, the execve syscall returns failure > in the original process image, allowing the program to handle the > error. However, failure of execve is not entirely atomic: > > The kernel may fail setting up the VM for the new process image > after the original VM has already been destroyed; the main > situation under which this would happen is resource exhaustion. > > Even after the kernel successfully sets up the new VM and > transfers execution to the new process image, it's possible to > have failures prior to the transfer of control to the actual > application program. This could happen in the dynamic linker > (resource exhaustion or other transient failures mapping required > libraries or loading configuration files) or libc startup > code. Using musl libc with static linking or even dynamic linking > with no additional libraries eliminates these failure cases, but > systemd is intended to be used with glibc. execve is not atomic, what is the exit state of the process when execve fails after throwing away the original process image? I already have a hacky solution (see https://gitorious.org/linted/linted/source/d25eac7a6fb58946ec8112771c0c56eb39fd1055:src/spawn/spawn.c) to finding when a process fails before or at execve and now I want to know what exit status is returned so I can give a nice error message. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
