similar to: Setting up charge/voltage based shutdowns

Yeah, I have no lack of imagination about scenarios where that can be useful - just was surprised to see no apparent "here's how you do it" sort of man page or something, Although technically the shutdown scenario like yours, where a NAS server only is told to go down - or actually does so (which is substantially different and can be implemented elsewhere) - after its consumers go

Yeah, I have no lack of imagination about scenarios where that can be useful - just was surprised to see no apparent "here's how you do it" sort of man page or something, Although technically the shutdown scenario like yours, where a NAS server only is told to go down - or actually does so (which is substantially different and can be implemented elsewhere) - after its consumers go

I think it can be useful in a scenario like: - Large UPS, that powers 2 hosts: one is VMServer with just a small boot driver and the second is a NAS with all the disks for the first server. - UPS is connected by USB to another host (such as a small Raspberry PI), acting as the NUT primary. - Both machines served by UPS are NUT secondaries. - The NAS box can only shutdown one the VMware is fully

I think it can be useful in a scenario like: - Large UPS, that powers 2 hosts: one is VMServer with just a small boot driver and the second is a NAS with all the disks for the first server. - UPS is connected by USB to another host (such as a small Raspberry PI), acting as the NUT primary. - Both machines served by UPS are NUT secondaries. - The NAS box can only shutdown one the VMware is fully

Hi Jim, I was thinking about setting different values for each device , so the first system has higher values and shutdowns?earlier:override.battery.charge.lowoverride.battery.runtime.low Won?t it work ? Best Regards,Strahil Nikolov? On Sunday, August 6, 2023, 7:41 PM, Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> wrote: Yeah, I have no lack of imagination about

Hi Jim, I was thinking about setting different values for each device , so the first system has higher values and shutdowns?earlier:override.battery.charge.lowoverride.battery.runtime.low Won?t it work ? Best Regards,Strahil Nikolov? On Sunday, August 6, 2023, 7:41 PM, Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> wrote: Yeah, I have no lack of imagination about

>From my understanding, alone with other NUT behaviors it would not. Even if NUT drivers already do (or are changed to) react to the actual charge/runtime going below this setting to fabricate an LB status, this as a driver setting/override would have immediate effect on all clients like `upsmon` watching the device status on their shared data server. This simultaneously requested shutdown

>From my understanding, alone with other NUT behaviors it would not. Even if NUT drivers already do (or are changed to) react to the actual charge/runtime going below this setting to fabricate an LB status, this as a driver setting/override would have immediate effect on all clients like `upsmon` watching the device status on their shared data server. This simultaneously requested shutdown

One thing that I think NUT misses is the client side being able to decide to shutdown by itself based on time (this can be done), battery charge (ex if bellow 10%), and estimated runtime left (if available and considered reliable/calibrated). Without having to sort on the LB state from the server. Sent from my iPhone with ? iTypos > On Jul 16, 2023, at 4:34 PM, Willcox David via Nut-upsuser

Hi, this does sound like a useful idea - although for the principle of least surprise and for variation in deployments, I'd rather have it as a (non-default state of a) configuration toggle that can be set via `upsmon.conf`: whether this particular client exits after processing FSD or not. The onus for the rest would be on general systems integration - e.g. ensure that init scripts `K*`ill the

On Sun, 9 Jun 2019, Joe Gervasio wrote: > This question undermines my reading of the documentation.  I had thought that > these were separate things:  > >     SHUTDOWNCMD "/sbin/shutdown -u -h +1"  >     NOTIFYCMD /opt/local/sbin/upssched > > I had assumed that the SHUTDOWNCMD would be used by the Nut client (upsmon) to > shutdown the slave system,  and that

Hi, and thanks for this great piece of free software! I've been meaning to sort this out for some time, but we don't get power outages that often, fortunately... So, correct me if I'm wrong, but from the documentation at https:// networkupstools.org/docs/user-manual.chunked/ Configuration_notes.html#UPS_shutdown, and also reading upsmon.c, when a UPS goes OB LB (assuming we have a

fredag 27 oktober 2023 20:07:58 CET skrev Jim Klimov: > Hi, this does sound like a useful idea - although for the principle of > least surprise and for variation in deployments, I'd rather have it as a > (non-default state of a) configuration toggle that can be set via > `upsmon.conf`: whether this particular client exits after processing FSD or > not. The onus for the rest

Hi, recently I observed that during a power outage, my NUT setup doesn't shutdown properly. Indeed it never reaches the LowBattery state to notify and initiate shutdown on clients. Reviewing my setup and logs I think I'm facing multiple problems and I'm unable to point to real root cause. First, let me focus on my scenario and current setup: In normal status (ONLINE, fully charged)

Hello, I am a new user of NUT and trying to wrap my ahead around a couple of things. I installed NUT 2.7.4-13 from package on RasPi 4, running Raspbian Linux 11 (bullseye). I have Cyberpower SL700U connected to it. For testing I set battery.charge.low to 90, so I wouldn't have to wait a long time. See all relevant config below. First of all, what seems to happen is that UPS gets to the low

On Jun 8, 2019, at 4:16 PM, Roger Price wrote: > > Is your System Shutdown Plan to shut down using upsmon or using the script upsched-cmd? In upssched.conf you do not have a line > > AT LOWBATT ups at ... EXECUTE lowbatt > > and in upssched-cmd there is nothing to shut down the system. Joe, Roger has a good point - the SHUTDOWNCMD should work as long as the master system

Hi! Is there a way to tell upsd to initiate a shutdown sequence (i.e. run SHUTDOWNCMD) immediately after losing line power and switching the state to OB? I'm using an old battery and by the time it reaches LB state, it's already too late for a clean shutdown. Another solution would be to change the LB percentage. It currently reads (upsc): battery.charge.low: 10 Is there a way to

Hello, I'm experiencing a strange early shutdown behavior with the following system: * */OS/*: Slackware Linux 14.2 x86_64 * */NUT/*: 2.7.4 (from my own package <https://sotirov-bg.net/slackpack/pack.cgi?id=4083>) * */UPS/*: MGE Ellipse PRO 1600 <powerquality.eaton.com/Products-services/Backup-Power-UPS/Ellipse-PRO.aspx> (bought in September 2017) */Problem

> If there is no message to NUT, I would consider opening a trouble > ticket with Eaton. It is possible that there is a known issue and/or > a firmware upgrade. What kind of message to NUT? In the log (syslog) there is no other message registered. In nut.log only this appears: > Dec 1 08:10:54 openmediavault upsd[5284]: Data for UPS [ellipsemax] > is stale - check driver >

Thank you for your response. The point is that I have configured my system to shut down at the event "upsc Inform@localhost ups.status"!="OL", not at "LB". So there will be no /etc/killpower file created. At an ups.status != "OL" event, the following script named "notifyme" is run: echo `date` >> /root/upsLog echo " No power, shutting