[Nut-upsuser] syslog flooding

Charles Lepple clepple at gmail.com
Sun Nov 21 02:27:58 UTC 2010

On Nov 19, 2010, at 7:13 AM, Gene Heskett wrote:

> Greetings;
> Nut pull & build from about two weeks ago, 2.4.3 I believe.

The 2.4.3 tarball, or from SVN? (If SVN, there should be a number  
after 2.4.3, such as 2.4.3-r1234).

>  Belkin UPS.
> I have everything working but a proper shutdown of upsd when I reboot,
> it hangs there and needs the hdwe reset button to reset it.  That  
> may be
> related to my finding more than 1 K##upsd and more than one  
> K##upsmon, in
> /etc/rc5.d and which I have now nuked.
> However, while its working well enough to monitor, it is flooding the
> syslog every 2 seconds with:
> Nov 19 07:05:56 coyote upsd[4884]: mainloop: Interrupted system call
> Nov 19 07:05:56 coyote upsd[4884]: Signal 15: exiting
> Nov 19 07:05:56 coyote usbhid-ups[4874]: Signal 15: exiting

^^^ Is this part repeating, or was this just the first portion after  
restarting NUT? (In a normal setup, upsd should be started once, and  
shouldn't be killed until shutdown time.)

> Nov 19 07:06:30 coyote klogd: ohci_hcd 0000:00:02.0: urb e7d21400  
> path 9 ep1in 93120000 cc 9 --> status -121

Looks like -121 is -EREMOTEIO, which apparently means this (from  
Documentation/usb/error-codes.txt in the kernel tree):

"The data read from the endpoint did not fill the
specified buffer, and URB_SHORT_NOT_OK was set in

The fact that it is happening every two seconds might be a clue, but I  
am not familiar with the main status loop in usbhid-ups (I would have  
thought it would poll only once every 30 seconds, based on the man  
page). Perhaps one of the authors of usbhid-ups has a better idea of  
whether we can fix this (since libusb doesn't expose the URB  
transfer_flags options), or if it is something we can't work around.

More information about the Nut-upsuser mailing list