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.

Reply via email to