Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
> -Original Message- > From: Charles Lepple [mailto:clep...@gmail.com] > Sent: Thursday, September 24, 2015 10:33 PM > To: Tim Dawson <tadaw...@tpcsvc.com> > Cc: Rob Groner <rgro...@rtd.com>; nut-upsuser Mailing List upsu...@lists.alioth.debian.org> > Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 > > On Sep 24, 2015, at 12:20 PM, Tim Dawson <tadaw...@tpcsvc.com> wrote: > > > > The "#! " is a *nix thing that exists in every *nix I have ever > > seen, for > as long as I know (mid 1980's for me . . ) and is used to specify what shell > is to > be loaded to run that script > > More specifically, this dates back to when the first two bytes of an a.out- > format executable file were the "magic" values used to determine how to > load it. The ASCII code for "#!" does not match any of those magic values, > and has the added benefit of being the start of a shell comment line. > Ya, that's the part that I hate the most, and why up until now I considered it dispensibleit's a COMMENT. Nowhere in software engineering should a comment actually affect the running of the program! That rant aside, I'm still not sure why this DOES affect the running. I'm not trying any fancy shell scripting tricks. I'm simply calling upsdrvctl. It's a single line in the file, and I can't imagine that bash or csh or any other scripting calls it differently. But *shrug* that's just my ignorance talking. Either way, SOMETHING is different now besides that because I wasn't able to get the systemd service unit to work before, and that has nothing to do with bash/shells. I'm going to try again today from scratch and make sure I've got it working. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
And nowsuddenly, and so far unexplainablyit 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 it at the same time as the OS install. There's NO WAY that should make a differencebut it certainly could be. I also discovered that the "#! /bin/bash" comment at the top of the shutdown script file was crucial...who knew? Thank you all for the patient help. I'm now putting the system through some systematic shutdown testing to make sure it's good, and then I'll start again from scratch and make sure I can repeat it, and then I'll finally be able to move on with wrapping this thing up. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com > -Original Message- > From: Nut-upsuser [mailto:nut-upsuser- > bounces+rgroner=rtd@lists.alioth.debian.org] On Behalf Of Rob Groner > Sent: Wednesday, September 23, 2015 9:02 AM > To: Charles Lepple <clep...@gmail.com> > Cc: nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> > Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 > > > >As I am not familiar with openSUSE's ldconfig, is there an /etc/ld.so.conf or > /etc/ld.so.conf.d/* entry >pointing to /usr/local/lib64? I am not sure if > libusb- > 0.1 tries to rerun ldconfig after installing, but if after >uninstalling > libusb- > compat, there are problems linking to the real libusb-0.1, then it can't hurt > to > re-run >ldconfig (as root). > > There's actually both of those thingsld.so.conf and the ld.so.conf.d > directory. There are entries in the ld.so.conf file for /usr/local/lib and > /usr/local/lib64. > > > Rob Groner > Software Engineer Level II > > RTD Embedded Technologies, Inc. > ISO 9001 and AS9100 Certified > Ph: +1 814-234-8087 > www.rtd.com > > > > ___ > Nut-upsuser mailing list > Nut-upsuser@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
>As I am not familiar with openSUSE's ldconfig, is there an /etc/ld.so.conf or >/etc/ld.so.conf.d/* entry >pointing to /usr/local/lib64? I am not sure if >libusb-0.1 tries to rerun ldconfig after installing, but if after >>uninstalling libusb-compat, there are problems linking to the real >libusb-0.1, then it can't hurt to re-run >ldconfig (as root). There's actually both of those thingsld.so.conf and the ld.so.conf.d directory. There are entries in the ld.so.conf file for /usr/local/lib and /usr/local/lib64. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
Thanks Charles, you were right about that. Here is what I tried...I installed openSUSE 13.1 from scratch (which means no libusb). I then took libusb-1.0 from the sourceforge site and built and installed it. Still it got the "cannot find libusb" error. So, looking at the sourceforge site, is see it mention that to work with the older libusb-0.1, you had to use libusb-compat-0.1.5. So, I downloaded, built, and installed that...and now ./configure is working. I'm sure this is all obvious to you, but I only now sort of understand the relationship between libusb-1.0 and libusb-0.1. 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 see looking at the last version of libusb-0.1 that was available, it was libusb-0.1.12, so it must be getting that version number from the libusb-compat layer, as I did not install the old libusb-0.1.12 on this last test. After installing libusb-1.0 and the libusb-compat layer and rebuilding NUT...it still doesn't work (as in, the shutdown command is not passed to the UPS due to can't claim message for USB). I could try reinstalling openSUSE and installing the old libusb-0.1.12 and see if that works. Perhaps it is the compat layer or the new libusb-1.0 that is the problem. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Monday, September 21, 2015 7:30 PM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 21, 2015, at 9:39 AM, Rob Groner <rgro...@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 can't make sense of the lines above > that set "nut_have_libusb", as far as what they're looking for. Clearly > somehow, that is supposed to be set to "yes". You have: ./configure --with-usb --with-dev --with-usb-includes=/usr/local/include --with-usb-libs=-L=/usr/local/lib64 I think you want: ./configure --with-usb --with-dev --with-usb-includes=-I/usr/local/include --with-usb-libs=-L/usr/local/lib64 The key lines in the compilation testing: configure:8062: gcc -o conftest /usr/local/include conftest.c -L=/usr/local/lib64 >&5 /usr/local/include: file not recognized: Is a directory ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
Thanks again Tim.
I installed openSUSE from scratch, without installing libusb anything. I tried
configure, and it failed because it couldn't find libusb. I used ldconfig to
see what the system could see. It found 3 entries with "libusb" in them.
I then built and installed the last update of libusb-0.1 (not libusb-compat or
libusb-1.0). I tried configure, and it ran without errors. I then execute
ldconfig, and it was the same as before the install.
So configure is finding these libusb libraries, but ldconfig doesn't seem to
know about them.
All of this might be a goose chase, but Charles hinted that libusb might be
part of the problem. I had this working fine earlier this year and now it
doesn't, and a changing version of libusb would explain that. Plus, if I
install openSUSE 13.1 AND install libusb* from the ISO, then it works. It's
just getting libusb from some other source that seems to be causing the problem.
Rob Groner
Software Engineer Level II
RTD Embedded Technologies, Inc.
ISO 9001 and AS9100 Certified
Ph: +1 814-234-8087
www.rtd.com
-Original Message-
From: Tim Dawson [mailto:tadaw...@tpcsvc.com]
Sent: Tuesday, September 22, 2015 4:52 PM
To: Rob Groner <rgro...@rtd.com>; nut-upsuser@lists.alioth.debian.org
Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
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 system, and LD. . . is for the runtime dynamic
linker.
- Tim
On 09/22/2015 03:48 PM, Rob Groner wrote:
> Tim,
>
> Thanks for the help! No, I didn't already know that... I swear, the more
> time I spend at this, the less I seem to be understanding.
>
> I know that it had to be finding the libusb-compat I had just installed,
> because configure hadn't worked before that, and now it did. But finding
> useful version information seems to be almost impossible.
>
> Rob Groner
> Software Engineer Level II
>
> RTD Embedded Technologies, Inc.
> ISO 9001 and AS9100 Certified
> Ph: +1 814-234-8087
> www.rtd.com
>
> -Original Message-
> From: Nut-upsuser
> [mailto:nut-upsuser-bounces+rgroner=rtd@lists.alioth.debian.org]
> On Behalf Of Tim Dawson
> Sent: Tuesday, September 22, 2015 3:56 PM
> To: nut-upsuser@lists.alioth.debian.org
> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
>
> 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 PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/new/component;export
> PKG_CONFIG_PATH (or as appropriate for the shell you use).
>
> Keep in mind that this is *NOT* the path where the library (.so or .a
> file) lives, but typically a directory *below* that with the pkgconfig
> .pc files, typically "pkgconfig". These .pc files tell the build
> system what is available, and what version they are, so for libusb on
> my system here libusb.pc (located in /usr/lib, PKG_CONFIG_DIR is
> /usr/lib/pkgconfig) is:
>
> prefix=/usr
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
>
> Name: libusb
> Description: USB access library
> Version: 0.1.12
> Libs: -L${libdir} -lusb
> Cflags: -I${includedir}
>
> This may help make sense of what version report, and how stuff gets found.
> Then again, if you already know this, sorry . . .
>
> - Tim
>
>
> On 09/22/2015 02:47 PM, Rob Groner wrote:
>> Thanks Charles, you were right about that.
>>
>> Here is what I tried...I installed openSUSE 13.1 from scratch (which means
>> no libusb). I then took libusb-1.0 from the sourceforge site and built and
>> installed it. Still it got the "cannot find libusb" error. So, looking at
>> the sourceforge site, is see it mention that to work with the older
>> libusb-0.1, you had to use libusb-compat-0.1.5. So, I downloaded, built,
>> and installed that...and now ./configure is working.
>>
>> I'm sure this is all obvious to you, but I only now sort of understand the
>> relationship between libusb-1.0 and libusb-0.1.
>>
>> So, here is what I think I know:
>>
>> NUT is using the libusb-1.0.20 library, by way of the libusb-compa
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
Tim,
Thanks for the help! No, I didn't already know that... I swear, the more time
I spend at this, the less I seem to be understanding.
I know that it had to be finding the libusb-compat I had just installed,
because configure hadn't worked before that, and now it did. But finding
useful version information seems to be almost impossible.
Rob Groner
Software Engineer Level II
RTD Embedded Technologies, Inc.
ISO 9001 and AS9100 Certified
Ph: +1 814-234-8087
www.rtd.com
-Original Message-
From: Nut-upsuser
[mailto:nut-upsuser-bounces+rgroner=rtd@lists.alioth.debian.org] On Behalf
Of Tim Dawson
Sent: Tuesday, September 22, 2015 3:56 PM
To: nut-upsuser@lists.alioth.debian.org
Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
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 PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/new/component;export
PKG_CONFIG_PATH (or as appropriate for the shell you use).
Keep in mind that this is *NOT* the path where the library (.so or .a
file) lives, but typically a directory *below* that with the pkgconfig .pc
files, typically "pkgconfig". These .pc files tell the build system what is
available, and what version they are, so for libusb on my system here libusb.pc
(located in /usr/lib, PKG_CONFIG_DIR is
/usr/lib/pkgconfig) is:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: libusb
Description: USB access library
Version: 0.1.12
Libs: -L${libdir} -lusb
Cflags: -I${includedir}
This may help make sense of what version report, and how stuff gets found.
Then again, if you already know this, sorry . . .
- Tim
On 09/22/2015 02:47 PM, Rob Groner wrote:
> Thanks Charles, you were right about that.
>
> Here is what I tried...I installed openSUSE 13.1 from scratch (which means no
> libusb). I then took libusb-1.0 from the sourceforge site and built and
> installed it. Still it got the "cannot find libusb" error. So, looking at
> the sourceforge site, is see it mention that to work with the older
> libusb-0.1, you had to use libusb-compat-0.1.5. So, I downloaded, built, and
> installed that...and now ./configure is working.
>
> I'm sure this is all obvious to you, but I only now sort of understand the
> relationship between libusb-1.0 and libusb-0.1.
>
> 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 see looking at the last version of libusb-0.1
> that was available, it was libusb-0.1.12, so it must be getting that version
> number from the libusb-compat layer, as I did not install the old
> libusb-0.1.12 on this last test.
>
> After installing libusb-1.0 and the libusb-compat layer and rebuilding
> NUT...it still doesn't work (as in, the shutdown command is not passed to the
> UPS due to can't claim message for USB).
>
> I could try reinstalling openSUSE and installing the old libusb-0.1.12 and
> see if that works. Perhaps it is the compat layer or the new libusb-1.0 that
> is the problem.
>
>
> Rob Groner
> Software Engineer Level II
>
> RTD Embedded Technologies, Inc.
> ISO 9001 and AS9100 Certified
> Ph: +1 814-234-8087
> www.rtd.com
>
> -Original Message-
> From: Charles Lepple [mailto:clep...@gmail.com]
> Sent: Monday, September 21, 2015 7:30 PM
> To: Rob Groner <rgro...@rtd.com>
> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List
> <nut-upsuser@lists.alioth.debian.org>
> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
>
> On Sep 21, 2015, at 9:39 AM, Rob Groner <rgro...@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 can't make sense of the lines
>> above that set "nut_have_libusb", as far as what they're looking for.
>> Clearly somehow, that is supposed to be set to "yes".
>
> You have:
>
> ./configure --with-usb --with-dev
> --with-usb-includes=/usr/local/include
> --with-usb-libs=-L=/usr/local/lib64
>
>
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
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 can't make sense of the lines above that set "nut_have_libusb", as far as what they're looking for. Clearly somehow, that is supposed to be set to "yes". Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Friday, September 18, 2015 7:06 PM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 18, 2015, at 2:45 PM, Rob Groner <rgro...@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 for > --with-usb-libs. Continuing to flog away at it... What's the error message? It might be hidden in config.log, but if you send that, please gzip it first. -- Charles Lepple clepple@gmail config_log.gz Description: config_log.gz ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
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 for --with-usb-libs. Continuing to flog away at it... Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Thursday, September 17, 2015 9:13 AM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 15, 2015, at 9:31 PM, Charles Lepple <clep...@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 packages will use the same > libusb-0.1.so* name. I misspoke. The "real libusb" (0.1) and libusb-compat will both get linked with "-lusb". The package management system is free to implement that with symlinks to the actual files. The confusing part is that openSUSE seems to be adopting the 0.1.1x numbering scheme for libusb-compat so that the package looks newer (0.1.13) than the real libusb-0.1.12: https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.spec?expand=1 Note the changes mentioned in the return codes for usb_detach_kernel_driver_np(): https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.changes?expand=1 Those are the sort of edge cases that haven't been fully tested with NUT. It seems like the path from NUT driver through libusb to the kernel is relatively unchanged with libusb-compat, but that mapping the errors back to root cause will depend on the exact version of libusb-compat in use (and potentially, the kernel version as well). I would recommend retesting with an explicit "killall usbhid-ups" (and anything else necessary to stop NUT background services, otherwise it will pop back up) before switching debug flags on. If that fails to turn up anything conclusive, you might try to install libusb-0.1.12 from source in a separate directory, and explicitly point ./configure to that tree: install from http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/ .../libusb-0.1.12 $ ./configure --prefix=$HOME/local/libusb-0.1 && make && sudo make install .../nut $ ./configure --with-usb-include=$HOME/local/libusb-0.1/include --with-usb-libs=-L$HOME/local/libusb-0.1/lib ... (might need slight adjustments) After that, you can verify that the libusb line in "ldd /path/to/usbhid-ups" points to "$HOME/local/..." -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
> What I missed before was that you have both "libusb-0.1.so.4" (from > libusb-compat) and "libusb- > 1.0.so.0" (what libusb-compat calls through to). Uh...is that good? :) Looking at the list of libusb entries from the working (openSUSE 13.1 w/libusb from the ISO) and non-working (openSUSE 13.1 w/libusb from repository), the versions look the same to me, but the hex number following the lib is different. I will give it a go of getting the latest libusb that you linked to me a try, to see if maybe it was some bug introduced that is now resolved, and that way I can at least write my instructions with that directive (to get the latest). -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
I'm making some progress, I think. My normal method of installation was to install openSUSE 13.1, and then after install, use zypper to install the libusb libraries. That, of course, pulls them from the online repository. I believe in the last couple months, that version must have changed. So I just did a fresh install off the ISO image, and this time included the libusb libraries in the install. Coming off of the ISO image, they are certain to be older versions than what can be installed today. And it works!SORT OF. More specifically, I can tell upsdrvctl to shutdown, and it does that. It sends the command to the UPS to shutdown after 20 seconds and then come back up. Awesome. Unfortunately, for some reason, putting that same command into the file that is supposed to be execute automatically upon shutdown isn't working. I'm going to try Roger's alternate "systemd service unit" method to see if it works. Still strange, though, because I had been using the shutdown script method before all this began So if I can get it to reliably shutdown the UPS using the service unit, I'm going to say some new version of libusb is to blame. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Thursday, September 17, 2015 9:13 AM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 15, 2015, at 9:31 PM, Charles Lepple <clep...@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 packages will use the same > libusb-0.1.so* name. I misspoke. The "real libusb" (0.1) and libusb-compat will both get linked with "-lusb". The package management system is free to implement that with symlinks to the actual files. The confusing part is that openSUSE seems to be adopting the 0.1.1x numbering scheme for libusb-compat so that the package looks newer (0.1.13) than the real libusb-0.1.12: https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.spec?expand=1 Note the changes mentioned in the return codes for usb_detach_kernel_driver_np(): https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.changes?expand=1 Those are the sort of edge cases that haven't been fully tested with NUT. It seems like the path from NUT driver through libusb to the kernel is relatively unchanged with libusb-compat, but that mapping the errors back to root cause will depend on the exact version of libusb-compat in use (and potentially, the kernel version as well). I would recommend retesting with an explicit "killall usbhid-ups" (and anything else necessary to stop NUT background services, otherwise it will pop back up) before switching debug flags on. If that fails to turn up anything conclusive, you might try to install libusb-0.1.12 from source in a separate directory, and explicitly point ./configure to that tree: install from http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/ .../libusb-0.1.12 $ ./configure --prefix=$HOME/local/libusb-0.1 && make && sudo make install .../nut $ ./configure --with-usb-include=$HOME/local/libusb-0.1/include --with-usb-libs=-L$HOME/local/libusb-0.1/lib ... (might need slight adjustments) After that, you can verify that the libusb line in "ldd /path/to/usbhid-ups" points to "$HOME/local/..." -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
So far, the systemd service unit is working perfectly. Halleluia! For reference, here are the libs associated with the usbhid-ups driver: rtd@linux-fnda:/etc/init.d> ldd /usr/local/ups/bin/usbhid-ups linux-vdso.so.1 (0x7fffecd25000) libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x7ff3b841b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7ff3b81fd000) libc.so.6 => /lib64/libc.so.6 (0x7ff3b7e4e000) libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x7ff3b7c3e000) /lib64/ld-linux-x86-64.so.2 (0x7ff3b8621000) librt.so.1 => /lib64/librt.so.1 (0x00007ff3b7a36000) Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Thursday, September 17, 2015 9:13 AM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 15, 2015, at 9:31 PM, Charles Lepple <clep...@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 packages will use the same > libusb-0.1.so* name. I misspoke. The "real libusb" (0.1) and libusb-compat will both get linked with "-lusb". The package management system is free to implement that with symlinks to the actual files. The confusing part is that openSUSE seems to be adopting the 0.1.1x numbering scheme for libusb-compat so that the package looks newer (0.1.13) than the real libusb-0.1.12: https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.spec?expand=1 Note the changes mentioned in the return codes for usb_detach_kernel_driver_np(): https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.changes?expand=1 Those are the sort of edge cases that haven't been fully tested with NUT. It seems like the path from NUT driver through libusb to the kernel is relatively unchanged with libusb-compat, but that mapping the errors back to root cause will depend on the exact version of libusb-compat in use (and potentially, the kernel version as well). I would recommend retesting with an explicit "killall usbhid-ups" (and anything else necessary to stop NUT background services, otherwise it will pop back up) before switching debug flags on. If that fails to turn up anything conclusive, you might try to install libusb-0.1.12 from source in a separate directory, and explicitly point ./configure to that tree: install from http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/ .../libusb-0.1.12 $ ./configure --prefix=$HOME/local/libusb-0.1 && make && sudo make install .../nut $ ./configure --with-usb-include=$HOME/local/libusb-0.1/include --with-usb-libs=-L$HOME/local/libusb-0.1/lib ... (might need slight adjustments) After that, you can verify that the libusb line in "ldd /path/to/usbhid-ups" points to "$HOME/local/..." -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
[2a37:5110]: No such file or directory ------ Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Tuesday, September 15, 2015 9:32 PM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 15, 2015, at 5:12 PM, Rob Groner <rgro...@rtd.com> wrote: > > Charles, > > 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 packages will use the same libusb-0.1.so* name. It's not necessarily a problem, but it does mean that there is different code between your driver and the kernel. Most of the NUT testing has been done with the original libusb. > I just thought of something else that has changed since the last time I was > trying this I am now using the "--with-pidpath=/var/run/ups" > configuration parameter to change where everything keeps the pid files. I > wasn't doing that before. Since that's mounted to tmpfs, is it possible > that's getting unmounted before the shutdown command happens (and thus not > finding the .pid file, it tries to start it instead)? You might be on to something, but if so, the race happens earlier than the "usbhid-ups -k" invocation. Because the "-k" flag is meant to be called at the end of the shutdown sequence, it doesn't assume /var is mounted, and consequently, it doesn't check for other PID files. However, if a driver happens to still be running, it could cause the "-k" option to report a busy error. https://github.com/networkupstools/nut/blob/master/drivers/main.c#L588 -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
Ok, just for fun, I tried removing any of the libusb files that had to do with "compatibility". Needless to say, that broke everything in openSUSE. I'm going to reinstall and see if I can selectively install just libusb and not -compat. Or maybe there is an older version of libusb I can install (perhaps it changed recently and that is why things are breaking) We've decided that we need to resolve this issue before we can release the software, as openSUSE is our standard testing distro. If you have any other suggestions of things to try, I'd love to hear them. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Wednesday, September 16, 2015 12:52 PM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 16, 2015, at 11:46 AM, Rob Groner <rgro...@rtd.com> wrote: > I then added - to the commandand then it failed, giving me the same > "Can't claim USB" message. Why does adding the debug commands cause a > problem? It doesn't write a PID file in debug mode: https://github.com/networkupstools/nut/issues/168 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
I just thought of something else that has changed since the last time I was trying this I am now using the "--with-pidpath=/var/run/ups" configuration parameter to change where everything keeps the pid files. I wasn't doing that before. Since that's mounted to tmpfs, is it possible that's getting unmounted before the shutdown command happens (and thus not finding the .pid file, it tries to start it instead)? I think I'm going to try going through the install process solely as root to see if that makes things works reliably. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Thursday, September 10, 2015 9:44 AM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 10, 2015, at 8:49 AM, Rob Groner <rgro...@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, but I'm looking for the device descriptor, which should be available regardless. The version number of your driver says "2.7.2.6_RTD". Which Git revision does that correspond to in the NUT repository (aside from your changes)? I'm curious because somewhere (af5f84c5) between 2.7.2 and 2.7.3, I removed a spurious usb_set_altinterface() call, and I'm wondering if that changes the claim/detach error messages. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
I just tried it with a clean install of Ubuntu 14.04no problems, gives ups shutdown command just like it should. So that's Ubuntu and Porteus: Good! openSUSE: Bad! Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com<http://www.rtd.com/> ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
Charles, 3.16.6.-2-desktop Keep in mind, despite the subject line, that this has been openSUSE 13.2 recently. I had hoped it would work better than 13.1, but so far hasn't. When I was trying with openSUSE 13.1, it was kernel 3.11.6-2-desktop. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com<http://www.rtd.com/> From: Charles Lepple [mailto:clep...@gmail.com] Sent: Wednesday, September 09, 2015 7:08 PM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 9, 2015, at 10:12 AM, Rob Groner <rgro...@rtd.com<mailto:rgro...@rtd.com>> wrote: linux-5048:/home/rtd # ldd /usr/local/ups/bin/usbhid-ups linux-vdso.so.1 (0x7fff403fc000) libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x7f7c34b56000) The last line seems to indicate that it is the real libusb-0.1, not -compat. What kernel version on openSUSE? -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
rtd@linux-5048:~> lsusb -vvv -d 2a37: Bus 001 Device 005: ID 2a37:5110 Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x2a37 idProduct 0x5110 bcdDevice0.03 iManufacturer 1 iProduct2 iSerial 4 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.11 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 503 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 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. Unfortunately, I don't recall much about the git pull, except when you told me how to do it however many months back it was. I pulled it and then went on my merry way modifying it. Is there some way to look in the code/data to see it? Either way, I haven't changed/updated the code since that pull, so if you made the change after that, it hasn't affect me at all. And if you made it before the pull, then I've still been able to successfully use the shutdown command with this code just a few months ago, and today using Porteus. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Thursday, September 10, 2015 9:44 AM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 10, 2015, at 8:49 AM, Rob Groner <rgro...@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, but I'm looking for the device descriptor, which should be available regardless. The version number of your driver says "2.7.2.6_RTD". Which Git revision does that correspond to in the NUT repository (aside from your changes)? I'm curious because somewhere (af5f84c5) between 2.7.2 and 2.7.3, I removed a spurious usb_set_altinterface() call, and I'm wondering if that changes the claim/detach error messages. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
linux-5048:/home/rtd # ldd /usr/local/ups/bin/usbhid-ups linux-vdso.so.1 (0x7fff403fc000) libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x7f7c34b56000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f7c34939000) libc.so.6 => /lib64/libc.so.6 (0x7f7c3459) libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x7f7c34378000) /lib64/ld-linux-x86-64.so.2 (0x7f7c34d7a000) libudev.so.1 => /usr/lib64/libudev.so.1 (0x7f7c34362000) librt.so.1 => /lib64/librt.so.1 (0x7f7c34159000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f7c33f55000) Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com<http://www.rtd.com/> From: Charles Lepple [mailto:clep...@gmail.com] Sent: Wednesday, September 09, 2015 10:05 AM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 9, 2015, at 9:40 AM, Rob Groner <rgro...@rtd.com<mailto:rgro...@rtd.com>> wrote: I'm not sure which USB lib it compiled against. What does this return? ldd /path/to/driver ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
Charles, dmesg doesn't say anything when "usbhid-ups -a rtdups -k" is executed. I'm not sure which USB lib it compiled against. I installed them via "zypper install libusb-*". I'll try to find the version that got installed, as that WOULD be one thing that might have changed since the last time I had this working. I'm not sure how to check for multiple usbhid-ups running (it's not a driver module, so not lsmod, and ps just returns what I am grepping for), but I do not think there are as I've encountered this problem even after a clean reinstall and starting from scratch. I might go try Porteus 3.1 because I got it working fully and easily on that as well "back in the day", and if it fails there too, then maybe my USB implementation on the UPS is off somehow. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Tuesday, September 08, 2015 6:53 PM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 8, 2015, at 4:48 PM, Rob Groner <rgro...@rtd.com> wrote: > > 0.005927Device matches > 0.005940failed to claim USB device: Device or resource busy > 0.005954failed 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 driver (usbhid, etc.) or from another userspace program. The simplest thing is to check for other copies of usbhid-ups (at the point when you run ' -k', it is expected that most processes will have terminated). If it isn't that, you may need to verify whether you are compiling against libusb-0.1.x, or libusb+libusb-compat. In theory, it shouldn't make any difference, but in practice, there might be subtle differences in error messages that could help narrow things down. Also, what does 'dmesg' say around the time that you run the driver? -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
I’ve now installed the package on a brand new Porteus 3.1.0 install, and it works just fine. The shutdown command is in /etc/rc.d/rc.local_shutdown and works so far (though only a few test runs have been executed). I’d still like to pursue what is wrong with openSUSE, as it is a more mainstream distro than Porteus. But I do feel that openSUSE itself is the problem. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com<http://www.rtd.com/> From: Charles Lepple [mailto:clep...@gmail.com] Sent: Wednesday, September 09, 2015 10:05 AM To: Rob Groner <rgro...@rtd.com> Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 9, 2015, at 9:40 AM, Rob Groner <rgro...@rtd.com<mailto:rgro...@rtd.com>> wrote: I'm not sure which USB lib it compiled against. What does this return? ldd /path/to/driver ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
Roger, rtd@linux-5048> sudo /usr/local/ups/bin/usbhid-ups -a rtdups -k -DDD Network UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD) USB communication driver 0.32 0.00 debug level is '3' 0.000405 upsdrv_initups... 0.004386 Checking device (0930/6545) (002/002) 0.004431 Failed to open device, skipping. (Permission denied) 0.004442 Checking device (1D6B/0002) (002/001) 0.004468 Failed to open device, skipping. (Permission denied) 0.004479 Checking device (1D6B/0001) (008/001) 0.004494 Failed to open device, skipping. (Permission denied) 0.004504 Checking device (1D6B/0001) (007/001) 0.004518 Failed to open device, skipping. (Permission denied) 0.004530 Checking device (1D6B/0001) (006/001) 0.004545 Failed to open device, skipping. (Permission denied) 0.004555 Checking device (2A37/5110) (001/005) 0.005862 - VendorID: 2a37 0.005876 - ProductID: 5110 0.005884 - Manufacturer: RTD Embedded Technologies, Inc. 0.005891 - Product: UPS25110 0.005898 - Serial Number: 123456789ABC 0.005906 - Bus: 001 0.005914 Trying to match device 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 0.005964 failed to claim USB device: Device or resource busy 0.005974 failed to detach kernel driver from USB device: No such file or directory 0.005984 failed to claim USB device: Device or resource busy 0.005993 failed to detach kernel driver from USB device: No such file or directory 0.006003 failed to claim USB device: Device or resource busy 0.006013 failed to detach kernel driver from USB device: No such file or directory 0.006023 Can't claim USB device [2a37:5110]: No such file or directory Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Nut-upsuser [mailto:nut-upsuser-bounces+rgroner=rtd@lists.alioth.debian.org] On Behalf Of Roger Price Sent: Tuesday, September 08, 2015 4:25 PM To: nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 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@linux-5048:~> sudo > /usr/local/ups/sbin/upsdrvctl -D shutdown Network UPS Tools - UPS > driver controller 2.7.2.6_RTD ... > 0.000137 Shutdown UPS: rtdups > 0.000160 exec: /usr/local/ups/bin/usbhid-ups -a rtdups -k > Network UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD) USB > communication driver 0.32 Can't claim USB device [2a37:5110]: No such > file or directory > 0.007491 Driver failed to start (exit status=1) > -- > - Hello Bob, What happens if you execute the command /usr/local/ups/bin/usbhid-ups -a rtdups -k -DDD Best Regards, Roger ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
Roger, Ok, I simplified it somewhat. I start all of the NUT services on the command line after boot, to verify they are all starting correctly. They appear to be. Doing this, I found the systemd service unit to somewhat reliably execute the shutdown. I only tried 5 times, but it worked each time which is a fairly significant change from previously. Still...hardly conclusive, and I'd STILL rather use the shutdown script. So I tried executing the shutdown command from the command line as well, and saw the same error that I had gotten from the systemd service unit: --- rtd@linux-5048:~> sudo /usr/local/ups/sbin/upsdrvctl -u ups start root's password: Network UPS Tools - UPS driver controller 2.7.2.6_RTD Network UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD) USB communication driver 0.32 writepid: fopen /var/run/ups/usbhid-ups-rtdups.pid: No such file or directory Using subdriver: RTD UPS HID v1.0 rtd@linux-5048:~> sudo /usr/local/ups/sbin/upsd -u ups Network UPS Tools upsd 2.7.2.6_RTD fopen /var/run/ups/upsd.pid: No such file or directory /usr/local/ups/etc/upsd.conf is world readable listening on 127.0.0.1 port 3493 Connected to UPS [rtdups]: usbhid-ups-rtdups /usr/local/ups/etc/upsd.users is world readable rtd@linux-5048:~> sudo /usr/local/ups/sbin/upsmon -u ups Network UPS Tools upsmon 2.7.2.6_RTD fopen /var/run/ups/upsmon.pid: No such file or directory UPS: rtdups@localhost (master) (power value 1) Using power down flag file /etc/killpower rtd@linux-5048:~> sudo /usr/local/ups/sbin/upsdrvctl shutdown Network UPS Tools - UPS driver controller 2.7.2.6_RTD Network UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD) USB communication driver 0.32 Can't claim USB device [2a37:5110]: No such file or directory Driver failed to start (exit status=1) --- 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@linux-5048:~> sudo /usr/local/ups/sbin/upsdrvctl -D shutdown Network UPS Tools - UPS driver controller 2.7.2.6_RTD 0.00 If you're not a NUT core developer, chances are that you're told to enable debugging to see why a driver isn't working for you. We're sorry for the confusion, but this is the 'upsdrvctl' wrapper, not the driver you're interested in. Below you'll find one or more lines starting with 'exec:' followed by an absolute path to the driver binary and some command line option. This is what the driver starts and you need to copy and paste that line and append the debug flags to that line (less the 'exec:' prefix). 0.000137 Shutdown UPS: rtdups 0.000160 exec: /usr/local/ups/bin/usbhid-ups -a rtdups -k Network UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD) USB communication driver 0.32 Can't claim USB device [2a37:5110]: No such file or directory 0.007491 Driver failed to start (exit status=1) --- I'm sure I'm doing something bone-headed, because this worked just a couple months ago without near this much trouble. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Nut-upsuser [mailto:nut-upsuser-bounces+rgroner=rtd@lists.alioth.debian.org] On Behalf Of Roger Price Sent: Saturday, September 05, 2015 5:13 AM To: nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 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 > 2015-09-04T11:43:38.825970-04:00 linux-5048 upsdrvctl[1887]: Network > UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD) > 2015-09-04T11:43:38.826243-04:00 linux-5048 upsdrvctl[1887]: USB > communication driver 0.32 > 2015-09-04T11:43:38.826934-04:00 linux-5048 upsdrvctl[1887]: Driver > failed to start (exit status=1) > 2015-09-04T11:43:38.827185-04:00 linux-5048 upsdrvctl[1887]: Network > UPS Tools - UPS driver controller 2.7.2.6_RTD I'm confused here - the Bash script, and the systemd service unit, are for _shutting down_ the system on power failure, but in the trace you are having a problem _starting_ the driver. > Is it possible the USB bus is going away before that can execute? I h
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
Roger, 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 2015-09-04T11:43:38.825970-04:00 linux-5048 upsdrvctl[1887]: Network UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD) 2015-09-04T11:43:38.826243-04:00 linux-5048 upsdrvctl[1887]: USB communication driver 0.32 2015-09-04T11:43:38.826934-04:00 linux-5048 upsdrvctl[1887]: Driver failed to start (exit status=1) 2015-09-04T11:43:38.827185-04:00 linux-5048 upsdrvctl[1887]: Network UPS Tools - UPS driver controller 2.7.2.6_RTD Is it possible the USB bus is going away before that can execute? Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Nut-upsuser [mailto:nut-upsuser-bounces+rgroner=rtd@lists.alioth.debian.org] On Behalf Of Roger Price Sent: Friday, September 04, 2015 10:31 AM To: nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 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 systemd for some time. For example SUSE Linux Enterprise Desktop 11 which does not use systemd will be supported until 31 Mar 2019 and SUSE Linux Enterprise Server 11 will be supported until 31 Mar 2022. https://www.suse.com/lifecycle/ > I assume that to undo the systemd service unit method, I do something > like "systemctl --system disable /etc/syst.."? Yes. That will remove the soft link. Best Regards, Roger ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
Roger, Thank you for the help. I tried what you suggested, going the system service unit route. Well...that works. So unfortunately, it doesn't provide a lot of debugging information. But I guess it also gives me a method I can move forward with. 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. The fact that I had the script working perfectly a few months ago makes me suspect this might be an openSUSE bug, and maybe that version I used back then had been updated. Now that I have a working solution, I might let my install update overnight and then try the shutdown script again. I assume that to undo the systemd service unit method, I do something like "systemctl --system disable /etc/syst.."? Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -Original Message- From: Nut-upsuser [mailto:nut-upsuser-bounces+rgroner=rtd@lists.alioth.debian.org] On Behalf Of Roger Price Sent: Thursday, September 03, 2015 11:18 AM To: nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Thu, 3 Sep 2015, Rob Groner wrote: > I’ve followed your excellent guide for setting up NUT in openSUSE > 13.1. I’ve had great luck IN THE PAST, but for some reason now that I > am trying to set it up again from scratch, I’m getting a weird error. > > Everything works except for the UPS shutdown. I put the script in > /usr/lib/system/system-shutdown and made it executable. In fact, if I > execute it manually...it will shut down the UPS (and then bring it > back up). However, if I shut down normally, either the script does > not execute, or the UPS simply fails to receive it. In a previous > system when I did this, it worked perfectly (almost too well, as I’d > sometimes forget when simply rebooting the system that it had > commanded the UPS to shutdown 20 seconds later…). Do you have any > suggestions as to why the script works fine when I execute it > manually, but doesn’t work when the system actually shuts down? Hello Bob, I'll reply via the NUT mailing list since others may be interested, and the list will archive the discussion. Putting the shutdown script in /usr/lib/system/system-shutdown so that systemd will execute it as late as possible makes it difficult to debug what happens, or doesn't happen, since when the script is executed, it is no longer possible to write out any trace statements. So I suggest that temporarily you use the systemd service unit approach which will place a record in /var/log/messages. This is easier to debug. Once you have found out why the required shutdown has not happened, you can test the fix, and when it works go back to using a script in /usr/lib/system/system-shutdown Don't forget that you will have to initialize the service unit with a command such as systemctl --system reenable /etc/systemd/system/ups-delayed-shutdown.service Best Regards, Roger ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsd not starting sometimes (Porteus 3.1, nut 2.7.2)
Correct, Porteus is based on Debian. I'm trying Charles' advice, initially just by making sure the /var/state dir is empty on boot. That's pretty easy to do with Porteus since you can prevent any permanent changes to the file system. Sincerely, Rob Groner Software Engineer RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: 814-234-8087 www.rtd.com -Original Message- From: Nut-upsuser [mailto:nut-upsuser-bounces+rgroner=rtd@lists.alioth.debian.org] On Behalf Of Roger Price Sent: Wednesday, July 08, 2015 4:54 AM To: nut-upsuser Mailing List Subject: Re: [Nut-upsuser] upsd not starting sometimes (Porteus 3.1, nut 2.7.2) On Tue, 7 Jul 2015, Rob Groner wrote: This is being run in Porteus 3.1 with nut 2.7.2. My first thought was that this is more systemd wierdness, but I believe that Porteus is based on Slackware which doesn't use systemd - is that correct? Roger ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsd not starting sometimes (Porteus 3.1, nut 2.7.2)
That seems to have fixed it...I've run it twice now through our tests and no recurrence of the problem. So I'll use the --with-altpidpath configure option to move it to /var/run instead of /var/state. Thanks! Sincerely, Rob Groner Software Engineer RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Tuesday, July 07, 2015 8:25 PM To: Rob Groner Cc: nut-upsuser Mailing List Subject: Re: [Nut-upsuser] upsd not starting sometimes (Porteus 3.1, nut 2.7.2) On Jul 7, 2015, at 4:12 PM, Rob Groner rgro...@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 running! Either stop the previous instance first, or use the 'reload' command. What might be happening is that the PID file is left over from the last test, and another process got that PID instead. Due to history and conflicting requirements, the path selection is not as simple as it could be. From ./configure --help: --with-statepath=PATH path for ups state files (/var/state/ups) --with-altpidpath=PATH path for driver/upsd .pid files (statepath) [...] --with-pidpath=PATH path for .pid files (/var/run) You might not want to use the default for --with-altpidpath: /var/state/* is not generally cleared at boot time, whereas /var/run is either wiped or mounted on a RAM filesystem. However, you might want the statepath protected - Debian uses the following: $ ls -ld /var/run/nut drwxrwx--- 2 root nut 60 Jun 24 17:13 /var/run/nut -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] upsd not starting sometimes (Porteus 3.1, nut 2.7.2)
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 its output, I see that it says : Fatal error: A previous upsd instance is already running! Either stop the previous instance first, or use the 'reload' command. Again note that this only happens SOME of the timeall other times, all 3 things get started that are supposed to (upsdrvctl, upsd, upsmon). Even when upsd fails, the other two services start. This is being run in Porteus 3.1 with nut 2.7.2. I'm calling my script from /etc/rc.d/rc.local. This script contains: #!/bin/sh /usr/local/ups/sbin/upsdrvctl -u ups start sleep 2 /usr/local/ups/sbin/upsd -u ups sleep 2 /usr/local/ups/sbin/upsmon -u ups I checked that upsd wasn't getting started from anywhere else, and I looked in the NUT code to see if I could figure out why it thought upsd was already started, but nothing was obvious. Does anyone have any other suggestions for tracking down why upsd errors out like that sometimes? Sincerely, Rob Groner Software Engineer RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: 814-234-8087 www.rtd.comhttp://www.rtd.com/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Are UPS shutdown commands automatically sent?
Roger, The UPS I'm connected to is one we're actually developing, and I've authored the firmware for it. I have a serial connection to it so I can output messages of interest, and one of those is when the UPS detects that the user has requested the delayed shutdown and restart. So far, every time I've done the upsdrvctl shutdown, I've seen both requests on the screen. But this last time, I only got the request for the delayed shutdown. It is certainly possible I'm doing something wrong in the firmware itself. If it really is just one USB Set Report being sent to the UPS, then that would be almost impossible that just the delayed shutdown got through. I haven't seen it again since then. I'll try some more times and see if I can find something repeatable about it. Sincerely, Robert G. Groner Software Engineer RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: 814-234-8087 www.rtd.com -Original Message- From: Nut-upsuser [mailto:nut-upsuser-bounces+rgroner=rtd@lists.alioth.debian.org] On Behalf Of Roger Price Sent: Wednesday, May 27, 2015 1:37 PM To: nut-upsuser Mailing List Subject: Re: [Nut-upsuser] Are UPS shutdown commands automatically sent? On Wed, 27 May 2015, Rob Groner wrote: 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 to do the delayed shutdown, but *not* the command to do the delayed restart. Hello Robert, This is surprizing. To the best of my knowledge the delayed-shutdown and the delayed-restart commands to the UPS are one single command. What is the symptom that the UPS has not received delayed-restart? Is it that the UPS does not restart? This could be due to something else. Best Regards, Roger ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] 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 to do the delayed shutdown, but *not* the command to do the delayed restart. While that's not a critical failure, it would be if the UPS doesn't get the delayed shutdown command instead. I'm wondering if the system (openSUSE ) died before that particular command could be sent over USB to the UPS. Sincerely, Robert G. Groner Software Engineer RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: 814-234-8087 www.rtd.com -Original Message- From: Nut-upsuser [mailto:nut-upsuser-bounces+rgroner=rtd@lists.alioth.debian.org] On Behalf Of Roger Price Sent: Saturday, May 23, 2015 6:02 AM To: nut-upsuser Mailing List Subject: Re: [Nut-upsuser] Are UPS shutdown commands automatically sent? 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 shutting down, including rebooting? So, if I choose to reboot my system, I would most likely see the UPS shutoff and then turn back on, somewhere in the middle of my system booting back up. Hello Robert, The command /sbin/shutdown -r used to reboot the box is incompatible with a UPS which receives a delayed shutdown order. If you have offdelay = 30 in /etc/ups/ups.conf, then 30 seconds after the upsdrvctl shutdown, when the box has now probably restarted, the UPS will shutdown with total loss of power to the box. Not good. I can think of a couple solutions: 1) Have the script verify that the UPS is actually in a OB state before giving the shutdown command. That should prevent unintended UPS power cycles when simply rebooting the system. 2) Have the UPS itself not respect any load.off.delay or similar commands when it is online. This adds complexity, and in a critical system component simplicity is a virtue. To reboot my box, I turn off the wall power and wait until I hear the clunk as the shutdown relay operates in the UPS. I then turn the wall power back on. Looking over UPS documentation and various helps, it seems most people would expect their UPS to turn the load off and then back on, even if it has wall power the entire time. That would facilitate testing at a minimum. So I'm guessing option #2 isn't a good one. If you have decided to use a UPS capable of shutting down and restarting when wall power comes back, then you have to respect the UPS cycle. You can't pretend it isn't there. Best regards, Roger ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Are UPS shutdown commands automatically sent?
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 and AS9100 Certified Ph: 814-234-8087 www.rtd.com -Original Message- From: Roger Price [mailto:ro...@rogerprice.org] Sent: Thursday, May 21, 2015 3:59 PM To: Rob Groner Subject: Re: [Nut-upsuser] Are UPS shutdown commands automatically sent? On Thu, 21 May 2015, Rob Groner wrote: 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 can’t find that, nor can I find any clear instructions on where I would put the commands to tell the UPS to start its shutdown and restart timers. Hi, I went through the same learning curve. I wrote up my notes at http://rogerprice.org/NUT.html Perhaps there is something there that could help you. Best Regards, Roger ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Are UPS shutdown commands automatically sent?
I'm testing that my system will shutdown when the UPS has been on battery for 10 seconds. That all works fine10 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 can't find that, nor can I find any clear instructions on where I would put the commands to tell the UPS to start its shutdown and restart timers. Sincerely, Robert G. Groner Software Engineer RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: 814-234-8087 www.rtd.comhttp://www.rtd.com/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with NUT 2.7.2 on CentOS 7 and using the Mini-Box OpenUPS
The documentation isn't explicit about this, but 'upsdrvctl shutdown' is meant to be run after all of the other processes on the system have been killed, real filesystems have been unmounted, and the kernel shutdown syscall is about to be called. Usually the init scripts will take care of this, although I don't know how CentOS handles that specifically. If you want to test the low-battery shutdown procedure (where upsmon tells the rest of the system to shut down, then tells the UPS to power off), you can run 'upsmon -c fsd' (Forced ShutDown). The init scripts should call 'upsdrvctl shutdown' implicitly when everything else has stopped. I wish it were explicit. :) You say to use FSD for testing the system...what do I use for real? I thought I was supposed to call upsdrvctl shutdown with some delay, and THEN begin shutting down my PC, in the hopes I finish before the delay expires and the UPS shuts off of the power supply. When you say the init scripts will take care of this, do you mean that if I execute a system shutdown, it will automatically send the upsdrvctl shutdown command at the end? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] building from git (was Re: Install problems (group permissions) with nut 2.7.2)
Ok, that worked great. I make a .tar, took it somewhere else, untarred it, configured, and built. Then I installed the result and ran it, and it shows 2.7.2.6_RTD for a version number. Awesome! Today I work on commands to tell the UPS to turn off...fun! Sincerely, Rob Groner Software Engineer RTD Embedded Technologies, Inc. ISO9001 and AS9100 Certified Ph: 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Tuesday, March 10, 2015 7:48 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] building from git (was Re: Install problems (group permissions) with nut 2.7.2) On Mar 10, 2015, at 11:20 AM, Rob Groner rgro...@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 never finished the cleanup of that code, I guess. If you build and install from the Git tree, it generates a version based on the latest tag in Git. The tarball generated from 'make dist' uses the version in configure.ac, but only if you build it outside of the Git working directory. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
It's arbitrary to me what version I start from, I had just grabbed the latest 2.7.2 tar. How do I get the version that you suggest I start from? git clone? Or do I just change the .tar file I have with what you linked (changes the 52-* file to 62-*) Sincerely, Rob Groner -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Monday, March 09, 2015 8:48 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 On Mar 9, 2015, at 12:00 PM, Rob Groner rgro...@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 script. I think it typically runs it as well, but often you would re-run it with --prefix= or other arguments (such as -- with-drivers=usbhid-ups to cut down on compilation time). It occurred to me that your driver will be introducing new USB VID:PID entries, so this is something else that autogen.sh does: it rebuilds the udev files that change permissions when the UPS gets plugged in. I mentioned pulling in a copy of autogen.sh earlier, and I'm not sure what other developer-only scripts are left out of the tarball. We really only heavily test two cases: building from Git, and building from a clean tarball. Small patches to the tarball are easy; structural changes like adding files are harder to guarantee that they will work. That, plus the fact that 2.7.2 still has the old prefix number on the udev files, means you might be better off starting from the latest Git version of NUT, or at least including the following patch: https://github.com/networkupstools/nut/commit/040c800efad46ead967007 7c9764360802d7aaf5 Reference: https://github.com/networkupstools/nut/issues/140 -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
Sorry for the bad formatting of the previous message...I tried to use plus signs as bullet points, and that caused a problem somehow. Ok...I discovered that if I do the autoreconf after the first failed make (and the autoreconf still gives that error message), and then do make again...it builds. Conclusions: 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. 2) Autoreconf appears to do what it needs to do, even though it shows and error and says it exited. Sincerely, Rob Groner -Original Message- From: Nut-upsuser [mailto:nut-upsuser- bounces+rgroner=rtd@lists.alioth.debian.org] On Behalf Of Rob Groner Sent: Monday, March 09, 2015 11:49 AM To: 'nut-upsuser List' Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 Ok, I tried this from scratch on a fresh 2.7.2 directory. I followed the web instructions, specifically: + I generated the new subdriver for my UPS (rtd-hid.*) based on PATH info. + I put them in the drivers subdir + I added the include line (#include rtd-hid.h) in usbhid-ups.c + (specifically in the #ifndef SHUT_MODE section) I added + rtd_subdriver, to the subdriver_list in usbhid-ups.c (specifically + in the #ifndef SHUT_MODE section) I added rtd-hid.c to + USBHID_UPS_SUBDRIVERS in drivers/Makefile.am I added rtd-hid.h to + dist_noinst_HEADERS in drivers/Makefile.am I executed ./configure + --with-usb --with-dev --etc --etc I execute make, and I get an error: /bin/sh ../libtool --tag=CC --mode=link gcc -I../include -g -O2 -Wall - Wsign-compare -o usbhid-ups usbhid-ups.o libhid.o libusb.o hidparser.o usb-common.o apc-hid.o belkin-hid.o cps-hid.o explore-hid.o liebert-hid.o mge-hid.o powercom-hid.o tripplite-hid.o idowell-hid.o openups-hid.o ../common/libcommon.la ../common/libparseconf.la main.o dstate.o -lusb - lpthread libtool: link: gcc -I../include -g -O2 -Wall -Wsign-compare -o usbhid-ups usbhid-ups.o libhid.o libusb.o hidparser.o usb-common.o apc-hid.o belkin- hid.o cps-hid.o explore-hid.o liebert-hid.o mge-hid.o powercom-hid.o tripplite-hid.o idowell-hid.o openups-hid.o main.o dstate.o ../common/.libs/libcommon.a ../common/.libs/libparseconf.a -lusb -lpthread usbhid-ups.o:(.rodata+0x110): undefined reference to `rtd_subdriver' collect2: error: ld returned 1 exit status make[1]: *** [usbhid-ups] Error 1 make[1]: Leaving directory `/home/rtd/nut-2.7.2/drivers' I can see that somehow, somewhere, my rtd-hid.o isn't being included in that list. I followed the same process again, but this time tried autoreconf instead of configure (I had already run ./configure once). That gave me an error message that I do not believe is related to my driver: Parallel-tests: error: required file './test-driver' not found Parallel-tests: 'automake --add-missing' can install 'test-driver' Autoreconf: automake failed with exit status 1 Sincerely, Rob Groner -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Monday, March 02, 2015 8:27 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 On Mar 2, 2015, at 12:49 PM, Rob Groner rgro...@rtd.com wrote: Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid driver, I'll revisit writing our own. I'll take this as a TODO item to make it clearer, but for later the basic information is here: http://www.networkupstools.org/docs/developer- guide.chunked/ar01s04.html#_writing_a_subdriver You must also add the subdriver to USBHID_UPS_SUBDRIVERS in drivers/Makefile.am and call autoreconf and/or ./configure from the top level NUT directory. To run autoreconf, you need automake, autoconf and libtool. automake turns Makefile.am into Makefile.in, and the ./configure script converts Makefile.in to the Makefile. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
Ok, I tried this from scratch on a fresh 2.7.2 directory. I followed the web instructions, specifically: + I generated the new subdriver for my UPS (rtd-hid.*) based on PATH info. + I put them in the drivers subdir + I added the include line (#include rtd-hid.h) in usbhid-ups.c (specifically in the #ifndef SHUT_MODE section) + I added rtd_subdriver, to the subdriver_list in usbhid-ups.c (specifically in the #ifndef SHUT_MODE section) + I added rtd-hid.c to USBHID_UPS_SUBDRIVERS in drivers/Makefile.am + I added rtd-hid.h to dist_noinst_HEADERS in drivers/Makefile.am + I executed ./configure --with-usb --with-dev --etc --etc I execute make, and I get an error: /bin/sh ../libtool --tag=CC --mode=link gcc -I../include -g -O2 -Wall -Wsign-compare -o usbhid-ups usbhid-ups.o libhid.o libusb.o hidparser.o usb-common.o apc-hid.o belkin-hid.o cps-hid.o explore-hid.o liebert-hid.o mge-hid.o powercom-hid.o tripplite-hid.o idowell-hid.o openups-hid.o ../common/libcommon.la ../common/libparseconf.la main.o dstate.o -lusb -lpthread libtool: link: gcc -I../include -g -O2 -Wall -Wsign-compare -o usbhid-ups usbhid-ups.o libhid.o libusb.o hidparser.o usb-common.o apc-hid.o belkin-hid.o cps-hid.o explore-hid.o liebert-hid.o mge-hid.o powercom-hid.o tripplite-hid.o idowell-hid.o openups-hid.o main.o dstate.o ../common/.libs/libcommon.a ../common/.libs/libparseconf.a -lusb -lpthread usbhid-ups.o:(.rodata+0x110): undefined reference to `rtd_subdriver' collect2: error: ld returned 1 exit status make[1]: *** [usbhid-ups] Error 1 make[1]: Leaving directory `/home/rtd/nut-2.7.2/drivers' I can see that somehow, somewhere, my rtd-hid.o isn't being included in that list. I followed the same process again, but this time tried autoreconf instead of configure (I had already run ./configure once). That gave me an error message that I do not believe is related to my driver: Parallel-tests: error: required file './test-driver' not found Parallel-tests: 'automake --add-missing' can install 'test-driver' Autoreconf: automake failed with exit status 1 Sincerely, Rob Groner -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Monday, March 02, 2015 8:27 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 On Mar 2, 2015, at 12:49 PM, Rob Groner rgro...@rtd.com wrote: Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid driver, I'll revisit writing our own. I'll take this as a TODO item to make it clearer, but for later the basic information is here: http://www.networkupstools.org/docs/developer- guide.chunked/ar01s04.html#_writing_a_subdriver You must also add the subdriver to USBHID_UPS_SUBDRIVERS in drivers/Makefile.am and call autoreconf and/or ./configure from the top level NUT directory. To run autoreconf, you need automake, autoconf and libtool. automake turns Makefile.am into Makefile.in, and the ./configure script converts Makefile.in to the Makefile. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
My fault, I neglected to re-read the developers guide. I had just taken the openups-usb.* and copied them, and then copied all their entries in various makefiles and changed them to match my files instead. That wasn't enough, apparently. I'll try following the guide verbatim instead and see how well that works for me. Sincerely, Rob Groner -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Monday, March 02, 2015 8:27 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 On Mar 2, 2015, at 12:49 PM, Rob Groner rgro...@rtd.com wrote: Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid driver, I'll revisit writing our own. I'll take this as a TODO item to make it clearer, but for later the basic information is here: http://www.networkupstools.org/docs/developer- guide.chunked/ar01s04.html#_writing_a_subdriver You must also add the subdriver to USBHID_UPS_SUBDRIVERS in drivers/Makefile.am and call autoreconf and/or ./configure from the top level NUT directory. To run autoreconf, you need automake, autoconf and libtool. automake turns Makefile.am into Makefile.in, and the ./configure script converts Makefile.in to the Makefile. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid driver, I'll revisit writing our own. Thanks for the helps. Sincerely, Rob Groner -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Wednesday, February 25, 2015 8:10 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 On Feb 25, 2015, at 11:35 AM, Rob Groner rgro...@rtd.com wrote: The quickest way to get my UPS running with nut (as the current release exists) is to either: 1) Add my vendor and device ID to the openups_usb_device_table OR 2) Create my own driver file, and then add that driver to the usbhid-ups subdriver_list And then recompile/install. Correct. For posterity, here's the discussion thread from last March: http://article.gmane.org/gmane.comp.monitoring.nut.devel/6669 I may not have been clear then, but the changes to the driver/*.c files will definitely require a recompile/install of at least the usbhid-ups driver. If you are looking for something more turnkey, you may want to consider building packages for a few of the common distributions. It has been on my TODO list for some time to gather the instructions on how to do this from all of the various mailing list posts, but the information is out there. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
Ok, so please correct me if I’m wrong…. The quickest way to get my UPS running with nut (as the current release exists) is to either: 1) Add my vendor and device ID to the openups_usb_device_table OR 2) Create my own driver file, and then add that driver to the usbhid-ups subdriver_list And then recompile/install. Obviously #1 will be easier at this point, but I understand that it will only get me the functionality that currently exists in the openups driver (which is ok, I structured my USB reports around what that driver makes available). If I want full functionality I’ll need to eventually make my own driver file. Sincerely, Rob Groner From: Charles Lepple [mailto:clep...@gmail.com] Sent: Friday, February 20, 2015 7:50 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 On Feb 20, 2015, at 3:15 PM, Rob Groner rgro...@rtd.commailto:rgro...@rtd.com wrote: Instead, it seems that the usbhid-ups driver will search through its own list of known devices with vid/pid, and won't match my device unless that device exists as an entry in its device table. Is that correct? More or less, yes. It turns out that UPS vendors all have somewhat different interpretations of the PDC spec. There was an idea to create a generic fallback driver that could talk to any USB HID PDC device: https://github.com/networkupstools/nut/issues/112 But at the moment, when we suggest passing the 'productid = ' parameter to usbhid-ups, it is because there is already a set of tables for that vendor, and their model is not all that different from earlier models. The nutdrv_qx driver might be more flexible in this regard, since we tend to see different VID:PID combinations for devices that all speak one of several easily identifiable dialects of the Megatec Q* protocols. - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
Charles, Success! But also curious. I renamed the 52-* file to 62-*, rebooted, confirmed that the USB device created when I plugged in the UPS had a group of nut (it does), and then started the upsdrvctrl as user ups, without -u root. Yay, that's all a first! However, I then went back and renamed the 62-* file back to 52-*, just to check, rebooted, etcand it still works. So I think I was doing something else wrong in the process, and it wasn't necessarily the fact it was named 52-*. For now, however, it works just great! Now to once again confirm it shuts my system down when it should... And I'll be happy to add our UPS info to the correct nut files when it is all done and working, which looks to be around late April. Thanks! Sincerely, Rob Groner -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Thursday, February 19, 2015 10:12 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 On Feb 19, 2015, at 8:43 AM, Rob Groner rgro...@rtd.com wrote: I followed the log messages and found where it had created the udev rule...as Charles said, in /lib/udev/rules.d. It is named 52-nut- and there is nothing else that starts with 52 in /lib/udev/rules.d or /etc/udev/rules.d. My apologies, I got that backwards in my earlier email. udev applies the rules in numerical sequence, so 62 overrides 52. The file should be renamed to 62- nut... to take effect. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
I think I had a misconception about something..
My goal was that someone could use our UPS with the default UPS driver in NUT
right out of the box, so they wouldn't have to alter any NUT code to get it
working. NUT config files, yes, but not NUT code.
I thought that if I put in the ups.conf file that I wanted to use the
usbhid-ups driver, and then put our vendor and product ID, it would find
whatever USB device matched those vid and pid, and then use the usbhid-ups
driver with it.
Instead, it seems that the usbhid-ups driver will search through its own list
of known devices with vid/pid, and won't match my device unless that device
exists as an entry in its device table. Is that correct?
In other words, instead of the ups.conf file saying Use usbhid-ups with USB
device of vid/pid, it is saying Use usbhid-ups with USB device of vid/pid
*if* they are in the list of devices for usbhid-ups?
Sincerely,
Rob Groner
-Original Message-
From: Charles Lepple [mailto:clep...@gmail.com]
Sent: Thursday, February 19, 2015 10:09 PM
To: Rob Groner
Cc: nut-upsuser List
Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut
2.7.2
On Feb 19, 2015, at 8:43 AM, Rob Groner rgro...@rtd.com wrote:
I looked at the file and saw how it was laid out...basically an ATTR for
every
known USB UPS. Well, since mine is not a known UPS, I had to add my own
entry.
If you want, once things are working, we can add an entry to that table (via
drivers/usbhid-ups.c, which gets parsed into the udev script)
So I added a similar entry to all the others, but putting in my USB vendor
and product IDs and setting GROUP=nut (like all the other entries do).
ATTR{idVendor}==04d8, ATTR{idProduct}==005c, MODE=664,
GROUP=nut
You might need to tell udev to reload, although newer versions seem to re-
read the rules files automatically.
Also, I think there is a debug mode for udev that will show what is being
parsed when.
But so far as I can tell, when I plug in the USB cable from the UPS...it is
still
not setting it to nut group permissions. I am looking at the file in
/dev/usb/hid/hiddev0 (which goes away when I unplug the UPS). Either
way, upsdrvctrl still won't start unless I add -u root.
/dev/bus/usb/*/* is the place to look (the hiddev* nodes are not used by
libusb). Once the permissions there look correct, can you post the output of
running the driver directly with -D?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
Thank you all for the help!
I followed the log messages and found where it had created the udev rule...as
Charles said, in /lib/udev/rules.d. It is named 52-nut- and there is
nothing else that starts with 52 in /lib/udev/rules.d or /etc/udev/rules.d.
I looked at the file and saw how it was laid out...basically an ATTR for every
known USB UPS. Well, since mine is not a known UPS, I had to add my own entry.
So I added a similar entry to all the others, but putting in my USB vendor and
product IDs and setting GROUP=nut (like all the other entries do).
ATTR{idVendor}==04d8, ATTR{idProduct}==005c, MODE=664, GROUP=nut
But so far as I can tell, when I plug in the USB cable from the UPS...it is
still not setting it to nut group permissions. I am looking at the file in
/dev/usb/hid/hiddev0 (which goes away when I unplug the UPS). Either way,
upsdrvctrl still won't start unless I add -u root.
So I think my udev rule is simply not taking somehow.
Sincerely,
Rob Groner
-Original Message-
From: Charles Lepple [mailto:clep...@gmail.com]
Sent: Wednesday, February 18, 2015 8:11 PM
To: Rob Groner
Cc: nut-upsuser List
Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut
2.7.2
On Feb 18, 2015, at 10:40 AM, Rob Groner rgro...@rtd.com wrote:
Does this revolve around hotplug and udev?
Yes. (Well, technically hotplug was superseded by udev)
In other words, is the idea that the created USB device will be in the
nut
group,
Yes.
and thus I'd be able to tell upsdrvctrl to start if I am user ups? Or do
ups/nut not really play into any of this?
The usual startup procedure is to run upsdrvctl as root (such as in a login
script). It will automatically drop the driver to ups/nut.
However, as you mentioned, that requires udev. I don't have an opensuse
system, and the broadband connection is down, so I'm not exactly sure what
you need to do there. On recent Debian and Ubuntu with 2.7.2 and earlier,
there was an issue where the udev rules file needed to be renamed from 62-
nut* to 52-nut* in order to not be overridden by another set of rules. It
lives
somewhere like /lib/udev/rules.d
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
Actually, nevermindI found an easier way. This guide is simply going to be the quick way to prove the UPS works, and doing it securely will be an exercise left to the user. As long as I put that in bold letters at the top of the guide, then I don't have a problem just using -u root everywhere. Rob -Original Message- From: Rob Groner Sent: Wednesday, February 18, 2015 10:40 AM To: 'Charles Lepple' Cc: 'nut-upsuser List' Subject: RE: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 Hmmm...well, let's put it this way. I'm trying to do the right thing in regards to permissions and access for running NUT and everything involved with it. I note in the installation instructions it says that if you're impatient and want to try starting upsd, upsmon, and drivers right now, you can use -u root, but that you should set the correct permissions later! I don't fully understand what the correct permissions are, but I had assumed that it was the reason I had created ups/nut at the beginning. If adding -u root to each command is bad security policy, then I'd like to make sure I use a better method. I've setup NUT several times, and tried following the directions each time, but no matter what I did...I could not get upsdrvctrl to successfully start unless I add -u root to it (even if I am root when executing the start command). The directions don't indicate to do that, so I've always figured I have permissions incorrect somewhere. Now I'm finally at the point where I need to get this right. Does this revolve around hotplug and udev? In other words, is the idea that the created USB device will be in the nut group, and thus I'd be able to tell upsdrvctrl to start if I am user ups? Or do ups/nut not really play into any of this? Rob -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Tuesday, February 17, 2015 7:26 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 On Feb 17, 2015, at 4:37 PM, Rob Groner rgro...@rtd.com wrote: I had thought that giving the user and the group would mean that the /usr/local/ups/* directories and binaries created by make install would have nut as their group, but they don'tthey have only root:root. Does the group permissions not get set in these directories upon install? I thought that was the point of creating the user and group in the beginning. If you want to lock down the binaries to only be readable/executable by NUT, you could do that with the group permissions, but since the source code to NUT is available, I'm not sure what that buys you (unless you are applying additional transformations on the binaries after installation). The restricted user/group IDs are primarily to limit the amount of damage that can be done if someone finds a bug in upsd, upsmon or the driver. These programs give up root permissions (with the exception of the upsmon parent, which calls shutdown), so these are the user/group settings that they will use by default. Also, since the NUT user/group typically does not have write access to USB nodes, we recommend using udev rules to set the permissions for NUT, which has the side effect of preventing other non-root processes from meddling with the UPS. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2
Hmmm...well, let's put it this way. I'm trying to do the right thing in regards to permissions and access for running NUT and everything involved with it. I note in the installation instructions it says that if you're impatient and want to try starting upsd, upsmon, and drivers right now, you can use -u root, but that you should set the correct permissions later! I don't fully understand what the correct permissions are, but I had assumed that it was the reason I had created ups/nut at the beginning. If adding -u root to each command is bad security policy, then I'd like to make sure I use a better method. I've setup NUT several times, and tried following the directions each time, but no matter what I did...I could not get upsdrvctrl to successfully start unless I add -u root to it (even if I am root when executing the start command). The directions don't indicate to do that, so I've always figured I have permissions incorrect somewhere. Now I'm finally at the point where I need to get this right. Does this revolve around hotplug and udev? In other words, is the idea that the created USB device will be in the nut group, and thus I'd be able to tell upsdrvctrl to start if I am user ups? Or do ups/nut not really play into any of this? Rob -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Tuesday, February 17, 2015 7:26 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2 On Feb 17, 2015, at 4:37 PM, Rob Groner rgro...@rtd.com wrote: I had thought that giving the user and the group would mean that the /usr/local/ups/* directories and binaries created by make install would have nut as their group, but they don'tthey have only root:root. Does the group permissions not get set in these directories upon install? I thought that was the point of creating the user and group in the beginning. If you want to lock down the binaries to only be readable/executable by NUT, you could do that with the group permissions, but since the source code to NUT is available, I'm not sure what that buys you (unless you are applying additional transformations on the binaries after installation). The restricted user/group IDs are primarily to limit the amount of damage that can be done if someone finds a bug in upsd, upsmon or the driver. These programs give up root permissions (with the exception of the upsmon parent, which calls shutdown), so these are the user/group settings that they will use by default. Also, since the NUT user/group typically does not have write access to USB nodes, we recommend using udev rules to set the permissions for NUT, which has the side effect of preventing other non-root processes from meddling with the UPS. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Install problems (group permissions) with nut 2.7.2
I am attempting to do a from-scratch install of nut into openSUSE 13.1 so I can document the steps a customer will need to follow to make nut work with our UPS. I'm running into the problem I have always run into, which is permissions. I have created the user ups and the group nut and made ups a member of that group. I executed: ./configure --with-user=ups --with-group=nut --with-usb --with-dev Looking at the output, I see that it does recognize that I put a user and group into the command line arg. Doing a grep for the user and group, I see that it is present in many places as RUN_AS_USER = ups and RUN_AS_GROUP = nut I then executed a make, and sudo make install. I had thought that giving the user and the group would mean that the /usr/local/ups/* directories and binaries created by make install would have nut as their group, but they don'tthey have only root:root. Does the group permissions not get set in these directories upon install? I thought that was the point of creating the user and group in the beginning. Thank you, Rob Groner ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] How do I disable messages from upsmon?
Excellent, thank you! -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Thursday, September 11, 2014 10:20 PM To: Rob Groner Cc: nut-upsuser@lists.alioth.debian.org Subject: Re: [Nut-upsuser] How do I disable messages from upsmon? On Sep 11, 2014, at 10:38 AM, Rob Groner rgro...@rtd.com wrote: I'm still getting the onbattery, online, comm good, comm bad, etc system messages. Clearly there is some default behavior going on. How do I keep these system messages from happening? From http://www.networkupstools.org/docs/man/upsmon.conf.html: NOTIFYFLAG type flag[+flag][+flag]... By default, upsmon sends walls global messages to all logged in users) via /bin/wall and writes to the syslog when things happen. You can change this. To suppress just the on-battery/online messages: NOTIFYFLAG ONLINE IGNORE NOTIFYFLAG ONBATT IGNORE The full list is just above NOTIFYFLAG in the upsmon.conf documentation. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] How do I disable messages from upsmon?
I've followed the config setup docs and also the excellent guide from Roger Price. I'm using openSUSE 13.1 and built NUT 2.7.2 from the sources (latest stable). I'm hooked up to a dummy UPS that basically just cycles from fully charged down to about 20% discharged. I was pleased when I started seeing the messages on my screen indicating the UPS was online or on-battery. Given how often the unit cycles, however (about every 30 seconds), it was quickly annoying to get the system messages, so I went into the upsmon.conf file and commented out the online and onbatt NOTIFYFLAG messages. I then did a reload of upsmon...but found I was still getting the messages. Long story short, my upsmon.conf file now consists of a single entry: MONITOR rtdups@localhost 1 upsmaster sekret master I'm still getting the onbattery, online, comm good, comm bad, etc system messages. Clearly there is some default behavior going on. How do I keep these system messages from happening? Thanks Rob ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Documentation out of date?
2) The Starting the driver section says to start the driver at /usr/local/ups/sbin/upsdrvctl , but it's actually located at /usr/lib/ups/driver/ Right, that was fixed post-2.6 (note that the web pages are all tagged with the version they correspond to; currently 2.7.2) I can't see on the webpages where it refers to being about version 2.7.2. Is this tagging in the html itself? My fault, the version is only included in the website pages, e.g. http://www.networkupstools.org/documentation.html https://github.com/networkupstools/nut/issues/150 3) Under Installation Instructions, under State path creation, it says to create the directories and make them owned by the user you created. It shows chown root:nut /var/state/ups, but shouldn't it be chown ups:nut /var/state/ups (I know any user/group can be used, but ups:nut is what the example had been using so far). Assuming this is true: Be sure the new user is a member of the new group! If you forget to do this, you will have problems later on when you try to start upsd. and the mode is 0770, then the NUT user can access those directories, and change the contents, but cannot change the directory itself. Ok, that makes sense, but then maybe the wording should be owned by the group instead of user? Then there wouldn't be confusion between what it says to do and the command to do it. Makes sense. Also added to the TODO list: https://github.com/networkupstools/nut/issues/151 Just thought I would mention them. If those paths are distro/package dependent, then that is ok, but it'd be nice of the docs said that. I know elsewhere they do (when talking about installing from source). Seems like a good idea in principle. How would you reword it? Well, since the paths really become important when dealing with the configuration, perhaps at the top of page 6, under the Note already there, it could just be said that the paths to the configuration files are distribution dependent, and the ones shown are for insert distro used here. That way, whether someone's coming from the package install or source install, they would both end up at the top of that page and get the note before they start seeing the specific paths. When you say Page 6, are you referring to a PDF? Or a sub-section in Configuration? Sorry... The web pages, where you're sent when you click the NUT Configuration link. 6. Configuration Notes (ar01s06.html) Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Documentation out of date?
openSUSE 13.1 installed via zypper (zypper install nut-classic) nut 2.6.? I'm attempting to go through the installation and configuration process on a new system (openSUSE 13.1 in this case), so I'm following the web page docs, but I'm seeing discrepencies: 1) After installing from packages, the configuration sections says that the ups.conf file is in /usr/local/ups/etc/, but it's actually in /etc/ups. 2) The Starting the driver section says to start the driver at /usr/local/ups/sbin/upsdrvctl , but it's actually located at /usr/lib/ups/driver/ 3) Under Installation Instructions, under State path creation, it says to create the directories and make them owned by the user you created. It shows chown root:nut /var/state/ups, but shouldn't it be chown ups:nut /var/state/ups (I know any user/group can be used, but ups:nut is what the example had been using so far). Just thought I would mention them. If those paths are distro/package dependent, then that is ok, but it'd be nice of the docs said that. I know elsewhere they do (when talking about installing from source). Rob ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
