Comment # 35 on bug 939571 from Takashi Iwai

(In reply to Dr. Werner Fink from comment #33)
> Hmm ... wild guess ... in drivers/input/evdev.c I found with  evdev_flush()
> 
>         if (!evdev->exist || client->revoked)
>                 retval = -ENODEV;
>         else
>                 retval = input_flush_device(&evdev->handle, file);
> 
> ... could it be that close() does trigger flushing the device and the client
> has no permission anymore for doing that?(!)  Normally close(2) does not
> trigger a flush but I've no idea how this is handled for this kind of
> devices?  Maybe the is a pending I/O handler triggered to late.

A good catch.  The flush is always called at close internally in filp_close(),
and this is taken as a return code.  The file itself is closed no matter which
error is returned.

(In reply to Dr. Werner Fink from comment #34)
> IMHO this is more a kernel issue. I can work around this in the pam systemd
> module, nevertheless it is not clear if the file descriptor becomes leaked
> after the system call close(2) had failed with ENODEV.

The file is closed no matter flush returns an error, so there should be no
leak.  It's just an unexpected return code.  I'll bring the error code problem
to upstream, but let's keep working and see whether this is really the culprit
of the whole problem.

My guess is that the close() error is rather a red herring.  It brings logind
assert on systemd-210.  But the problem persists with systemd-219 on Tumbleweed
that doesn't kill logind, too.