Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Rob Groner]

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

[Rob Groner]

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

[Tim Dawson]

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, since there are many, and syntax is 
not compatible. Without it, the shell already running will try to run the 
script, which may well bomb, or no shell could be loaded at all.

- Tim

On September 24, 2015 7:52:31 AM CDT, Rob Groner <rgro...@rtd.com> wrote:
>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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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 Lepple]

On Sep 24, 2015, at 12:20 PM, Tim Dawson  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.

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

[Rob Groner]

>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

[Rob Groner]

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

[Tim Dawson]

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

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Rob Groner]

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 Dawson]

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

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



--

Tim Dawson (tadaw...@tpcsvc.com)Owner/Engineer
TPC ServicesBellnet: (972)-221-7385
Lewisville, Texas 75067
"Gaff Tape can't fix 'Stupid', but it can muffle the sound..."

___
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

[Rob Groner]

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

[Tim Dawson]

Unless Nut is hard coding the path of what it found in the binary (which 
is not common), it may be runtime linking the wrong version, especially 
if 'ldconfig -p' is not showing the new one.  What does the "ldd" 
command show that the binaries in question are linking with?


That's one of the things that can be great (not)fun in cases like this 
where multiple libs share the same name, and version/number management 
is screwy . . . I've seen cases where the linker thinks the old lib is 
newer, and proceeds to grab the wrong one . . . and also, note that what 
the build system found and build with the headers for, etc. may well not 
be what the dynamic linker is trying to run the program with . . . . 
which can get, well, interesting . . . .


- Tim


On 09/22/2015 04:21 PM, Rob Groner wrote:

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 tha

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Charles Lepple]

On Sep 22, 2015, at 3:47 PM, Rob Groner  wrote:

> So, here is what I think I know:
> 
> NUT is using the libusb-1.0.20 library, by way of the libusb-compat layer.  
> When I check the configure log, it says "libusb-0.1.12"  I'm not sure why it 
> says that, as in where it gets that value, as that version doesn't correspond 
> to anything I installed.  I 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.

This is the crux of the libusb-1.0 problem for NUT: a lot of time has been 
spent making things work with libusb-0.1 and the kernel, and now, instead of 
three moving pieces, we have four (counting NUT itself, with the addition of 
libusb-compat in the middle).

> 
> ./configure --with-usb --with-dev --with-usb-includes=-I/usr/local/include 
> --with-usb-libs=-L/usr/local/lib64

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).

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

[Rob Groner]

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

[Charles Lepple]

On Sep 21, 2015, at 9:39 AM, Rob Groner  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

[Rob Groner]

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

[Charles Lepple]

On Sep 18, 2015, at 2:45 PM, Rob Groner  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




___
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

[Rob Groner]

>  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

[Rob Groner]

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

[Charles Lepple]

On Sep 15, 2015, at 9:31 PM, Charles Lepple  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

[Rob Groner]

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 (0x7ff3b7a36000)


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

[Charles Lepple]

On Sep 17, 2015, at 10:56 AM, Rob Groner  wrote:
> 
> So far, the systemd service unit is working perfectly.  Halleluia!

Good news!

> 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 (0x7ff3b7a36000)

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).

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

[Rob Groner]

[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

[Charles Lepple]

On Sep 16, 2015, at 11:46 AM, Rob Groner  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

[Rob Groner]

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

[Charles Lepple]

On Sep 15, 2015, at 5:12 PM, Rob Groner  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

[Rob Groner]

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

[Rob Groner]

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

___
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 Lepple]

On Sep 10, 2015, at 8:49 AM, Rob Groner  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

[Rob Groner]

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

[Rob Groner]

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

[Charles Lepple]

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

Not a big deal, in this case. I was just looking for the device/configuration 
descriptors, and things look reasonable.

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

If it is still the same directory (with the .git metadata directory at the top 
level), you can say "git show".

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

[Charles Lepple]

On Sep 9, 2015, at 9:40 AM, Rob Groner  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

[Rob Groner]

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 (0x7f7c33f55000)


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

[Rob Groner]

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

[Charles Lepple]

> On Sep 9, 2015, at 10:12 AM, Rob Groner  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

[Rob Groner]

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 Price]

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

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Rob Groner]

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 Price]

On Tue, 8 Sep 2015, Rob Groner wrote:


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


Hello Bob, I'm not an expert in usbhid-ups: perhaps someone else on this
list can explain what's happening at 0.005940.  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] UPS/NUT with openSUSE 13.1

[Charles Lepple]

On Sep 8, 2015, at 4:48 PM, Rob Groner  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

[Rob Groner]

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 Price]

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 havn't tested with openSUSE 13.2 so there may be something in it which 
prevents the driver from connecting to the UPS.  Perhaps with a more 
detailed trace using the upsdrvctl -D option it may be possible to see 
more clearly.


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] UPS/NUT with openSUSE 13.1

[Roger Price]

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

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Rob Groner]

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 Price]

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] UPS/NUT with openSUSE 13.1

[Rob Groner]

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