search

USBGuard / usbguard

USBGuard is a software framework for implementing USB device authorization policies (what kind of USB devices are authorized) as well as method of use policies (how a USB device may interact with the system)
https://usbguard.github.io/
GNU General Public License v2.0
1.12k stars 136 forks source link

EINTR causes: sigwaitinfo failed: errno=4; Shutting down. #261

Closed Allen-Webb closed 4 years ago

Allen-Webb commented 5 years ago

Under some circumstances sigwaitinfo (and other syscalls) can get an EINTR which generally means the program should repeat the previous syscall because of an interrupt, so it might make sense to call sigwaitinfo again.

However, this might be intended behavior or better left as is if usbguard were to lose track of uevents or other system state changes having it close on EINTR would give it the opportunity for the daemon to be respawned and pickup the current state instead of resuming with the old state. I am not convinced the state would get out of sync in practice,

You can trigger this behavior by the following: sudo kill -SIGSTOP ${USBGUARD_PID}; sudo kill -SIGCONT ${USBGUARD_PID} It isn't necessary to send a SIGSTOP though, an EINTR can happen for a variety of reasons, this is just an easy way to trigger the behavior. Ideally, if you want to handle EINTR, you would need to do it for a good number of the syscalls besides just sigwaitinfo.

rathann commented 5 years ago

Is my downstream bug report related? https://bugzilla.redhat.com/show_bug.cgi?id=1751861 . I frequently get logs like this:

Sep 11 10:20:31 usbguard-daemon[11714]: sigwaitinfo failed: errno=4; Shutting down.

and find usbguard not running and my external keyboard/mouse not working after I leave my machine idling for over an hour.

infokiller commented 4 years ago

I can confirm what @rathann is seeing. In my specific case it was even more painful, because it happened on a desktop computer with no built in keyboard, so I had to do a hard reboot to make the keyboard functional again.

infokiller commented 4 years ago

If I understand the code correctly, the big issue is that when this error happens, it doesn't affect the exit code of the process, which will always return success: https://github.com/USBGuard/usbguard/blob/4957d2d0bc4c2ed4529e8b69f9813c735d51a69a/src/Daemon/main.cpp#L196-L197

And it seems that the systemd service is configured to only restart on failures: https://github.com/USBGuard/usbguard/blob/4957d2d0bc4c2ed4529e8b69f9813c735d51a69a/usbguard.service.in#L25

So it means that once this error happens, the systemd service will finish with success and not be restarted. I guess that as a workaround, I can systemd edit the service file to always restart. As for a long term fix, is there any objection for a PR that makes the process exit with an error in this case?

zuzzurro commented 4 years ago

On my fedora 31 usbguard is basically useless as it keeps exiting. Is someone actually looking into this?

genodeftest commented 4 years ago

On my fedora 31 usbguard is basically useless as it keeps exiting. Is someone actually looking into this?

There is an update, also for Fedora 31 but I now instead see issue #279 which breaks usbguard completely in my case.

radosroka commented 4 years ago

From upstream point of view this seems to be fixed.