similar to: Are UPS shutdown commands automatically sent?

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 am running tests on my system and UPS, making sure that it is reliably able to come up, detect power loss, shutdown safely, and then come back up when the power returns. 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

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 Fri, 22 May 2015, Rob Groner wrote: > 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

> 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? --

Roger, Your guide is already my go-to source, especially since openSUSE 13.1 is our currently supported system (though I'm doing this testing on Porteus due to its file system resilience). It's AWESOME, btw. Very helpful. I'll spend some time tomorrow going through chapter 6 and trying again. Sincerely, Robert G. Groner Software Engineer RTD Embedded Technologies, Inc. ISO 9001

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.

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 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 Fri, 4 Sep 2015, Rob Groner wrote: > Well, I tried the same script method with openSUSE 13.2, and it still did not execute. > > So I tried the system method, and it worked 1 time out of 3 attempts. I captured the last failure: > 2015-09-04T11:43:38.825317-04:00 linux-5048 upsdrvctl[1887]: Can't claim USB device [2a37:5110]: No such file or directory >

On Tue, 8 Sep 2015, Rob Groner wrote: > I executed lsusb to verify the USB device is there, and it is. I tried > the shutdown command again with debug enabled, but it didn't seem to > reveal much more: > ----------------------------------------------------------------------------------------------- > rtd at linux-5048:~> sudo /usr/local/ups/sbin/upsdrvctl -DDDDD shutdown

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

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

I'm testing that my system will shutdown when the UPS has been on battery for 10 seconds. That all works fine....10 seconds after pulling the plug, my system does shut down. However, I am not getting the commands into the UPS telling it to power off and then power on. I had thought I read somewhere that these commands are sent automatically when "upsmon -c fsd" happens...but I

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

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

Hello Bob, > I had preferred the shutdown script method because it was a little more > straight-forward, and possibly more portable. This guide is meant to > help people get the UPS up and running, whatever their Linux distro. I > don't know how common the systemd implementation is across various Linux > distros. You will need to support Linux systems with and without

I'm probably spending WAY too much time on this question, but.... If the goal is just to perform a clean shutdown, and the power might cycle a few more times before coming back completely, then shutdown.stayoff might make more sense. A human could come along and manually power it back on. ...by plugging the PC into a new power source? Because the UPS outlet would be shut off, so hitting the

Having dealt with the USB portion of our UPS, I'm now reviewing our serial port communication. I've looked over some of the drivers in NUT to see how they handle it so I can get an idea of what the "standard" is for how to accomplish it. I'd like to do something simple and human readable. It seems like most data is gathered from a query and a response. Is that typical? I

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