Bill - that all depends on the operating system and the UPS in question. Some combinations work, others don't and (worse) some that should don't.

As to your second question - are you talking about keeping a laptop with a GPU running for a few minutes, or are you talking about running a desktop from a laptop PSU?

Neither, actually. I would like to connect a UPS to my desktop. When I have a power outage, I want the UPS to keep the desktop running. Ideally, I would like Boinc to stop computing when running on the UPS backup. That is in essence how a laptop runs now, which I guess is one good feature a laptop has.

So it looks like this is something that isn't built into Boinc just yet, whether you're running Windows or Linux (I won't ask about macOS...although I guess I did).

I have an old APC UPS. I know they're one of the more popular brands. Whether the UPS manufacturers use the same API or not, regardless of OS, I would think it shouldn't be too challenging to write code for the top five brands?

---

Seti@home classic: 1,456 results, 1.613 years CPU time

The trouble is Keith, not every UPS uses the same API, and not every operating system respects all of them, so there would have to be several variations on the theme to cover the whole spectrum :-(
This is unlike laptop batteries which, thankfully, now use a common API call.

Sounds like the common ordinary *nix problem, someone has to write the driver because the old one is out of date. Maybe for many of these problems the UPS maker has a driver download. I'm sure data center size UPS do work right.
Haven't tried Win 10, but Win 7 and Mac O/S all know when they are on mains or battery.

What I have failed to point out is that the API is the same for all UPS'. There already is a mechanism in Linux to suspend when on battery and works as advertised for a laptop. But the mechanism is very old and matches up with what BOINC currently uses. However for a modern Linux release they have started using a much newer interface that uses a different mechanism. But the current BOINC client code does not know about this new interface. What needs to happen is the BOINC client code to get updated to also probe this new interface to get the status of whether the host computer is on battery, both laptop battery power and desktop UPS backed battery power. The states are available but the BOINC client code does not know where to look for them in modern Linux.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

The trouble is Keith, not every UPS uses the same API, and not every operating system respects all of them, so there would have to be several variations on the theme to cover the whole spectrum :-(
This is unlike laptop batteries which, thankfully, now use a common API call.

Sounds like the common ordinary *nix problem, someone has to write the driver because the old one is out of date. Maybe for many of these problems the UPS maker has a driver download. I'm sure data center size UPS do work right.
Haven't tried Win 10, but Win 7 and Mac O/S all know when they are on mains or battery.

It's not a driver issue. There IS NO driver involved. It's a BOINC issue where it just isn't looking for battery status in the correct place. All that needs to be done is update the code in the /client/hostinfo_unix.cpp file at line 195 to use another defined method for finding the battery status.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Maybe you are confused of what is being asked. The UPS's do function correctly for controlling the state of the host computer when the power is interrupted. They gracefully stop all processes and shut the computer down until power is restored. All my APC UPS's do that quite well with no issues with the software solutions available.

But that is not what we are asking for. We don't want to shut the computer down when we lose power. We want to shed the compute load of BOINC computing to lesson the demand load on the battery backup by simply obeying the standard BOINC Manager configuration of "Suspend computing when on battery" which is in the Computing Preferences on both the web and local preferences interface. That way the computer can stay up running much longer on battery if it does not have a large compute load on it and only has to support the computer in normal idle loads with not much running. Certainly not most of the cpu on cpu tasks and however many gpu tasks are running.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

hi, with active PFC with the actuals and last power supplies, u need to have pure sine wave UPS to avoid some disagreements

like explained in this APC ad https://www.youtube.com/watch?v=1huvCkTisko

---

Since there are at least two versions of the API - the "old" one, and the "new" one, that means some additional logic is required to make sure that the UPS is detected correctly (remember not everyone has the newest UPS, there are still a large number of ancient ones kicking around - I have at least three....). Add to that the fact that there are several "flavours" of Linux out there (Deb, Red Hat, etc.) and each of those could have different internal APIs then the problem is not the "easy" one that you portray :-(

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Keith, somewhere *nix has to talk (actually listen) to the UPS to know what state it is in. To do that there is a driver.

If the "old" API is gone then the loader should fail and BOINC should not launch.

If call is the same name but the arguments have changed, then someone is ignoring a compile/link warning message.

If the call returns different values than before, feature test macros and also very un-*nix like for that to be the case.

Haven't looked for that API, wouldn't surprise me to see if it returns a mask and before you could do an integer compare but now you actually have to mask off the bit(s) you are interested in.

But it is! That is why I provided the link to the code that detects on battery. All that is needed is to add another detect method to the list that is tried.
#elif LINUX_LIKE_SYSTEM
static enum {
Detect,
ProcAPM,
ProcACPI,
SysClass,
NoBattery
Upower
} method = Detect;

First we try:
// try APM in ProcFS if not found then try
// try ACPI in ProcFS if not found then try
// try SysFS if not found then try
// try Upower which is the latest method for detecting when on battery
and finally
// if we haven't found a method so far, give up
method = NoBattery;

All we need to do is write the new Upower section for looking where the battery state is in newer Linux. If you are running older hardware and older OS or other OS, then the first methods will find the battery state. The client keeps trying the various methods until it finds the battery or doesn't. All that is wrong with the current code is that all the older detect methods don't look for the correct thing in modern Linux and fail through to no battery detected. If we add the Upower detect method, we find the battery state.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I don't know why everyone is getting hung up on API. There is no API involved in the detect code other than using a name to identify the detect method. LOOK at the code! The hostinfo_unix.cpp is NOT an API. It is just a module of C++ code. All the detect methods do is look somewhere on the host drive for a file that created for whether the battery is charging or discharging or the host is on battery or AC power. The dbus API accesses the Upower daemon and sends out a message to the system that the battery state has changed. The message file is what we need to look for.

The Upower daemon is an abstraction for enumerating power devices, listening to device events and querying history and statistics. Any application or service on the system can access the org.freedesktop.UPower service via the system message bus.

Here is the documentation once again.
https://upower.freedesktop.org/docs/UPower.html

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

That IS the API for systems using "upower"
- do you know for certain that EVERY Linux system uses upower, or are there alternatives out there that use a different API?

Interesting little giveaway near the bottom of the page, against the defintion of the battery use/not use bit:

The "OnBattery" property

'OnBattery' read 'b'

Indicates whether the system is running on battery power. This property is provided for convenience.

"For convenience" - that means it may not be fully, or properly acted on, or implemented, as it is almost an optional feature, not a mandated feature.


It is also worth noting that only THREE actions are actually defined:

GetCriticalAction ()

GetCriticalAction (out 's' action)

When the system's power supply is critical (critically low batteries or UPS), the system will take this action. Possible values are:

HybridSleep:
Hibernate:
PowerOff:

action:
A string representing the critical action configured and available.

Nothing in there about "stop application xxx running", so that is a derived function is harder to cope with at the application end (and I dare say very hard to cope with at the triggering end - one would have to set up an exclusion (or inclusion) list of applications, or to have a delay of some sort in the "detect on battery" trigger and the "critical action" trigger, which does not appear to exist in the API, but might/should be possible to derive from the data within the "GetDisplayDevice ()" method. (This has changed quite dramatically from one of the earlier UPS management APIs where there were a couple of "non-critical" triggers available which could be used to kill selected applications when the SoC dropped below a certain level - the fun there was interrogating the task id so you could set and maintain the "kill on event" table up as each application started and stopped.)

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Greetings,

From Wikipedia:

An application programming interface (API) is an interface or communication protocol between a client and a server intended to simplify the building of client-side software.

I'm not a programmer, but from what I read above, I would say that that is not what Keith is talking about.

Have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

That IS the API for systems using "upower"
- do you know for certain that EVERY Linux system uses upower, or are there alternatives out there that use a different API?

Is there a guarantee that every Linux system uses the existing API's ProcAPM, ProcACPI or SysFS? No there isn't. That is why we probe for each one until we find one that reports the device's state of "On Battery"

From what I have gathered, Upower is the descendent of PolicyKit which is deprecated. And PolicyKit is the descendent of ProcFS or something.

It isn't the job of the API to "stop application xxx running" that is the job of the BOINC client as the only applications we care about are the BOINC science apps. All we are looking for is an indication of whether the device is "on battery" and then make a decision to do something about it.

The job of the API is just to detect messages from the application that is monitoring the UPS state, IOW APC's PowerChute program or the open source apcupsd program or whatever program that the UPS manufacturer provides, that the UPS has shifted to battery power during a power outage and sent out a system message to be acted upon or not.

We don't have to be concerned with the individual UPS monitoring programs since their job is only to communicate to the dbus API which all Linux systems use as far as I know. And all they have to do is signal the dbus API using a standardized messaging system. Then we just look for the dbus API message that it has been told the host is on battery. Then the BOINC client knows to "suspend applications when on battery"
Objective achieved.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

If there are other *nix systems out there that don't use the existing detection messaging systems that are already probed for in the client and don't use Upower which is needed to be added to the detect methods, then just add another detect method for those systems. If we need to add Upower, then just add the others too.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Are totally certain that all UPS manufacturers correctly apply the "on battery" bit?
They could quite easily use one or more of the "battery discharging" and "percent charge" values to give a more realistic "UPS has lost mains" control value. Don't forget that a lot of UPS actually continuously charge the battery, and simultaneous discharge it so "on battery" is the only state that exists because doing so gives some considerable advantage in regulating the output voltage and gives instant protection against mains drop-outs.

Interesting thing is that while laptops have a battery continuously in the circuit there is a subtle difference in the logic - it is assumed that "plugged into the wall" is the exception rather than the rule, and the vast majority of them do the setting of the "on battery" bit in the manner one might expect.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Upower seems to be a third party addition.

http://man7.org/linux/man-pages/man5/proc.5.html
/proc/apm

Upower seems to be a third party addition.

http://man7.org/linux/man-pages/man5/proc.5.html
/proc/apm

No it is not. At least if you go by the standard definition of third-party which entails downloading software not included by default in a distro. Upower is part of the freedesktop.org platform which is included with most Linux/Debian distros.
https://www.freedesktop.org/wiki/Software/

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

If you can drop to command shell within the code, you can just run the upower daemon and get the state of the UPS battery. But I don't think that is even necessary, just look for the message file in the path directory for the device and look for the battery state symbol.

keith@Serenity:~$ upower --monitor-detail /org/freedesktop/UPower/devices/ups_hiddev0
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
[08:38:59.453]	device changed:     /org/freedesktop/UPower/devices/ups_hiddev0
  native-path:          /sys/devices/pci0000:00/0000:00:08.1/0000:0d:00.3/usb9/9-4/9-4:1.0/usbmisc/hiddev0
  vendor:               American Power Conversion 
  model:                Smart-UPS_1500 FW:UPS 03.5 / ID=1015
  serial:               3S1831X12519    
  power supply:         yes
  updated:              Wed 23 Oct 2019 08:38:59 AM PDT (0 seconds ago)
  has history:          yes
  has statistics:       yes
  ups
    present:             yes
    state:               fully-charged
    warning-level:       none
    time to empty:       9.8 minutes
    percentage:          100%
    icon-name:          'battery-full-charged-symbolic'

[08:38:59.458]	device changed:     /org/freedesktop/UPower/devices/ups_hiddev0
  native-path:          /sys/devices/pci0000:00/0000:00:08.1/0000:0d:00.3/usb9/9-4/9-4:1.0/usbmisc/hiddev0
  vendor:               American Power Conversion 
  model:                Smart-UPS_1500 FW:UPS 03.5 / ID=1015
  serial:               3S1831X12519    
  power supply:         yes
  updated:              Wed 23 Oct 2019 08:38:59 AM PDT (0 seconds ago)
  has history:          yes
  has statistics:       yes
  ups
    present:             yes
    state:               fully-charged
    warning-level:       none
    time to empty:       9.8 minutes
    percentage:          100%
    icon-name:          'battery-full-charged-symbolic'

Upower -e enumerates all devices.

keith@Serenity:~$ upower -e
/org/freedesktop/UPower/devices/ups_hiddev0
/org/freedesktop/UPower/devices/keyboard_hidpp_battery_0
/org/freedesktop/UPower/devices/mouse_hidpp_battery_1
/org/freedesktop/UPower/devices/DisplayDevice

And upower -d displays the status of all enumerated devices.

keith@Serenity:~$ upower -d
Device: /org/freedesktop/UPower/devices/ups_hiddev0
  native-path:          /sys/devices/pci0000:00/0000:00:08.1/0000:0d:00.3/usb9/9-4/9-4:1.0/usbmisc/hiddev0
  vendor:               American Power Conversion 
  model:                Smart-UPS_1500 FW:UPS 03.5 / ID=1015
  serial:               3S1831X12519    
  power supply:         yes
  updated:              Wed 23 Oct 2019 04:07:29 PM PDT (4 seconds ago)
  has history:          yes
  has statistics:       yes
  ups
    present:             yes
    state:               fully-charged
    warning-level:       none
    time to empty:       9.6 minutes
    percentage:          100%
    icon-name:          'battery-full-charged-symbolic'

Device: /org/freedesktop/UPower/devices/keyboard_hidpp_battery_0
  native-path:          hidpp_battery_0
  model:                K520
  serial:               2011-1c-ea-e8-7f
  power supply:         no
  updated:              Wed 23 Oct 2019 04:05:41 PM PDT (112 seconds ago)
  has history:          yes
  has statistics:       yes
  keyboard
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    battery-level:       high
    percentage:          70%
    icon-name:          'battery-full-symbolic'

Device: /org/freedesktop/UPower/devices/mouse_hidpp_battery_1
  native-path:          hidpp_battery_1
  model:                Wireless Mouse M510
  serial:               4051-4d-87-b1-46
  power supply:         no
  updated:              Wed 23 Oct 2019 04:06:36 PM PDT (57 seconds ago)
  has history:          yes
  has statistics:       yes
  mouse
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    battery-level:       normal
    percentage:          55%
    icon-name:          'battery-good-symbolic'

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply:         yes
  updated:              Wed 23 Oct 2019 04:07:29 PM PDT (4 seconds ago)
  has history:          no
  has statistics:       no
  ups
    present:             yes
    state:               fully-charged
    warning-level:       none
    time to empty:       9.6 minutes
    percentage:          100%
    icon-name:          'battery-full-charged-symbolic'

Daemon:
  daemon-version:  0.99.7
  on-battery:      no
  lid-is-closed:   no
  lid-is-present:  no
  critical-action: PowerOff
keith@Serenity:~$

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Upower is part of the freedesktop.org platform which is included with some Linux/Debian distros.

On my Debian derived Linux box

$ upower
-bash: upower: command not found

Not going to check if sudo apt install upower finds it in the distro. I don't need it.

/proc is included/required in all Linux systems (modern anyway). It is what the developers should be using because of that universal.
If the system is so old /proc isn't there then sysctl is the depreciated method.

Ok, not in your distro. But what debian derived distro do you use? I don't see one in your hosts. freedesktop.org platform is used in most distros I am aware of simply because they all use the same software like X.org, X11, D-Bus, Network Manager, Wayland, Nouveau, Mesa, Plymouth, PulseAudio etc. etc. Just look at the list of software on the freedestop.org software list. I would say simply because of a good majority of debian distros have and use those programs, they have Upower available. So why not just add a Upower detect method to cover a good majority of Linux systems. What is the harm? And now you have good coverage for detecting on battery state for a much larger contingent of Linux hosts.

https://www.freedesktop.org/wiki/Software/

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)