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

[Allen-Webb]

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]

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]

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]

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:

usbguard/src/Daemon/main.cpp

Lines 196 to 197 in 4957d2d

	daemon.run();
	ret = EXIT_SUCCESS;

And it seems that the systemd service is configured to only restart on failures:

usbguard/usbguard.service.in

Line 25 in 4957d2d

Restart=on-failure

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]

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

[genodeftest]

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]

From upstream point of view this seems to be fixed.