Start von TLP unter Arch Linux

[Evilandi666]

Linrunner weißt du zufällig wieso

/usr/sbin/tlp xlogin

unter Awesome WM nicht funktioniert?

Dieser Befehl wird ja von Gnome aufgerufen (via /etc/xdg/autostart) um die TLP anzuschmeißen, aber Awesome ignoriert /etc/xdg/autostart, also habe ich /usr/sbin/tlp xlogin entsprechend in .xinitrc aufgerufen, auch innerhalb des Policykits. Müsste eigentlich 1 zu 1 analog wie bei Gnome sein. Oder benötigt das Root Rechte? (wobei das bei Gnome ja auch nur User Rechte haben sollte, eigentlich). (Was xlogin genau macht scheinst du auch nirgendwo erklärt zu haben )

Es tut aber nicht

Äußert sich so: Scheduler der SSD nicht geändert, usw...

sudo tlp start hilft dem ganzen auf die Sprünge...

An der Konfig kann es übrigens nicht liegen, die geht unter Gnome, was ich parallel drauf habe.

Wieso kann gnome tlp mit /usr/sbin/tlp xlogin starten aber awesome nicht?

Debug hab ich angemacht, keinerlei auffälligen Logs außer dass der mode auf xlogin gewechselt wurde..mhh

Edit:

Ach xlogin macht ja garnichts, wenn ich mir /usr/sbin/tlp so ansehe .. jetzt bin ich verwirrt .. wie aktiviert gnome 3 dann tlp beim login? (vor dem login wird ja nur via /etc/rc.d/tlp die Devices (wifi,usw.) korrekt gesetzt).

 

[linrunner]

Die eigentlichen Stromsparfunktionen werden beim Systemstart nicht über ein Startskript aufgerufen, sondern implizit vom Powermanagement der Distribution. Die Architektur (in Debian/Ubuntu/openSUSE) ist wie folgt:
1. upower(d): reagiert auf ACPI-Ereignisse und ruft pm-powersave true (BAT) bzw. false (AC) aus pm-utils auf
2. pm-utils/pm-powersave: arbeitet die Skripte in /usr/lib/pm-utils/power.d/ ab, darunter auch zztlp
3. zztlp: ruft tlp true bzw false auf.

Wie jetzt 1. mit Arch/awesome zu implementieren ist, weiß ich nicht. Ich verlasse mich darauf, daß ich vom pm-utils gerufen werde.

Das bisher gesagte findet der geneigte Leser übrigens zum großen Teil in der TLP Programmdokumentation .

Laß doch bitte von einem Mod diese Diskussion in einen eigenen Thread mit passendem Titel verlagern, wir verlassen hier das Gebiet des normalen Benutzersupports ...

ps. tlp xlogin tut derzeit übrigens nichts, ich habe nur die Infrastruktur nicht entfernt (absichtlich).

 

[Evilandi666]

Mhh danke, aber upowerd läuft ja automatisch und "sollte" eigentlich gehen.(da kann man manuell gar nicht viel machen).

Die Programmdoku hab ich schon angeschaut, aber du erwähnst upowerd nicht an einer Stelle auf der Seite :huh:

Naja, also von mir aus brauchen wir nicht schieben, mir fällt grad ehrlich gesagt nicht ein wo die Lösung liegen könnte, und tlp per rc.local starten tut es es zur Not auch erstmal, keine Ahnung was Gnome da anders macht :/

Edit: Tatsächlich startet der upowerd Daemon nicht bei awesome, aber wie startet Gnome den? Da gibts ja keinen Befehl dafür :/

Edit2: Also upowerd wird automatisch gestartet sobald eine beliebige Anwendung drauf zugreift, bei Gnome macht das vermutlich irgendein Bestandteil davon (gnome-power-manager? -> Abfrage AC/Battery). Da TLP es nicht macht und bei Awesome auch kein anderes Programm, muss man es manuell anstoßen. Eigentlich wäre das nicht schlimm, weil upowerd bei Bedarf gestartet wird, allerdings wird TLP eben nur dadurch gestartet. Sprich es setzt einen WM voraus der durch irgendeine Abfrage upowerd startet.
Kann man aber ziemlich easy mit einem "/usr/bin/upower -e &> /dev/null" beheben in .xinitrc beispielsweise, damit wird upowerd nach allen Stromdevices gefragt und dabei auch gestartet. (upower ist der Client).

-> Problem gelöst.

Allerdings wäre es doch schöner wenn das Startskript auch einfach den kompletten TLP Startvorgang machen würde, aber Linrunner hat bestimmt Gründe warum es erst nach dem Login starten soll

Danke jedenfalls

Jetzt kann der "normale Benutzersupport" weitergehen, sry. für die kleine Unterbrechung

 

[linrunner]

@Mods: Danke fürs Herauslösen.

@Evilandi666: nun zu deiner Frage warum nicht alle TLP-Funktionen über das Init-Script aufgerufen werden:

• TLP muss in jedem Fall vom Powermanagement gerufen werden um den Wechsel der Stromquelle mitzubekommen
• Ich möchte verhindern, daß TLP beim Systemstart von unterschiedlichen Aufrufern zweimal gestartet wird, insbesondere nicht zufällig gleichzeitig (vorbeugendes Locking wäre ja nur eine Umgehung)
• Bei den von mir selbst untersuchten Distris (mit GNOME/KDE/LXDE) besorgt beim Systemstart das Powermanagements zuverlässig auch für den Aufruf von pm-utils/pm-powersave.
• Außerdem wird dort upower völlig unabhängig von bzw. vor der Benutzeranmeldung gestartet - der Prozess läuft mit Root-Rechten.

Fazit: aus meiner Sicht ist die Frage zu klären, ob es bei Arch für die alternativen Desktops einen vorgesehenen Weg gibt upowerd im Systemstart aufzurufen, alternativ einen anderen Weg pm-powersave zu rufen. Dieser Weg wäre dann im Archwiki zu dokumentieren.

 

[Evilandi666]

upowerd wird nicht explizit aufgerufen sondern bei der ersten Anfrage gestartet - soweit hab ich das herausgefunden.

Ich denke mal GDM/KDM/usw. machen einfach so eine Abfrage nach der Stromquelle, woraufhin upowerd läuft.

Es scheint keinen anderen Weg zu geben, upowerd zu starten, zumindest habe ich vergeblich danach gesucht und gegoogelt. Scheinbar nutzt auch niemand TLP ohne Gnome/KDE/XFCE im Netz

Als Alternative zum o.g. Vorschlag könnte man doch /usr/sbin/pm-powersave von Hand aufrufen - oder?

 

[linrunner]

Wegen Wechselerkennung für die Stromquelle muß doch upowerd sowieso gestartet werden. upower -e läßt sich auch als Root aufrufen, gibt es so etwas wie eine /etc/rc.local in Arch?

EDITH meint noch: pm-powersave geht nur mit Parameter. Die Chose muß aber mit AC und BAT laufen ...

 

[Evilandi666]

Wegen Wechselerkennung für die Stromquelle muß doch upowerd sowieso gestartet werden. upower -e läßt sich auch als Root aufrufen, gibt es so etwas wie eine /etc/rc.local in Arch?

Ja klar geht das, so mach ich das ja auch, nur ich mach es halt erst nachdem Login via .xinitrc, aber prinzipiell sollte das auch per /etc/rc.local gehen.

Man muss halt irgendwie einmal mit upower eine Anfrage stellen, danach rennt upowerd als root. (auch wenn die Anfrage von einem upower (=client) mit Userrechten kommt).

Wie gesagt, prinzipiell ist das eigentlich gelöst.

 

[g3eB4Y]

ich hab heut versucht das Problem in einer VM zu reproduzieren, allerdings weiß ich nicht welche Methode du zum Starten von X/Awesome nutzt? Ein LoginManager (gdm, slim ...) oder startest du direkt startx?

Hintergrund meiner Frage ist folgender: im Wiki Artikel von awesome steht "When you do not use a login manager, nothing is automated." - könnte das schon der Grund sein, warum upowerd bei gnome gestartet wird, bei awesome aber nicht?

Desweiteren halte ich die Lösung .xinitrc für falsch, weil TLP als Daemon unabhängig vom Nutzer-Login und vor dem X-Start gestartet wird (ich glaube sogar Init 3), während .xinitrc erst nach X-Start (init 5) gerufen wird und das sogar abhängig vom Nutzer... Ein zweiter Nutzer könnte TLP trotzdem nicht verwenden...

 

[Evilandi666]

Ich weiß doch, ich kann es auch in die rc.local packen, dass dauert 2 Sekunden.

Ich nutze Slim übrigens, das macht auch praktisch nichts automatisch. Den Grund warum es nicht startet hatte ich ja bereits geschrieben...

Wie gesagt, für mich ist es gelöst. :thumbup:

 

[linrunner]

@Evilandi666: ja doch, das hab ich verstanden . Dennoch wäre eine "allgemeingültige" Lösung interessant.

@g3eB4Y: deine Schlußfolgerung .xinitrc betreffend ist richtig, allerdings treffen deine Argumente nicht zu: es gibt keinen TLP-Daemon, nur ein Start/Stop-Skript für Funk+Ladeschwellen. Als Daemon fungiert der upowerd. Eine Betrachtung von Benutzern ist nicht nötig.

 

[g3eB4Y]

das stimmt, da hast du recht!

Sind wir uns sicher, das irgendein gnome Programm (zb der Power Settings Daemon) upower implizit startet? Oder könnte es auch gdm sein? Oder irgendetwas anderes? Ich glaube zwar, dass gnome-power-manager upower explizit startet. Immerhin ist upower eine Abhängigkeit von gnome-power-manager... aber das ändert nix...

Wenn es ein Gnome Programm sein sollte, das upower startet, egal ob implizit oder explizit, wäre die rc.local Methode ok...

 

[Evilandi666]

Mit Sicherheit fragt gdm die vorhandenen Energiequellen ab, danach läuft upowerd. Genau das mach ich auch in meiner Lösung - nur ich benötige die Info nicht, daher /dev/null.

@linrunner allgemein wäre Komplettstart via Startskript machbar, die vorhandenen Stromquellen kannst du mit upower abfragen. Danach ist upowerd sicher aktiv - und TLP kann auf die Events reagieren wie bisher.

Wer nachher upowerd durch seine Anfrage startet, ist egal, der Kernel startet upowerd sobald die erste Anfrage eingeht - explizit starten kann man upowerd wohl gar nicht.

Grüße,
Andreas

Edit: So... die android korrektur mal korrigiert^^

 

[Evilandi666]

Kurze Rückmeldung:

"/usr/bin/upower -e &> /dev/null" in /etc/rc.local klappt ebenfalls bestens.

Ich muss eine der obigen Aussagen korrigieren, /usr/bin/upower -e zeigt grundsätzlich alle Stromquellen an, bringt dem Linrunner also herzlich wenig:

(Beispiel beim R400 nur Akku, kein Netzteil dran)

/org/freedesktop/UPower/devices/line_power_AC
/org/freedesktop/UPower/devices/battery_BAT0

Ich vermute mal dass man via dbus-send dann genaueres Abfragen kann, welche davon aktiv sind usw., aber das ist nur eine Vermutung. Entschuldigt die falschen Infos

 

[linrunner]

allgemein wäre Komplettstart via Startskript machbar

Hab ich oben schon erklärt, dass das zu doppelten parallelen Aufrufen führt.

Ich habe gestern nochmal ein frisch installiertes Kubuntu 11.10 angeschaut und mußte feststellen, daß dort der upowerd auch erst nach der Anmeldung angeworfen wird.

Meine vorläufige Schlußfolgerung aus dieser interessanten Diskussion: ich werde wohl ein upower -e ins Init-Script aufnehmen .

 

[Evilandi666]

Hab ich oben schon erklärt, dass das zu doppelten parallelen Aufrufen führt..

Das war mMn kein richtiges Argument. Wenn TLP "nur" durch das Skript gestartet* werden kann und ansonsten von upower/usw. bei Stromquellenwechsel aufgerufen wird, ist das durchaus machbar, denke ich jedenfalls. Zumal man das Verhalten auch erwarten würde, wenn es schon ein Initskript gibt. Ich kann aber durchaus verstehen, dass du keine Lust hast mal kurz alles umzuschreiben

Ich habe gestern nochmal ein frisch installiertes Kubuntu 11.10 angeschaut und mußte feststellen, daß dort der upowerd auch erst nach der Anmeldung angeworfen wird. Meine vorläufige Schlußfolgerung aus dieser interessanten Diskussion: ich werde wohl ein upower -e ins Init-Script aufnehmen .

Sehe ich auch so - nur dann wird TLP ja im Endeffekt doch per Init-Skript (wenn auch indirekt) aufgerufen

Es fehlt einfach ein TLP Daemon

*= Es ist ja eh nur ein setzen von Optionen, da TLP ja kein Daemon o.Ä. ist

 

[linrunner]

*seufz*

Ich versuchs nochmal zu erklären. Wenn ich das vollständige TLP auch im Initscript aufrufe, würde folgendes passieren:

1. wird tlp start aufgerufen und macht seine Einstellungen (Stromquelle wird selbst festgestellt)
2. wird upowerd irgendwann vom System gestartet, prüft die aktive Stromquelle und startet (via pm-powersave) tlp ac bzw. bat, welches die Einstellungen macht

Beides passiert unabhängig voneinenander und asynchron, aber lt. Murphy mit einer Wahrscheinlichkeit > 0 parallel. Das will ich aber nicht, u.a. weil ich keine Lust habe daraus resultierende merkwürdige Fehler zu analysieren. Daher bevorzuge ich eine saubere Architektur wo die Stromsparfunktionen von genau einer Stelle aus aufgerufen werden, also via upower/pm-utils. Die bleibt auch dann sauber, wenn TLP selbst dafür sorgt, daß der upowerd läuft .

 

[Evilandi666]

Ich empfinde das nicht als Problem - die Initskripte werden doch vor den Displaymanagern abgearbeitet, und diese starten frühestens upowerd durch eine Anfrage.

Somit wäre das also eigentlich kein großes Problem meiner Meinung nach, außer dass eben mal tlp bat/tlp ac am start "unnötig" aufgerufen wird, weil tlp diese werte ja beim Start schon gesetzt hat.

(Vorallem stößt das Initskript jetzt upowerd an, was daraufhin TLP anstößt, was zwar einfacher ist für dich (Bugfixing etcpp. wie du sagtest), aber eigentlich nicht so schön.)*

Aber du darfst das gern halten wie du magst, brauchst dich nicht rechtfertigen

(zumal jeder der will es ja selbst ändern kann, so ist es ja nicht.)

Probleme wird es so oder so immer geben - dafür ist die Linuxwelt einfach zu unterschiedlich & vielfältig.

Edit: Argh du hast ja was rauseditiert - somit ergibt * natürlich keinen Sinn mehr

 

[linrunner]

die Initskripte werden doch vor den Displaymanagern abgearbeitet

Diese Annahme hält nicht, und zwar spätestens dann, wenn upstart oder systemd parallel zu verbliebenen Initskripten ins Spiel kommen ...

 

[Evilandi666]

Nur die Reihenfolge der Initskripte ist doch variabel, aber der Aufruf eines Displaymanagers erfolgt doch immer am Schluss afaik*. Selbst falls das nicht so wäre, lässt systemd/upstart auch die Definition von Abhängigkeiten zu.

* = Stark distriabhängig, klar, müsste man nachsehen.