Monthly Archives: Juli 2014

Eigene Chips in lm_sensors konfigurieren

Posted on by

Linux verfügt über ein großartiges Programm zum Lesen und Anzeigen von Sensorsdaten. Das Paket heißt lm_sensors. Da es aber sehr viele verschiedene Mainboards, respektive Chips auf den Boards gibt, kann es vorkommen, daß aktuelle Chips nicht richtig ausgewertet werden.

Der Chipsatz „it8721-isa-0290“ auf meinem Asusboard ist so ein Chip.

Das Problem

Wenn man sensors aufruft, erscheint z.B. so eine Ausgabe:

it8721-isa-0290
Adapter: ISA adapter
in0:          +2.82 V  (min =  +1.22 V, max =  +0.19 V)  ALARM
in1:          +2.80 V  (min =  +1.93 V, max =  +1.42 V)  ALARM
in2:          +0.80 V  (min =  +1.84 V, max =  +2.38 V)  ALARM      
+3.3V:        +3.34 V  (min =  +2.71 V, max =  +0.38 V)  ALARM
in4:          +1.20 V  (min =  +0.17 V, max =  +2.03 V)
in5:          +2.50 V  (min =  +1.18 V, max =  +2.52 V)  ALARM
in6:          +1.92 V  (min =  +1.43 V, max =  +0.23 V)  ALARM
3VSB:         +4.61 V  (min =  +3.65 V, max =  +2.76 V)  ALARM      
Vbat:         +3.36 V  
fan1:        1912 RPM  (min =  128 RPM)
fan2:           0 RPM  (min =   53 RPM)  ALARM           
fan3:           0 RPM  (min =   10 RPM)  ALARM           
temp1:        +39.0°C  (low  = -54.0°C, high = -127.0°C)  ALARM  sensor = thermistor
temp2:        +34.0°C  (low  = +19.0°C, high = -123.0°C)  ALARM  sensor = thermistor
temp3:       -128.0°C  (low  = -85.0°C, high = -32.0°C)  sensor = disabled

Wie man leicht erkennen kann, sind die meisten Min/Max Werte falsch und folglich auch die ALARM Meldungen am Ende der jeweiligen Sensoren. Das liegt daran, daß in der /etc/sensors.conf keine Einträge für diesen Chip enthalten sind.

Fügen Sie am Ende der Datei einfach folgende Einträge an:

chip "it8721-*"
 label temp1 "CPU Temp"
 label fan1 "CPU Fan"
 label in0 "Core 0"
 set in0_min 3.0 * 0.90
 set in0_max 3.0 * 1.10
 set in1_min 3.0 * 0.90
 set in1_max 3.0 * 1.10
 set in2_min 0.8 * 0.90
 set in2_max 2.0
 set in3_min 3.3 * 0.90
 set in3_max 3.3 * 1.10
 set in6_min 1.9 * 0.95
 set in6_max 1.9 * 1.05
 set in7_min 5.0 * 0.90
 set in7_max 5.0 * 1.10
 set fan2_min 0
 set fan3_min 0
 set temp1_min 0
 set temp1_max 86
 set temp2_min 0
 set temp2_max 128

und dann starten Sie sensors mal mit dem Zusatz „-s“ : sensors -s . Danach ist die Ausgabe für Ihren Chipsatz korrekt.

Sie müssen erstmal herausbekommen, welchen Chip Sie da überhaupt haben, bevor Sie das obige Nachmachen können. Dabei hilft Ihnen sensors-detect . In einem Frage- und Antwortspiel werden Sie über Ihre Chips ausgefragt. Antworten Sie nach besten Wissen und Gewissen, dann klappt das schon.

YUM: Abhängigkeitsprobleme lösen

Posted on by

Es kann vorkommen, daß einzelne Abhängigkeiten bei einem Update über mehrere Repositories nicht aufgelöst werden können. Z.b. weil im Fedora Hauptrepo eine neuere Version des Pakets verteilt werden soll, wie in den anderen Repos referenziert werden. Oder anders ausgedrückt, jemand hat sein Update noch nicht fertig und hinkt hinterher.

Am Beispiel des jüngsten QMMP Updates, möchte ich das mal verdeutlichen :

---> Paket qmmp.x86_64 0:0.7.4-1.fc20 markiert, um aktualisiert zu werden
 --> Abhängigkeit qmmp(x86-64) = 0.7.4 wird für Paket qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 verarbeitet
 --> Abhängigkeitsauflösung beendet
 --> Transaktionsprüfung wird ausgeführt
 ---> Paket qmmp.x86_64 0:0.7.4-1.fc20 markiert, um aktualisiert zu werden
 --> Abhängigkeit qmmp(x86-64) = 0.7.4 wird für Paket qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 verarbeitet
 --> Abhängigkeitsauflösung beendet
 Fehler: Paket: qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 (@rpmfusion-free-updates)
 Benötigt: qmmp(x86-64) = 0.7.4
 Entfernen: qmmp-0.7.4-1.fc20.x86_64 (@updates)
 qmmp(x86-64) = 0.7.4-1.fc20
 Aktualisiert durch: qmmp-0.7.7-1.fc20.1.x86_64 (updates)
 qmmp(x86-64) = 0.7.7-1.fc20.1
 Verfügbar: qmmp-0.7.2-1.fc20.x86_64 (fedora)
 qmmp(x86-64) = 0.7.2-1.fc20
 Sie können versuchen, mit --skip-broken das Problem zu umgehen.
 Sie könnten Folgendes versuchen: rpm -Va --nofiles --nodigest

Was steht da jetzt wirklich ?

QMMP soll von 0.7.4 auf 0.7.7 aktualisiert werden,
ABER das qmmp-plugins-freeworld-0.7.4-1 Paket braucht 0.7.4-1 und nicht 0.7.7 .

Den Vorschlag SKIP BROKEN kann man einfach vergessen. Der Zustand kommt öfter vor,
deswegen hier gleich mal die Lösung:

 #  vi /etc/yum.conf

Ans Ende der Main-Sektion schreibt man nun einfach „exclude=qmmp*“ .

Das könnte dann so aussehen :

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
exclude=qmmp*

#  This is the default, if you make this bigger yum won't see if the metadata

Ein „yum update“ wird jetzt durchlaufen. In einer Woche können wir dann mal nachsehen, ob das qmmp-plugins-freeworld Paket auf Stand ist.

Systemd schickt alte Einträge zum Syslogd

Posted on by

Die Bild-Zeitung könnte mit der folgenden Schlagzeile öffnen:

„Systemd wahnsinnig – Syslogd kurz vor dem Zusammenbruch“

Wenn man einen Produktivserver im Netz hat, möchte man solche Schlagzeilen lieber nicht lesen, dennoch können Sie passieren. Mit den folgenden kleinen Anweisungen kann man das Desaster beenden.

Aber zunächst mal zum eigentlichen Problem:

Der Syslogd läuft mit 95% CPU Last, aber ansonsten ist auf dem System nichts zu sehen, was die Nachrichten produzieren könnte. Der erste Blick geht daher nach /var/log/messages:

Jul 16 20:21:01 systemd: Started Session 29860 of user root.
Jul 16 20:21:01 systemd: Starting Session 29859 of user munin.
Jul 16 20:21:01 systemd: Started Session 29859 of user munin.
Jul 16 20:21:01 systemd: Starting Session 29862 of user root.
Jul 16 20:21:01 systemd: Started Session 29862 of user root.
Jul 25 07:34:20 rsyslogd-2177: imjournal: begin to drop messages due to rate-limiting

Was wir sehen, sind eine Flut von alten Nachrichten und die Meldung, daß imournal daran gehindert wurde, weitere Nachrichten zu loggen, weil es zu viele wurden. Was Sie oben nicht sehen ist, daß das Ganze mit Nachrichten aus April begonnen hat. 3,7 GB an Logfiles sollten nochmal durch den Syslogd gejagt werden.

Auch wenn die eigentlichen Nachrichten nicht mehr in /var/log/messages auftauchen, so verbraucht der Syslogd trotzdem noch eine Menge CPU Leistung, meistens soviel er bekommt.

Ein Neustart von syslogd machts nur schlimmer, weil die alten Nachrichten dann wieder ins Log geschrieben werden.

Die Lösung:

Man editiere /etc/systemd/journald.conf :

 [Journal]
 #Storage=auto
 #Compress=yes
 #Seal=yes
 #SplitMode=login
 #SyncIntervalSec=5m
 #RateLimitInterval=30s
 #RateLimitBurst=1000
 #SystemMaxUse=
 #SystemKeepFree=
 #SystemMaxFileSize=
 #RuntimeMaxUse=
 #RuntimeKeepFree=
 #RuntimeMaxFileSize=
 #MaxRetentionSec=
 #MaxFileSec=1month
 #ForwardToSyslog=yes
 #ForwardToKMsg=no
 #ForwardToConsole=no
 #TTYPath=/dev/console
 #MaxLevelStore=debug
 #MaxLevelSyslog=debug
 #MaxLevelKMsg=notice
 #MaxLevelConsole=info

in dem man das hier einfügt oder ändert, ganz wie Sie möchten:

[Journal]
 MaxRetentionSec=10day

Wenn man dann den Journaldienst des Systemd neustartet, werden alle alten Files aus /var/log/journal/ entfernt und der Systemd schickt nur noch 10 Tage Logs an den Syslogd. Das ist aber i.d.R.  in wenigen Sekunden durch und die Last des Systems geht auf normal zurück.

 systemctl restart systemd-journald

Als positiver Seiteneffekt werden gleich noch monatealte Logdaten gelöscht. In unserem Fall waren es satte 3 GB.

Das Ende der Orgie erkennt man im Logfile des Syslogds an dieser Meldung:

Jul 25 07:35:13 rsyslogd-2177: imjournal: 229963 messages lost due to rate-limiting

Das wäre früher oder vermutlich sehr viel später auch ohne die Anpassungen im in der journal.conf passiert.

Da aber nach 17 Minuten erst 1 Monat verarbeitet wurde, ist es aus Performancegründen des Servers ratsam das zu beschleunigen.