NUT 2.8.1-3 "Can't claim USB device [051d:0002]@0/0: Entity not found" using usbhid-ups #2666
Labels
APC
DDL
impacts-release-2.8.1
Issues reported against NUT release 2.8.1 (maybe vanilla or with minor packaging tweaks)
USB
Comments
ErikDB87
changed the title
|
I thought removing and installing the package again might solve the problem. I also removed But somehow, the directory So I did this: And now: Somehow, I made it worse... But I don't understand how installing the packages again fails to install these files...? EDIT But |
|
I believe some answers around this general issue are in the mailing list. As for packaging, NUT team does not impact it directly, so it is technically a distro matter. That said, probably different packages defined for NUT there which deliver files which might need configuration files, all deliver the |
|
Of course I didn't expect my amended config files to appear. :) But the standard ones - which were installed when I first installed NUT, didn't reappear... I manually added Anyway, I had hoped this reinstall would have reset all the permissions. But I was wrong... But it looks like I'm where I started out; so maybe no harm no foul? |
|
Probably no foul. As you edited Re-check if the unit does exist and does not complain (like on the mailing list) - if so, go on to |
|
I'm not sure I fully understand what you mean... I'm not really a Linux master :) But here are some outputs: There seem to be some problems with |
|
Looks great actually:
(if on the same machine as WARNING: The This usually means either mismatch between I am a bit puzzled about |
Indeed:
I had hoped a fresh install would have reset all the permissions... Do you have any idea which commands might fix the permissions issues? |
jimklimov
added
DDL
APC
USB
impacts-release-2.8.1
|
Looking at your earlier post, the Also note, with an APC BX###MI device, #2565 and related issues and PRs may be relevant. That fix is not part of a released version yet though, so if you'd end up needing it before a release is cut and gets through distro packaging queues - a custom build would be required, e.g. per https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests |
|
As for file permissions, can you post |
I see... Shame on me for following the guide, and not reading the readme. I did that eventually for a few other conf files, but not this one... I assume this would be better? ? (I'll have access to the Linux server later today; I'll run |
|
Well, coming from legacy long ago, before my time, that
|
So it should be: ? |
|
Maybe, if it does work to mix it like that. If something still complains, separate this into two users for two use-cases, e.g.: (and then use |
|
Thanks for all your time and effort, @jimklimov! Although we're not out of the woods yet, I'm afraid... Now (Although I don't understand where this
Now: Unfortunately, even after a Linux reboot, still: As requested: EDIT But trying it again, resulted in failure again: Puzzling... |
|
Looks cool about getting the driver and I think I think with #1917 in NUT v2.8.1 the driver program should have tried to communicate with the previous instance over its local socket (same as communications with |
|
Also note, that if you get You may be after |
|
Alternately, you can try sending commands to the UPS (using the |
The UPS didn't power cylce.
The Linux box shut down, but the UPS didn't power cycle...
You mean like so: ? Unfortunately, again no power cycle. (I've got a table lamp lit, so a power loss should be visible.) |
|
Looking at current code for the driver, the command sequence in Lines 969 to 993 in d244d73 |
I assume you mean the other options mentioned in that Java code? No power cycle... I also tried: But no effect on the lamp. FYI: |
|
"OK" there means the command was accepted by the driver. Please try It may also be that the device model/firmware does not actually support that command, or we poke a wrong USB endpoint for that (e.g. worked for other related devices but not this one). |
|
And that's plain old C code ;) |
But no effect on the lamp...
What would that mean for my setup? End of the line? Or are there more avenues to be walked? :) |
Done. LogsBut after a restart this morning (see message below):
No antivirus, and no storage problems that I know of... Are there any tests you can suggest I run? |
|
Tonight, my Linux system shut down for no clear reason... After some checking: Strange that this |
|
You might see more in Given |
journalctl -lu nut-serverjournalctl -lu nut-monitorI also tried
You mean the below lines in |
How is this possible? I realized I first had another git pulled, in directory OutputAlas (even after a reboot): Maybe I should |
|
Regarding the earlier log post, it seems "Can't connect to UPS [apcupskelder] (usbhid-ups-apcupskelder)" happened for at least 2 hours before For that matter, after a reboot at 03:39:34 it started and was stopped after a few seconds, so reasonably the nut-client could not talk to it; a subsequent reboot however was 4 hours later. The log copy is a bit messy in terms of monotonously growing time, but it seems between 07:49:51 and 09:00:52 communications of driver, upsd and upsmon were okay. In the So it missed 2 beats in 5 seconds, and went for FSD, which I don't think it should have. Such behavior may be possible when the UPS is last-known (to client) as on battery, and then if the connection is lost, power situation is assumed critical and immediate shutdown happens. But here in the As an off-topic bit, it is a bit odd and messy to see both |
|
Now looking at next post :)
and per I assume Also noted that your |
Given the complications above, and worse - their unknown nature - this may be a reasonable way to proceed. The many hours I've spent trying to troubleshoot this strange situation of something that should pass without blinking twice are hours by which the next NUT release gets delayed :-D |
:| Hopefully, some insight comes out of it, in the end ;)
What am I doing wrong here? It looks like I used this exact command before? Edit: it looks like that branch has been removed. Which branch do you recommend I clone? |
|
Seems the PR was merged and branch deleted -- use |
|
For the output of the reinstallation: see attachment: Reinstall-output.txt After a reboot: The UPS didn't shut down/power cycle...
Fair enough, but the command worked before... |
|
I now unplugged the UPS from the wall power. The Linux machine doesn't seem to be shutdown, even after 5 minutes, so that's good. The Plugging the UPS back in didn't cause a power cycle, but it shouldn't of course. But finally, where making some progress: After reboot: I then ran I'll now wait some 10 minutes, and observe... |
|
Nothing happened, even after 10 minutes. But since a shutdown or power cycle isn't necessary when there is power coming from the grid, that's not a big problem. A third test I'll now run, is running Although the UPS was plugged in again, it kept beeping and blinking. The Linux machine shut down, as with the earlier test. And then, roughly 1'30" after the command had been given, the UPS power cycled. HOORAY Unfortunately, my Linux box didn't start up again, although it should have. I've noticed it not doing so once in a while. Maybe a hardware issue with the Linux box? Anyway, it looks like finally, NUT is doing what it should! :) I assume actually letting it drain to its threshold, or putting the threshold higher to speed that up, would be the final test, but I don't want to do the latter, to avoid playing with the settings. But to test the former, I would need to be close to the UPS when it's about to shut down, so I can plug it back in after the Linux box is shut down, and before the UPS is. That seems difficult to time... |
|
Sounds great, thanks for the tests. Especially the latter one - seems to prove that it it UPS's hardware or firmware that may be handling commands from the driver differently based on whether it has wall power at the moment or not. Probably these tests also confirmed that the driver stopping, when built and running with systemd integration (using In the tests with the driver program, I see that the program you've launched communicates with the running driver (wrapped under the service), which in turn probably sends the shutdown command to the UPS successfully - since in at least some cases it ends up shutting down.
It may be revealing to In particular, I am curious how In case of the test while the UPS was plugged in, when the UPS did not power off/cycle, did the Linux OS shut down still? Or there was no FSD from Perhaps the drivers' processing of shutdown/off/reboot/etc. commands should also try to report the UPS as powering off via its protocol to the data server and beyond, so this is known before comms go stale. I don't think it was handled previously, this is a rather uncommon use-case. I also wonder if it is actually correct for the driver program to exit during shutdown command handling, at least on systems with a service management framework. Perhaps it should report administrative-OFF or something, but stay and continue reporting on the device state (so if e.g. this is not the only UPS of a server, and it does power-cycle and state changes, we can eventually report it is online again, without disrupting any services).
Only the Linux box? So is it correct to say that the UPS did power off and back on, and powered up the load sockets (confirmed by e.g. some lamp, or a laptop fed from the UPS, or LEDs on the server), and just the server's BIOS decided to not start?
IIRC at that time you had NUT programs and drivers all in PATH, |
|
That's a lot to digest :)
Seems that way, indeed.
I'm afraid this is beyond me. :)
I'll try that soon (but possibly only next Tuesday, as that's the day I have the most free time, without people possibly bothering me).
How should I best capture that info? Or do you expect it in the output of the
Linux OS didn't shutdown. I didn't record this, but I'm 99 % certain, because otherwise I would have been annoyed: without the power cycle, the Linux box would never start up again.
Again: beyond me. :) But if there is any way I can provide insight, I'll gladly follow your instructions!
Another Linux box, as well as my router and modem did restart.
Yes, and it works 85 % of the time. So I'm not sure where the problem lies.
I think all three outlets are identical, but I'm not 100% sure...
Actually, I've got one "superoutlet" (don't know the English term), in which my two Linux boxes, my router and my modem are plugged. Something like this: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQGu0Q_2cQowo-dczA-sLa79fuikCTW3CWqrg&s. Maybe that's not good practice, and I should make use of the two other outlets... Do you think that may have an impact?
Ah, I assume the apt package NUT was still installed then. |
Probably bump up
That can go by a number of names.
Using one with UPS should be okay, as long as you fit in the Amp rating of the socket. Can help "against" too-eager ECO sockets by always having someone to feed :) |
Okay, I already went ahead and did that: But reading the docs, I wonder whether my |
|
see also conf/*.sample files in repo - many start with hints on minimal config, and detail them all "yes" to minsupplies "depends" to flag |
I didn't quite get on what it depends... Also, reading the docs didn't clear everything up about |
|
There's a built-in value for the flag (from configure option or defaults). You might want to not write into persistent /etc but use a tmpfs like /run(/nut) for example. More so with flash storage and limited write cycles. |
By "journal", I suppose you don't mean the output of the command? But rather something like |
I was looking at the wrong Linux box 🙄😅 |
Should be a file path (name after dir missing).
"service", "its" :) So After a reboot, |
Coming up (tomorrow)! So
Good idea. |
|
Since the primary looks like it's working, I think I'm going to configure my secondary Linux box as well. But I'm not sure what I should install there. Can I use the package, even though the primary runs on a custom build? And if so, as per the documentation I should install |
|
Good question. There were some changes to Protocol-wise, the different versions of client and server should work well, even about the master/primary and slave/secondary change as part of 2.8.0 release. As for docs listing third-party packages, gotta check them eventually to modernize the list, maybe add more distributions too. PRs also welcome :) |
That sounds over my head 😬 Maybe I better build from the master branch again. I suppose a lot of the arguments are unneeded for a secondary? |
|
Would not hurt either, I think. Easier to keep stuff similar. |
|
Okay, I don't think the tests had the expected results...
Hopefully, some of this is of use. :) |
|
I repeated point 7, but now with Unfortunately, my primary Linux box didn't reboot... Is it possible the power isn't cut long enough on the power cycle...? (Although my secondary Linux box always boots up, maybe it's got more sensitive hardware?) I might need a more complicated workaround with a smart plug or something... :( (I now synchronized the clock of my Windows machine, which would have made more sense at the beginning of the tests...) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi all,
Yesterday, I bought a UPS for the first time in my life, and was eager to dive into NUT. But not all is working as expected... I saw a similar thread started on 18 October, but it didn't help me. (I also spent a handful of hours searching the web for solutions, and of course read the manual and FAQ - "queequeg".)
I tried shutting my UPS (APC "Back-UPS BX750MI FW:295202G -302202G") down with
sudo upsdrvctl shutdown, but no response. Digging around, I found a few things that raised my suspicion, but I can't figure it out...I followed this fine gentleman's guide (but tweaked it a bit - I don't know why he uses
masterandslavefor example?): https://technotim.live/posts/NUT-server-guide/.I must add that I created a few users and user groups during installation and configuration, following the documentation. But in the end, I lost oversight, and everything didn't work. So it's entirely possible there's a permissions issue somewhere. But I don't have any idea where...
Because of the trial-and-error approach, in the
.conffiles (shown below), a lot of stuff is commented out. I assume I can delete it, but I also assume the#should be adequate? Anyway, I keep it in the output below for clarity.I'll just paste various outputs here, I hope that's a reasonable approach?
Thanks in advance for anyone's help!
Kind regards,
Erik
This seems strange? But after some googling, I found the below alternative - although I would expect it to work without
/lib/nut/):The text was updated successfully, but these errors were encountered: