Arch Linux

Automatisches Herunterfahren bei fast leerer Notebookbatterie

zauser

Liebe Arch-Gemeinde,

nachdem ich nach einer Recherche nichts finden konnte, wende ich mich wieder an Euch. Ich möchte, dass das Notebook (Thinkpad L520) bei einem kritischen Akkuzustand (so ca. 1%) von selbst herunterfährt. Momentan ist es so, dass das Notebook einfach ausgeht. Wie realisiere ich das mit IceWM? Herzlichen Dank im Voraus!

LG
zauser

GerBra

Das Zauberwort ist hier acpi(d)...

Ein fertiges Tool ist AFAIK laptop-mode-tools (dort kann man den Wert für dein gewünschtes Verhalten wohl einstellen), dieses Tool bewirkt aber noch andere Einstellungen die z.B. Strom sparen, aber manchmal sind auch viele Dinge nicht gewünscht... Im englischen Wiki gibt es u.a. Artikel zu ACPI und laptop-mode-tools.

Für deinen Wunsch geht es aber noch individueller und IMHO einfacher:
Der acpid sendet bei BATtery-Ereignissen ein Event, was auf meinem Thinkpad (bei dir sicher auch) so aussieht:

battery BAT0 0000080 00000001

Wenn du dir nun /etc/acpi/handler.sh anschaust wirst du dort schon eine Abfrage für BAT0 Action mit dem Ereigniss 00000001 sehen (Das bedeutet: Battery ist present und bekam ein Signal).
Mit acpi_listen kannst du deine acpi-Events verfolgen. Für die Batterien werden Ereignisse gesendet bei: An/Abstecken des Netzteils, Ein/Ausbau von batterien und - hier wirds spanned - wenn ein Alarm auftritt.

Wenn du etwas Shell-scripten kannst, dann kannst du dir was Nettes basteln:

cat /proc/acpi/battery/BAT0/*

zeigt dir alles was du brauchst. alarm dürfte schon einen bestimmten Wert an mWh haben. Sobald im handler.sh Skript jetzt ein Ereigniss auf BAT0/00000001 geworfen wird dann fragst du "remaining capacity" ab. Wenn dieser Wert unter dem von alarm liegt dann kannst du Maßnahmen einleiten: piepen, warnen, Suspend, Runterfahren,...
Den Wert von alarm kannst du selbst setzen, aber ein guter Default wird eigentlich von der Batterie selbst vorgegeben.

Abfragen kannst du diese Werte nicht nur über Auslesen von /proc/acpi/* Files, auch acpitool -b / -B bieten gute Möglichkeiten.

So mußt du keinen cronjob o.ä. haben, der ständig fragt, sondern reagierst "ganz modern" auf Ereignisse von acpid. NB: Anders machen das die Powermanager von KDE/Gnome oder laptop-mode-tools auch nicht...

Wenn du garnichts mit Programmieren/Skripten anfangen kannst dann kann ich dir irgendwann auch was schreiben...

zauser

Hallo GerBra,

erst einmal herzlichen Dank für die ausführliche Antwort!!! Jetzt bin ich endlich zum Testen gekommen. Nach der Installation von laptop-mode-tools und einem entsprechenden Eintrag in der rc.conf musste ich leider feststellen, dass das Notebook wieder einfach ausging und nicht davor heruntergefahren ist. Mit dem Shell-Scripten bin ich nicht so vertraut, obwohl ich dem nicht abgeneigt bin. Gemäß der Datei /etc/laptop-mode/laptop-mode.conf wird laptop-mode immer dann gestartet, wenn das Notebook batteriebetrieben ist; müsste also passen.

In der /etc/acpi/handler.sh steht dazu Folgendes:

battery)
        case "$2" in
            BAT0)
                case "$4" in
                    00000000)   #echo "offline" >/dev/tty5
                    ;;
                    00000001)   #echo "online"  >/dev/tty5
                    ;;
                esac
                ;;
            CPU0)	
                ;;
            *)  logger "ACPI action undefined: $2" ;;
        esac
        ;;

Nachdem ich mich leider nicht so damit auskenne, bin ich für jede Unterstützung dankbar, um das System zum Herunterfahren bei niedrigem Batteriestand zu bewegen. Besten Dank im Voraus!

anomander

Vielleicht kannst Du das selbstskripten ja noch umgehen...

Das automatische runterfahren mit Laptop-Mode-Tools wird in der Datei

/etc/laptop-mode/conf.d/auto-hibernate.conf

geregelt.

Da muss drinstehen:

ENABLE_AUTO_HIBERNATION=1

Außerdem musst Du das entsprechende Programm zum runterfahren / hibernate angeben, bei mir:

HIBERNATE_COMMAND=/usr/sbin/pm-hibernate

oder halt alternativ z.B. "/usr/sbin/shutdown -h now" zum herunterfahren.

Außerdem müssen noch die entsprechenden Batterielevel zum hibernate/shutdown angegeben werden.

Das funktioniert (ebenso wie die Skrip-Lösung) allerdings nur, wenn die Batterie noch funktioniert und nicht irgendwann einfach von X % auf Null fällt (wegen kaputten Zellen o.ä.).

LessWire

Herunterfahren bei Restkapazität=ca. 1 % halte ich schon für äußerst knapp, ich wähle da lieber 5 %.

Dazu kommt (wie von anomander schon bemerkt), daß die Leistung der Akkus (meistens) nach ca. 2 Jahren deutlich nachlässt - dann kann man sich auf die Kapazitätsangaben insbesondere <20% nicht mehr verlassen, da geht's dann immer schneller runter.
Man könnte das Script so schlau machen, daß es diese zunehmenden Verluste erkennt und dementsprechend immer "früher" reagiert. 😉

VG, LW.

zauser

Besten Dank an Euch!!!

Ich ging gemäß der Anleitung von anomander vor und staunte beim anschließenden Neustart nicht schlecht als das System nach kurzem Bootvorgang wieder herunterfuhr. Es liegt wahrscheinlich daran, dass das Notebook momentan ohne Batterie betrieben wird. Es soll aber nicht so sein, dass ich unbedingt den Akku benötige, um den Rechner hochfahren zu können. Dank eines Lubuntu-Bootsticks konnte ich die Änderungen auch ohne Akku wieder rückgängig machen 🙂

In der Datei /etc/laptop-mode/laptop-mode.conf habe ich doch deswegen Folgendes drinstehen:

# Enable laptop mode when on battery power.
#
ENABLE_LAPTOP_MODE_ON_BATTERY=1
#
#
# Enable laptop mode when on AC power.
#
ENABLE_LAPTOP_MODE_ON_AC=0

Warum funktioniert das nicht?

portix

anomander schrieb oder halt alternativ z.B. "/usr/sbin/shutdown -h now" zum herunterfahren.

Das müsste "/sbin/shutdown -h now" sein, ohne /usr.

anomander

portix schrieb
anomander schrieb oder halt alternativ z.B. "/usr/sbin/shutdown -h now" zum herunterfahren.
Das müsste "/sbin/shutdown -h now" sein, ohne /usr.

Jep.. vollkommen richtig - my bad

Das Problem mit dem runterfahren / hibernate ohne Akku hatte ich noch nie und das find ich wirklich seltsam.
Zumal ACPI auch keinen Batterielevel liefern sollte, wenn keine drin ist 😉

Vielleicht probierst Du in der laptop-mode.conf mal aus:

DISABLE_LAPTOP_MODE_ON_CRITICAL_BATTERY_LEVEL=1

Damit sollte laptop-mode nichts mehr machen, wenn die Batterie "kritischen" Zustand hat (vielleicht ist nicht-vorhanden = kritisch 😃 )
Wobei das ja eigentlich schon mit der Option "on-AC" abgedeckt sein sollte.

Aber sonst fällt mir dazu erstmal nix ein.

zauser

Die vorgeschlagene Einstellung in der /etc/laptop-mode/laptop-mode.conf

DISABLE_LAPTOP_MODE_ON_CRITICAL_BATTERY_LEVEL=1

ist schon standardmäßig so.

In der Datei /etc/laptop-mode/conf.d/auto-hibernate.conf habe ich den Eintrag zum Herunterfahren aus der ~/.icewm/preferences übernommen, so dass mir das mit dem "/usr" gar nicht aufgefallen ist 🙂

ENABLE_AUTO_HIBERNATION=1
...
HIBERNATE_COMMAND=sudo /sbin/shutdown -h now

Leider bin ich nun ziemlich ratlos und mit dem Shell-Skripten nicht vertraut. Evtl. kann mir von Euch noch jemand Unterstützung leisten; besten Dank im Voraus!

deviant

Mal ne janz doofe Frage: Du hast doch neben laptop-mode auch acpid in die Daemons-Liste eingetragen, oder?^^

Was ich an dem genannten Vorschlag nicht verstehe ist folgendes: Bei kritischem Ladezustand sollen die laptop-modes ausgeschaltet werden, aber bei unter x% solls herunterfahren? Das halte ich für genau falschherum. Eine nicht vorhandene Batterie dürfte 0% senden, nicht aber "critical" (jedenfalls zeigt das tint2 bei mir, wenn ich meine Batterie nachträglich entferne). Damit wäre alles beim Alten und das System fährt sich ohne Batterie herunter. Stattdessen müsste gerade ein kritischer Akkuladezustand benutzt werden, um den hibernate auszulösen.

Und wo ich schon bei tint2 bin: Solltest du es auch benutzen, wäre der allereinfachste Weg, über die Einstellungen einen Wert für "Battery Low Status" anzugeben und dann als "Battery Low Action" zum Beispiel "sudo /sbin/shutdown -h now" anzugeben...denn deine laptop-mode configs scheinen ersteinmal korrekt...

GerBra

Ich würde es - wie gesagt - über den acpid machen anstatt mit laptop-mode-tools.

acpid also installieren und per DAEMON starten lassen.
Dann folgendes Skript in /usr/local/bin/my-batcheck.sh erstellen:
//Edit: Bessere Version, in der ein Shutdown automatsich abgebrochen wird wenn das netzteil wieder angeschlossen ist

#!/bin/sh
#
## => Batterie Nummer
BAT="BAT0"
#
AC=$(< /sys/class/power_supply/AC/online)
alarm=$(< /sys/class/power_supply/$BAT/alarm)
energy=$(< /sys/class/power_supply/$BAT/energy_now)
## => Was getan werden soll, hier wird in 2 Minuten runtergefahren
action="shutdown -h -P +2 Low battery shutdown!!!"

# mache nichts wenn am Netzteil bzw. cancel shutdown
if [ "$AC" == "1" ]; then
    # shutdown abbrechen wenn schon eingeleitet...
    pidof shutdown && shutdown -c Cancel, AC present!
    exit
fi

# Wenn die aktuelle Kapazität kleiner oder gleich dem Wert in alarm ist dann mache was
if [ $energy -le $alarm ]; then
    logger "BAT0 emergency shutdown!!!"
    $action &
fi

Dieses Skipt muß root gehören und ausführbar sein.

In /etc/acpi/handler.sh genügt dann folgendes:

....
BAT0)
                case "$4" in
                    00000000)   #echo "offline" >/dev/tty5
                    ;;
                    00000001)   #echo "online"  >/dev/tty5
                                /usr/local/bin/my-batcheck.sh
                    ;;
                esac
...

Wenn der vorgegebene Alarm-Wert für den Akku:
< /proc/acpi/battery/BAT0/alarm
zu wenig ist damit der shutdown in z.B. 2 Minuten auch noch passieren kann, dann kannst du z.B. in der /etc/rc.local für alarm einen anderen Wert in Miliiwatt/Stunde angeben:
echo 3000 > /proc/acpi/battery/BAT0/alarm

Der acpid löst nun einen Battery-Event aus, sobald z.B. die Batterie den Aalrm-Wert erreicht. Somit wird dann das Skript ausgeführt. Einen bereits angestoßenen shutdown kann root übrigens wieder mit:
shutdown -c
abbrechen... (Wenn du z.B. in Windeseile das netzteil anschließt...)
//Edit: Skript geändert sodaß dieser Abbruch des shutdowns automagich eingeleitet wird....

zauser

Zunächst einmal besten Dank an alle!

@deviant: Sowohl acpi als auch laptop-mode habe ich bei den DAEMONS in der rc.conf eingetragen. Leider - warum auch immer - hat die Änderung des Eintrages in

DISABLE_LAPTOP_MODE_ON_CRITICAL_BATTERY_LEVEL=0

in der /etc/laptop-mode/laptop-mode.conf nichts verändert!

@GerBra: Ein riesiges Dankschön für Deine Bemühungen! Voller Tatendrang habe ich gleich Deinen Vorschlag wie folgt vollzogen:

# nano /usr/local/bin/my-batcheck.sh (als root)
das Script von Dir hineinkopiert und gespeichert
chmod u+x /usr/local/bin/my-batcheck.sh
# nano /etc/acpi/handler.sh
Datei um den beschriebenen Zusatz erweitert und gespeichert

Soweit so gut, nach einem heutigen Test schaltete sich der Rechner wieder einfach aus! Gerade eben merkte ich aber, dass es /proc/acpi/battery/BAT1/alarm und nicht /proc/acpi/battery/BAT0/alarm heißt. In der /etc/acpi/handler.sh steht immer BAT0 und nicht BAT1. Liegt es vielleicht daran? Einfach den Ordner umbenennen?

portix

zauser schrieb Soweit so gut, nach einem heutigen Test schaltete sich der Rechner wieder einfach aus! Gerade eben merkte ich aber, dass es /proc/acpi/battery/BAT1/alarm und nicht /proc/acpi/battery/BAT0/alarm heißt. In der /etc/acpi/handler.sh steht immer BAT0 und nicht BAT1. Liegt es vielleicht daran? Einfach den Ordner umbenennen?

Du musst das schon in /etc/acpi/handler.sh anpassen, die Verzeichnisse in /proc kann man nicht umbenennen, da /proc ein virtuelles Filesystem ist.

GerBra

Hast du mehrere Akkus im Laptop? BAT fängt eigentlich immer bei 0 an, mein Zusatzakku im UltraBay ist z.B. BAT1...

Zeige ggf. mal die Ausgabe von:
acpitool -B
(acpitool muß installiert sein...)

zauser

Die Chancen stehen also nicht schlecht, dass es daran liegt, da die Ausgabe von acpitool -B das Folgende zeigt:

# acpitool -B
Battery #1     : slot empty

Dass der Slot empty ist, glaube ich gerne, da momentan keine Batterie im Fach ist. Demnach wird also in meinem System die Battery als BAT1 geführt, obwohl ich über keinen Zusatzakku verfüge. Ich ersetze jetzt mal alle BAT0 durch BAT1 in my-batcheck.sh sowie handler.sh und hoffe, dass es dann funktioniert. Das Ganze würde auch erklären, warum es mit laptop-mode nicht ging. Herzliche Grüße!

GerBra

acpitool war nicht gedacht zum Prüfen ob nun BAT0 oder BAT1 (wie du siehst nummeriert acpitool in seiner Ausgabe ab 1, also menschlich - ein Kasten Bier fängt ja auch mit der ersten Flasche an, nicht mit der Nullsten <g>)
acpitool sollte uns/mir lediglich zeigen wieviele Akkus du hast - was auch nur mit eingebautem Akku Sinn gemacht hätte...

Daß der einzige Akku bei BAT1 beginnt ist mir ist es bisher noch nicht untergekommen, aber das kannst du bei dir ja sehen.
Dann mußt du logischerweise das Check-Skript und auch den acpid-handler anpassen.
Wenn die Bezeichnernummer für den Akku voodooartig wechseln sollte, dann könnte man die aktuelle Nummer durch Abfragen von z.B. /sys/class/power_supply/BAT? rauskriegen...

Zum Austesten des Skripts mußt du ja nicht warten bis der Akku leer ist, du kannst ja während des Testens /proc/acpi/battery/BAT0/alarm (bzw. ggf. BAT1) höher als den aktuellen Wert in /sys/class/power_supply/BAT?/energy_now einstellen und somit die Aktion auslösen.
Auch die Aktion muß beim Testen ja nicht der Shutdown sein, ich arbeite z.B. gerne mit logger:
logger "Was auch immer ich sagen will"
landet im syslog (bei Arch in /var/log/everything.log), was sich bequem per tailf beobachten läßt...

//Edit: nutzt du (bzw. kann dein Thinpad das) den tp_smapi?
http://www.thinkwiki.org/wiki/Tp_smapi
Wenn ja, dann könnte man die Testerei ab wann z.B. runtergefahren würde recht einfach über Prozentwerte regeln. Also nicht über alarm.
Ohne tp_smapi könnte man das auch über die Ausgabe von: acpitool -b machen, was für **alle** Akkus summiert die Restlaufzeit auch prozentual ausgibt. Ab einem Fix von z.B. 5% könnte man dann die Aktion auslösen.
Das wäre ggf. sogar der bessere Ansatz für so ein Skript (wenn ich drüber nachdenke....)

Creshal

ein Kasten Bier fängt ja auch mit der ersten Flasche an, nicht mit der Nullsten <g>

Spätestens nach dem dritten Kasten fangen die auch bei null an. 😃

zauser

Es ist vollbracht - endlich funktioniert es!!! Dafür ein herzliches Dankeschön an Euch alle!!! Die Änderung von BAT0 auf BAT1 in den Scripten brachte die erhoffte Lösung.

Tp_smapi nutze ich (noch) nicht; falls mir mal gerade nichts einfällt, schaue ich mir es einmal an - ich freue mich gerade noch so, dass es endlich klappt 🙂