☰

Wie kann ich verhindern, dass sich ein Amok laufender Prozess bei systemd anmeldet?

tag-icon • tag-icon logs systemd
Wie kann ich verhindern, dass sich ein Amok laufender Prozess bei systemd anmeldet?

Auf meinem System gibt es einen Prozess namensDämondas etwa 100 Einträge in das systemd-Journal protokolliertalle 15 Sekunden:

Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev0. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev1. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev2. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev3. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev4. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev5. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev6. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev7. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev8. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev9. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev10. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev11. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev12. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev13. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev14. No such file or directory
Okt 11 04:58:42 scarecrow demond[1692]: [P:1692 T:108160832] src/discovery.c : 158  getHidDevices        -- failed in opening HIDDEV file: /dev/hiddev15. No such file or directory

Dadurch wird das Journal sehr schnell gefüllt und es kommt zu permanenten Festplattenzugriffen, die den Akku belasten. Die Einträge haben alle Priorität 7 (Debug).

demond ist Teil des Lexmark-Druckertreibers. Ich vermute, sie verwenden es für die WLAN-Erkennung von Geräten. Ich habe den Lexmark-Support kontaktiert und sie sagten, sie könnten den Treiber nicht ändern und es gäbe keine Möglichkeit, diese Meldungen zu unterdrücken. Und da der Treiber Closed Source ist, kann ich ihn nicht selbst ändern.

Ich weiß, dass ich Debug-Level 7 vollständig unterdrücken kann, indem ich MaxLevelStore=infoin journald.conf verwende, aber dies unterdrückt den Debug-Level füralleProzesse.

Gibt es eine Möglichkeit, die Protokollierung zu unterdrücken?für einen bestimmten Vorgangwie zum Beispiel Dämon?

Ich verwende ArchLinux mit dem neuesten systemd 208. Ich verwende weder syslog-ng noch rsyslog.

Antwort1

Es stellte sich heraus, dass es eine Umgebungsvariable namens ENABLE_D_LOG=0|1 gibt, die standardmäßig 1 ist und für den Logging-Wahnsinn verantwortlich ist. Wenn man sie auf 0 setzt, wird der Treiber heruntergefahren. Also habe ich ein Wrapper-Skript für Demond erstellt, das ENABLE_D_LOG=0 setzt und dann den ursprünglichen Demond aufruft:

# cd /usr/local/lexmark/legacy/bin
# mv demond demond.orig
# cat > demond <<EOF
#!/bin/sh
export ENABLE_D_LOG=0
/usr/local/lexmark/legacy/bin/demond.orig $@
EOF
# chmod +x demond

verwandte Informationen