similar to: Fedora 40 nut-server not starting at boot

On Mon, Jul 29, 2024 at 5:45?PM Tim Dawson <tadawson at tpcsvc.com> wrote: > OK, looking at this on my RH8 test image . . . > > The first thing that I note, is that the *only* thing that needed to be > set to "enabled" in systemctl (IE "systemctl enable ....") is the > nut.target entry. > Tim, can you show output of systemctl list-unit-files| grep nut

OK, looking at this on my RH8 test image . . . The first thing that I note, is that the *only* thing that needed to be set to "enabled" in systemctl (IE "systemctl enable ....") is the nut.target entry. All else here are disabled, and "drug along" by nut.target which ensures that they come up in sequence. In nut.target I added to the "After" and

I've had fun with nut on RH systems, these are my notes to get it working: Create /usr/lib/tmpfiles.d/nut-client.conf:D? ? /run/nut 0770 root nut - ...the file did not exist, and so the PID folder/file was not getting generated. Then the driver would start. Also had to setup enabled services (still not 100% confident that this is totally correct):[root at emp80 ups]# systemctl list-unit-files

On Sat, Oct 31, 2020 at 2:42 PM Tim Dawson <tadawson at tpcsvc.com> wrote: > I'm going to guess that since your test runtime of 305 is very close to > the low limit of 300, that's the warning. Not yet a fail, but very, very > close. > I tried setting override.battery.runtime.low = 60 in ups.conf, and waited for the UPS to reach 100% charge, and ups.status to report only

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

---------- Forwarded message ---------- From: Tim Dawson <tadawson at tpcsvc.com> Date: Thu, Feb 13, 2014 at 12:07 AM Subject: Re: [Nut-upsuser] Powerware (Eaton) Prestige 9 UPS To: Charles Lepple <clepple at gmail.com> Charles - As a quick followup, the Prestige (both FW 2.13 and 3.09 - 2.x is pre-Eaton, 3.x post) reply to the topology block query thus: 3.064046

Look in the startup logs and see where itnis starting. I'm not at a RH system at the moment, but at work, I have had to do this, so can look there,mor perhaps put Nut on the test RH8 VM I spun up for other rrasons on Friday and work out the syntax. Not sure if the systemd file you are using came in the RPM or not, but if it did, it's almost a crime that this critical detail was overlooked.

On Sep 24, 2015, at 12:20 PM, Tim Dawson <tadawson at tpcsvc.com> wrote: > > The "#! <shell>" 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

Just looked at your prior mail, and it was using 'usbhid' based on your output. If 'modprobe' exists on your router, what response do you get to 'modprobe usbhid'? - Tim On February 24, 2014 2:56:16 AM CST, Tim Dawson <tadawson at tpcsvc.com> wrote: >Either it is not loaded, or the usb serial and/or hid drivers are not >loaded, which appear to have been used

ls -lia /<path>/wall will give you the owner and group . . . . Messages off . . . I think you are on the path . . . . -Tim On July 15, 2015 10:00:51 PM CDT, john hart <jsamcr at yahoo.com> wrote: >Time, not sure who owner is, but I've tried as both admin and myself, >to no avail. ?However, I told you that mesg is y, buti tried to send a >mesg using ?' write '

HI again, Sorry I didn't mean to cause a security debate. I'd like things to be secure of course, but I've got a dilema that I don't use DHCP and instead have a block of static IPs from my ISP. So my nut server has 68.68.452.02 for example and my two slave clients have 68.68.452.03 and .04 ideally I'd like to allow access for the whole static IP block to access the nut

On Saturday 31 October 2020 20:13:48 Rick Dicaire wrote: > On Sat, Oct 31, 2020 at 2:42 PM Tim Dawson <tadawson at tpcsvc.com> wrote: > > I'm going to guess that since your test runtime of 305 is very close > > to the low limit of 300, that's the warning. Not yet a fail, but > > very, very close. > > I tried setting > override.battery.runtime.low = 60

I noted some correspondence from several years back about supporting this device with bcmxcp, and the problems therein. Since I have one of these UPS units, still going strong, and the Eaton LanSafe stuff has finally caused me enough grief to abandon it, I figured I'd take a look at this. The issue is not that bad - the bcmxcp driver query of the topology block (2 bytes!) is returning

I downloaded latest source and it compiles ok but the original usbhid-ups.c is unchanged. Pier changed other files, too, and I don't know the changes needed. Simply substituting the modified (as per 2011) usbhid-ups gives a failed connection to the ups. So I have tried a little. I'll uninstall 2.6.3 and try to install 2.7.2 from a fresh compile. Thanks for the responses so far :-) --

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

Time, not sure who owner is, but I've tried as both admin and myself, to no avail. ?However, I told you that mesg is y, buti tried to send a mesg using ?' write ' ?and it says I have messages disabled. ????? ? I did that by opening two?terminals, on I logged in as ' su ', and sent the message from there. ?Is that peculiar? Might account for why I am notgetting anything from

I guess it's kind of a natural response on my part, working professionally in software. T-Shooting step one: Get current and see if the problem persists. If it does,then step rwo: debug. 2+ years is forever in software, noting that 2.6.3 was mid 2012 . . . - Tim On October 17, 2014 9:38:15 PM CDT, Charles Lepple <clepple at gmail.com> wrote: >On Oct 17, 2014, at 8:31 PM, Tim Dawson

On June 21, 2017 5:26:47 PM GMT+02:00, Tim Dawson <tadawson at tpcsvc.com> wrote: >My thought of #2 require none of that . . . I have a server with two >supplies, and two UPS units. One supply is on each UPS, and clients are >distributed otherwise to balance. The main thing is to ensure that it >is documented accurately how to config so that the server only shuts >down when

Charles and Tim - I actually had 192.168.123.1 3493 initially since that's what I thought was correct but it didn't work - don't remember the exact error and I'm not near the hardware right now to check it. I don't believe I checked 0.0.0.0 3493. I will try both again when I get a chance and reply with a better update. Thanks for the quick reply! Shade On Tue, Mar 25,

On Oct 17, 2014, at 8:31 PM, Tim Dawson <tadawson at tpcsvc.com> wrote: > Likely because 2.6.3 is not a current release. 2.7.2 (or 3?) is rhe current version, and it makes little sense to backport changes. Tim, It's possible that these changes didn't make it in. I admit that would be my knee-jerk reaction to seeing an older version number, but the last occurrence of