[systemd-devel] [PATCH] log: add log_errno() helper

[Lennart Poettering]

On Fri, 15.11.13 15:26, David Herrmann (dh.herrmann at gmail.com) wrote:

> file-name and line is actually what I wanted (does log_meta() suppress
> these?). Custom error-messages don't really make much sense.
> 
> For example: Assume you have a function to open an input device. The
> function itself has to run a bunch of syscalls:
>  - open() (open device node)
>  - ioctl() (get device bits, like 10 EVIOC* ioctls)
>  - write() (to initialize LED values)
> These are all mostly straightforward and shouldn't fail if the device
> is valid. However, they *can* fail for various reasons (daemon not
> running with enough privileges, device being unplugged during
> operation, ...) but it's almost impossible to detect these properly.
> So we want debug/error messages.
> 
> If we now add a custom log_error() message for each of these calls,
> they will be something like "EVIOCGABS failed: %m". To a user this is
> as helpful as "syscall failed in $file:$line:$func". So I thought, we
> can avoid cluttering .text with useless error-messages and just print
> $file:$line:$func and %m.

They might not be helpful to the user, but they are for the developer
who the user complains to. Much unlike the file/line which is highly
dependent on the version you have built. 

I don't think we really need to optimize the log messages on error
away. Doing log_error("EVIOCGABS: %m") doesn't look like too much. 

> 
> Does that make sense?
> 
> Note that this obviously is only for developer error-messages. For
> functions like open() it makes sense to handle it separately. A
> message like "cannot open /dev/$sth: Access denied" even helps users,
> not only developers. The log_errno() is really intended for stuff like
> custom ioctls/etc.

I'd side with Zbsyzek here... It's difficult to draw a line between user
and developer messages, and people frequently are somewhat in the middle
of it too (i think those folks are called "devops" these days ;-).

I am pretty sure we should keep proper log messages for these cases
too. You can keep them terse of course, they'd don't need to have the
highest quality of proper sentences, but they should give an educated
man an idea what failed without him having to figure out the version of
the binary and then look into the sources...

Lennart

-- 
Lennart Poettering, Red Hat