Comments (8)
Please retry with higher debug verbosity, e.g.:
:; sudo nut-scanner -DDDDDD -C > /tmp/nutscan.log 2>&1
There would be a huge wall of text about directories it looks into and file names it sees and tries to match there.
I wonder if your system delivers e.g. libusb-1.0.so.1.27.0
and no symlink like libusb-1.0.so
which could be in another package.
For context: most of NUT deliverables can be split into packages based on dependencies (e.g. snmp, ipmi, usb etc. drivers) or purpose (client, cgi, ...) However the nut-scanner
tool can optionally talk all protocols it can discover, and with usual shared object linking approach it would require all those libraries installed - even if the particular user never needs them (only got USB and has no care and footprint to spare for SNMP or IPMI libs). Instead, shared objects (libraries) are loaded dynamically by the program itself at its discretion - or skipped if the load failed, such as in this case. Why specifically it failed is the root cause to discover here.
from nut.
Also, just in case: how did you install NUT (packages? custom build?) and which version?
from nut.
Must be the OS that NUT was compiled on, I’ve just compiled and installed on Ubuntu 24.04 no issues.
from nut.
Sorry, have been on holidays, looping back to this now. I'm not great with Linux/packages/github, I installed using apt which I believe should be version 2.8.1-3.1ubuntu2.
Have run with higher debug verbosity, the following seem to be the most pertinent lines:
0.001188 [D1] Built-in: /usr/lib/gcc/aarch64-unknown-linux-gnu
0.001239 [D2] Looking for lib libusb-1.0.so in directory #0 : /usr/lib/aarch64-linux-gnu
-- snip --
0.012290 [D5] Comparing lib libusb-1.0.so with dirpath entry libusb-1.0.so.0
0.012298 [D5] Comparing lib libusb-1.0.so with dirpath entry libusb-1.0.so.0.4.0
-- snip --
0.014574 [D1] Looking for lib libusb-1.0.so, found NULL
-- snip --
0.026829 [D1] nutscan_init: get_libname() did not resolve libname for LibUSB, trying to load it with libtool default resolver
Cannot load USB library (libusb-1.0.so) : file not found. USB search disabled.
Am I right in thinking that creating a symlink 'libusb-1.0.so' that points to 'libusb-1.0.so.0' in the same directory should resolve the issue in this case?
from nut.
Yes, I wonder why one was not created in the first place (maybe devel packages deliver such a link, or some distro conventions had changed?) :\
At least, not directly a NUT problem, or not sure quickly how to address such distro specifics in common codebase, short of adding a nut-scanner
config file/options about such paths.
from nut.
Hm, yeah, the name without trailing numbers seems to come from development packages:
:; grep libusb-1.0.so /var/lib/dpkg/info/*.list
/var/lib/dpkg/info/libusb-1.0-0-dev:amd64.list:/usr/lib/x86_64-linux-gnu/libusb-1.0.so
/var/lib/dpkg/info/libusb-1.0-0:amd64.list:/usr/lib/x86_64-linux-gnu/libusb-1.0.so.0.3.0
/var/lib/dpkg/info/libusb-1.0-0:amd64.list:/usr/lib/x86_64-linux-gnu/libusb-1.0.so.0
Wondering how nobody stumbled on that before. Did everyone have a larger system footprint installed (e.g. did other packagings of NUT depend on *-dev packages of other stuff)?..
At least, this does seem like something NUT codebase can address - beside the idea above for direct run-time modifiable configuration of file names/paths to use, it may be possible to add the name(s) of the library seen at configuration/build time (e.g. libusb-1.0.so.0
or resolved through all the symlinks to "real file" at libusb-1.0.so.0.3.0
) to the built-in search list.
I would be wary of just allowing random suffixes to be accepted in the search method; to that end, get_libname_in_dir()
explicitly has checks to avoid "*.dll.a", ".so.1.2.3" etc.
and only pick the specified file name exactly (notably, not all such names can even be shared objects that we would be able to dynamically load). Although that is still a clumsy option... "If we found nothing exactly, try again with random suffixes allowed and check by dlload()
" but that IMHO is an attack waiting to happen :)
from nut.
A practical search on a test system does use realpath()
(where available) and practically use the ultimate file name when it looks at a symlink (which does exist):
0.002097 [D5] Comparing lib libusb-1.0.so with dirpath entry libusb-1.0.so
0.002108 [D2] Candidate path for lib libusb-1.0.so is /usr/lib/x86_64-linux-gnu/libusb-1.0.so (realpath /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0.3.0)
0.002119 [D1] Looking for lib libusb-1.0.so, found /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0.3.0
0.002121 [D1] nutscan_init: get_libname() resolved '/usr/lib/x86_64-linux-gnu/libusb-1.0.so.0.3.0' for LibUSB, loading it
0.002324 [D1] nutscan_init: succeeded to load the library for LibUSB
Looking at code, I see that for each library of interest, nut-scanner
tries one or more patterns via get_libname()
and if any of those fails to find an exact filename match in searched directories, it falls back to the likes of nutscan_load_usb_library()
(half a dozen of those for different libs) which would try to lt_dlopen()
the specified pattern(s) in hopes that the OS resolver would take care of locating the library in some location unexpected by NUT (and maybe under a slightly different name - up to the OS not NUT at this point). This is the part seen in your log too, as:
0.026829 [D1] nutscan_init: get_libname() did not resolve libname for LibUSB, trying to load it with libtool default resolver
from nut.
Running some experiments with another lib that is easier to fiddle with (NUT only built in this system, not installed into common paths, so its own libupsclient
is not resolved via OS paths):
:; ./tools/nut-scanner/nut-scanner -O
Cannot load NUT library (libupsclient.so) : file not found. NUT search disabled.
With the local build in the library path, it is seen:
:; LD_LIBRARY_PATH="`pwd`/clients/.libs:$LD_LIBRARY_PATH" ./tools/nut-scanner/nut-scanner -O -DDDDDD 2>&1 | grep -B5 -A5 'libupsclient\.so\.'
...
0.014299 [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.so
0.014308 [D2] Candidate path for lib libupsclient.so is /home/jim/nut/clients/.libs/libupsclient.so (realpath /home/jim/nut/clients/.libs/libupsclient.so.6.0.1)
0.014312 [D2] Looking for lib libupsclient.so, found in LD_LIBRARY_PATH
0.014313 [D1] Looking for lib libupsclient.so, found /home/jim/nut/clients/.libs/libupsclient.so.6.0.1
0.014313 [D1] nutscan_init: get_libname() resolved '/home/jim/nut/clients/.libs/libupsclient.so.6.0.1' for NUT Client library, loading it
0.014361 [D1] nutscan_init: succeeded to load the library for NUT Client library
...
Removing the .so
symlink out of the way:
:; ls -la clients/.libs/libupsclient.so*
lrwxrwxrwx 1 jim jim 21 May 15 17:35 clients/.libs/libupsclient.so -> libupsclient.so.6.0.1
lrwxrwxrwx 1 jim jim 21 May 15 17:35 clients/.libs/libupsclient.so.6 -> libupsclient.so.6.0.1
-rwxr-xr-x 1 jim jim 223376 May 15 17:35 clients/.libs/libupsclient.so.6.0.1
:; mv clients/.libs/libupsclient.so{,.x}
:; LD_LIBRARY_PATH="`pwd`/clients/.libs:$LD_LIBRARY_PATH" ./tools/nut-scanner/nut-scanner -O -DDDDDD 2>&1 | grep -B5 -A5 'libupsclient\.so\.'
...
0.013544 [D2] Looking for lib libupsclient.so in directory #1 : /home/jim/nut/clients/.libs
0.013569 [D5] Comparing lib libupsclient.so with dirpath entry libnutclient.so.2.0.2
0.013586 [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.a
0.013588 [D5] Comparing lib libupsclient.so with dirpath entry upslog
0.013589 [D5] Comparing lib libupsclient.so with dirpath entry libnutclientstub.la
0.013590 [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.so.6.0.1
0.013591 [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.exp
...
0.013598 [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.so.x
0.013599 [D5] Comparing lib libupsclient.so with dirpath entry libnutclient.a
0.013600 [D5] Comparing lib libupsclient.so with dirpath entry libnutclientstub.a
0.013600 [D5] Comparing lib libupsclient.so with dirpath entry upsset.cgi
0.013601 [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.so.6
...
0.013613 [D1] Got no strong candidate path for lib libupsclient.so in /home/jim/nut/clients/.libs, but saw seemingly related names (are you missing a symbolic link, perhaps?) e.g.: libupsclient.so.6.0.1
0.013619 [D2] Looking for lib libupsclient.so in directory #2 : /usr/lib/x86_64-linux-gnu
...
So it even recognizes that file, just not as a "strong" candidate.
from nut.
Related Issues (20)
- Revise driver man pages to include all known options (and their data types)
- usbhid-ups: Complete the `onlinedischarge_log_throttle_hovercharge` option support
- RFE: Enhance `upsd` to `LISTEN host:port` with one colon-separated parameter token HOT 1
- Works with Forza FX-2200LCD using nutdrv_qx driver HOT 1
- [HCL] GE Critical Power - VH Series UL - supported by snmp-ups (mib = ietf) HOT 3
- NUT for Windows: add help/usage to the CLI wrapper `nut.exe`
- nutwriter.hpp / -Wmaybe-uninitialized warning HOT 2
- `pijuice` driver uses `status_set()` unidiomatically
- C++20 compiler complaints HOT 4
- Add S/N to ups.conf and nut breaks HOT 13
- v2.8.1 Works with PowerWalker VI 600 STL LCD on OpenBSD HOT 1
- APC Smart-UPS 1000 USB - ups.test.result: No test initiated and missing TIMELEFT HOT 12
- Are there more readings with USB driver rather than SNMP? Eaton 5P 850 HOT 5
- Definitive guide on how to setup upsmon to shutdown computer HOT 8
- upsdrvctl start no longer works (insufficient permissions on everything) HOT 13
- For the few cases where we use variables as formatting strings, find a way to ensure it is safe HOT 3
- Help please poweredge rt2000 HOT 3
- Failed to open device (1D6B/0003), skipping: Access denied (insufficient permissions) | Eaton 9130 HOT 5
- Weird connectivity issues with a generic ViewPower UPS HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nut.