El jue., 17 oct. 2019 a las 16:51, Laurent Bercot escribió: > > Hurd should return -1 ENXIO, > unless there is a real problem with the underlying file system - and the > test your patch comments exists to catch such problems.
…or an error in the underlying operating system. POSIX open() seems to be implemented directly by the Hurd: * https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/open.c;h=e093b67c1e3aa99bc3ca9999f485feaf8f226dc0;hb=56c86f5dd516284558e106d04b92875d5b623b7a . And the call seems to be failing with that special Hurd errno code, EIEIO, which... is not a good thing :P * http://www.gnu.org/software/hurd/faq/eieio.html "This error code is used for a variety of "hopeless" error conditions. Most probably you will encounter it when a translator crashes while you were trying to use a file that it serves." * https://sourceware.org/git/?p=glibc.git;a=blob;f=manual/errno.texi;h=8cb4ce8b489dbbc6b3decef023cb3cafa471a32b;hb=56c86f5dd516284558e106d04b92875d5b623b7a "@errno{EIEIO, 104, Computer bought the farm} Go home and have a glass of warm, dairy-fresh milk. [...] @c Translators, please do not translate this litteraly, translate it into @c an idiomatic funny way of saying that the computer died." So, whoever calls s6_supervise_lock_mode() should correctly die, as there is an actual error (that should be reported to the Hurd developers); libs6, libskarnet and the libc are just the messengers. Commenting out the errno check just sweeps the error under the carpet. G.