[systemd-devel] Antw: Re: Antw: Re: Antw: [EXT] I/O error on "systemctl kill -s HUP rsyslog.service"

[Ulrich Windl]

>>> Lennart Poettering <lennart at poettering.net> schrieb am 13.08.2020 um 11:13
in
Nachricht <20200813091301.GF229811 at gardel-login>:
> eOn Do, 13.08.20 09:24, Ulrich Windl (Ulrich.Windl at rz.uni‑regensburg.de) 
> wrote:
> 
>> > systemd should really clearly log this (invalid PID and and in which
>> > cgroup it was). Returning generic error message without any indication
>> > what caused this error is not useful at all.
>>
>> Especially as there was no I/O error at all ;‑) Maybe EINVAL or ESRCH
would
>> have been a better error code.
> 
> We generate EIO because the I/O data we read was bogus and can't
> possible be correct.
> 
> I really don't think the precise error code here matters much, as long
> as we generate an error.
> 
> ESRCH is not the right error, it suggests that there was a valiD PID
> number but simply no matching process for it. But that's not the case
> here, the PID "0" is not valid at all.
> 
> Note that we'd probably generate EINVAL here, if this was a different
> type of interface, i.e. some explicit syscall or so. But here we have
> a read() call where we get the clearly borked data from, hence we
> generate this as EIO and not EINVAL.

I disagree: EIO would suggest that no data could be read. In fact data was
read, but data was invalid. This is not an I/O error. (Think about this: The
compiler reads an invalid C program, and it says "I/O Error") ;-)

> 
> Ultimately, which error code to generate is just bike‑shedding though...
> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin