similar to: upsd not starting sometimes (Porteus 3.1, nut 2.7.2)

> On Sep 9, 2015, at 10:12 AM, Rob Groner <rgroner at RTD.com> wrote: > > linux-5048:/home/rtd # ldd /usr/local/ups/bin/usbhid-ups > linux-vdso.so.1 (0x00007fff403fc000) > libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f7c34b56000) The last line seems to indicate that it is the real libusb-0.1, not -compat. What kernel version on openSUSE? --

On Sep 9, 2015, at 9:40 AM, Rob Groner <rgroner at RTD.com> wrote: > > I'm not sure which USB lib it compiled against. What does this return? ldd /path/to/driver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150909/ba08f4c0/attachment.html>

On Jul 7, 2015, at 4:12 PM, Rob Groner <rgroner at RTD.com> wrote: > It does that MOST of the time. However, a significant part of the time, the system comes up, and then doesn?t respond to loss of power. Doing some checking, I find that the reason is because upsd never started. Capturing its output, I see that it says : > > Fatal error: A previous upsd instance is already

On Sep 10, 2015, at 8:49 AM, Rob Groner <rgroner at RTD.com> wrote: > > Charles, > > 3.16.6.-2-desktop I think that corresponds to this file: http://lxr.free-electrons.com/source/drivers/usb/core/devio.c?v=3.16 (but I don't see anything obvious there) What does "lsusb -vvv -d 2a37:" return? Usually I'd say run that as root when the driver isn't running,

On Sep 8, 2015, at 4:48 PM, Rob Groner <rgroner at RTD.com> wrote: > > 0.005927 Device matches > 0.005940 failed to claim USB device: Device or resource busy > 0.005954 failed to detach kernel driver from USB device: No such file or directory Rob, this is a bit of a tough one to track down. The "Device or resource busy" message can either come from a kernel

On Sep 10, 2015, at 10:28 AM, Rob Groner <rgroner at RTD.com> wrote: > [...] > I noticed the "can't open device" at the top of the listing before, but I also saw that every other entry in the results from "lsusb -vvv" (including the mouse) had the same string, so I didn't think it was unusual. I did notice that my USB stick didn't have that message.

Roger, So I'm pursuing the strategy of issuing the "upsdrvctl shutdown" command script when the OS (Porteus, in this case) is shutting down. I so far can't get it to do it, but I'm sure I'll overcome it, but I realized something else might be a problem. Won't that script execute every time Linux is shutting down, including rebooting? So, if I choose to reboot my

For fun, if you want to see where the system thinks it is linking a library from, you can use "ldconfig -p" and it will give you a path to all known libraries that it can find. If you have one loaded, and it can't find it (odd directory, etc.) you can always amend "LD_LIBRARY_PATH" the same way as PKG_CONFIG_PATH I mentioned earlier . . . . PKG . . . is for the build

Rob - Just stepping in from the sidelines . . . with a few tidbits. Nut uses pkgconfig to find and identify stuff as part of it's build . . . So, depending on where your libusb install went, if it wasn't in the default "PKG_CONFIG_PATH" setting, it won't be found. Much like other shell variables, you can adjust that setting to find anything you like . . . IE

On Mar 9, 2015, at 12:00 PM, Rob Groner <rgroner at RTD.com> wrote: > 1) Autoreconf *must* be run, and not ./configure? I had thought that putting in my *.c and *.h files and making the makefile changes and then executing ./configure for the first time would be enough. Each tool serves a different purpose. autoreconf (and NUT's autogen.sh, by inclusion) generates the ./configure

And now....suddenly, and so far unexplainably....it works again. I did the same as before, installed openSUSE 13.1 from scratch, then installed the libusb* libraries. And now...it works, so far reliably. I'm certain that there is some micro-step I started doing different than last time. For example, I used to install jedit from the command line after install, but I had started installing

On Sep 21, 2015, at 9:39 AM, Rob Groner <rgroner at RTD.com> wrote: > > I didn't think to look for a log (attached), but now looking in it, I don't see anything more than I already thought I knew. It's as cryptic as configure itself. > > It does reference the line in the configure where the test for USB failed, but I'd already been looking in there. I

On Mar 10, 2015, at 11:20 AM, Rob Groner <rgroner at RTD.com> wrote: > I added "_RTD" to the version string in configure.ac and ran autogen.sh and then configure, and it now shows the _RTD version string during configure. I did a clean make and install, but don't see where else the version number may be showing. When the executables startup, they show 2.7.2-signed-*. I

On Sep 22, 2015, at 3:47 PM, Rob Groner <rgroner at RTD.com> wrote: > So, here is what I think I know: > > NUT is using the libusb-1.0.20 library, by way of the libusb-compat layer. When I check the configure log, it says "libusb-0.1.12" I'm not sure why it says that, as in where it gets that value, as that version doesn't correspond to anything I installed. I

On Sep 18, 2015, at 2:45 PM, Rob Groner <rgroner at RTD.com> wrote: > > Well, I've spent a couple hours on this, unable to figure it out. I removed the libusb-compat-devel package using zypper. And I've downloaded, built, and installed libusb from sourceforge. But trying to configure nut now I get "USB drivers requested, but libusb not found", no matter what I put

On Sep 15, 2015, at 9:31 PM, Charles Lepple <clepple at gmail.com> wrote: > >> Trying to track down the source of the problem, I checked Yast to make sure I had at least 0.1.8 version for libusb. I saw this (attached photo). Is it then actually using ?compat instead of the ?real? libusb? And is that a problem? > > You're right, both the -compat and real libusb

I'm doing testing of the UPS-side code, including being able to tell the UPS to shutdown and then come back up after a while (if power has returned). I'm trying to use upscmd so that I don't have to do an actual shutdown, but when I have it list the commands for my UPS, I just see 4 commands, and they're not the ones I thought I had specified. load.on load.off shutdown.return

Roger, Following your guide, it now works great, shutting down the UPS after the system has shutdown. I went with the bash script method. I have noticed, however, that the command to the UPS to do the delayed shutdown comes RIGHT as openSUSE is shutting down. While that is a good thing as far as timing and the potential race is concerned, I have seen it once where the UPS received the command

I found something particularly strange while trying out different things: I started up upsdrvctl, upsd, and upsmon. I then stopped upsdrvctl, and tried starting the usbhid-ups driver a few times. Each time I executed the driver, it indicated an instance was already running, stopped it, and then started it again....which is what it should do. I then added -DDDD to the command....and then it

We're wrapping up our first version of the UPS we're making, and so I'm going over the USB code and came across one loose end. The serial number of the unit (iSerialNumber according to the USB HID doc) is a constant, but it's of course a different constant for each UPS. Right now we store that value in the Flash on the device, but the only way I've seen to pass the serial