Thread (2 messages) flat view 2 messages, 2 authors, 2018-02-28

Re: [PATCH] hooks/pre-auto-gc-battery: allow gc to run on non-laptops

From: Adam Borowski <hidden>
Date: 2018-02-28 21:47:04

On Wed, Feb 28, 2018 at 10:16:21AM -0800, Junio C Hamano wrote:
Adam Borowski [off-list ref] writes:
quoted
Desktops and servers tend to have no power sensor, thus on_ac_power returns
255 ("unknown").

If that tool returns "unknown", there's no point in querying other sources
as it already queried them, and is smarter than us (can handle multiple
adapters).
The explanation talks about the exit status 255 being special and
serves to signal "there is no point continuing, and it is OK to
assume we are not on batttery", while the code says that anything
but exit status 1 can be treated as such.  Which is correct?
As the man page says:

# EXIT STATUS
#       0 (true)  System is on mains power
#       1 (false) System is not on mains power
#       255 (false)    Power status could not be determined

0 usually means a laptop on AC power, 255 is for a typical desktop.
The current code can't return 2 or any other unexpected value, but if it
ever does, an unknown error should probably be treated same as 255 unknown.
Thus, gc should be avoided only if the return code is 1.

As for the second paragraph, I meant that on_ac_power already queried all
sources this hook knows about (other than /usr/bin/pmset which is OSX
only[1]), thus if the answer is "unknown", continuing to query is redundant.

If that's unclear, do you have some other wording in mind?

Also, it's good to trust on_ac_power, as it'll get updated whenever new
quirks of power management get known: I heard allegations that some boards
say "USB" instead of "Mains", which should count the same for our
purposes[2].  It's not reasonable to update consumers such as git instead of
a single system-provided tool.

One worry is that, if on_ac_power is not installed, other sources known by
this hook likewise assume that unknown means battery.  And for example on
Debian, powermgmt-base (which is where on_ac_power lives) is no longer
installed by default.  This suggests this patch needs to be extended to
cover the other sources as well, but let's discuss this first.  Extra
commits are cheap...
quoted
Reported by: Xin Li [off-list ref]
Signed-off-by: Adam Borowski <redacted>
---
 contrib/hooks/pre-auto-gc-battery | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/hooks/pre-auto-gc-battery b/contrib/hooks/pre-auto-gc-battery
index 6a2cdebdb..7ba78c4df 100755
--- a/contrib/hooks/pre-auto-gc-battery
+++ b/contrib/hooks/pre-auto-gc-battery
@@ -17,7 +17,7 @@
 # ln -sf /usr/share/git-core/contrib/hooks/pre-auto-gc-battery \
 #	hooks/pre-auto-gc
 
-if test -x /sbin/on_ac_power && /sbin/on_ac_power
+if test -x /sbin/on_ac_power && (/sbin/on_ac_power;test $? -ne 1)
 then
 	exit 0
 elif test "$(cat /sys/class/power_supply/AC/online 2>/dev/null)" = 1

[1]. I don't know if there's an implementation of on_ac_power for OSX, but
if there is, it is reasonable to assume it uses or emulates pmset.

[2]. Technically, that's _dc_ not ac power, but as batteries use a different
interface, in the vast majority of cases USB power can be considered
non-rationed.  You can power it from an unplugged laptop or from a
powerbank, but that's no different from "mains" that come from an unplugged
UPS with no or unsupported control link.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help