lange Auszeit beim Einloggen

[fischig]

Seit einigen Wochen beobachte ich, dass sich das System, devuan chimaera ohne Login-Manager, beim Einloggen eines Benutzers, egal ob root oder nicht, etwa 20s Auszeit nimmt. Wie kann ich feststellen, woran das liegt.

[fischig]

Niemand eine Idee, was da passiert sein könnte (ich hab'ja ne Idee, aber die halte ich selbst für sehr unwahrscheinlich) und weitaus wichtiger: wie man's abstellt?

[HumiNi]

Hauptverdächtige sind Netzwerk und Filesysteme, evtl. kaputte HD/SSD. Mehr kann kann man zu dieser Problembeschreibung nicht sagen. Schau in diverse Systemlogs.

[rhHeini]

Chimaera hat noch die traditionellen Logs. Brauchst halt einen Logviewer um reinzuschauen.

[fischig]

'Tschuldigung, ich habe mich vertan, das System ist daedalus, dürfte aber meiner Einschätzung nach nicht von Belang sein.

[GregorS]

'Tschuldigung, ich habe mich vertan, das System ist daedalus, dürfte aber meiner Einschätzung nach nicht von Belang sein.

Ja hast Du zwischenzeitlich denn wenigstens mal in die Logs geguckt? Du bist lange genug hier, um zu wissen, dass man da zuerst guckt.

[fischig]

Ja hast Du zwischenzeitlich denn wenigstens mal in die Logs geguckt?

Nein, ich habe mir die Liste angeguckt, aber ich weiß nicht, in welchem ich hierbei fündig werden könnte.

[GregorS]

Ja hast Du zwischenzeitlich denn wenigstens mal in die Logs geguckt?

Nein, ich habe mir die Liste angeguckt, aber ich weiß nicht, in welchem ich hierbei fündig werden könnte.

Dann fang' z.B. mit (Eingabe in einem xterm):

Code: Alles auswählen

less /var/log/syslog

an. Wenn das angezeigt wird, springst Du mit Shift-g ans Ende und suchst rückwärts, bis Du an die Stelle gekommen bist, wo Du die Pause bemerkt hast. Rund um diesen Zeitpunkt kannst Du dann gucken, was im System so los war. Üblicherweise ist das die Art, mit der ich anfange, im Nebel herumzustochern.
PS: Eine Hilfe in less bekommst Du mit einem Druck auf h.

[fischig]

Das passiert nicht an einer bestimmten Stelle, sondern bei jedem x-beliebigen login.
Ich habe das mal mit deiner Methode unmittelbar nach einem root-login gemacht und ich finde nichts.

[rhHeini]

Mein lieber fischig, Du eierst hier genauso rum wie in Deinem "grub Kernel finden"-Faden. Viel Prosa, keine brauchbaren Daten übers von Dir verkonfigurierte System, keine Logs ... Ich sag nur Bullshit in Bullshit out.

Wenn Du konkrete Hinweise haben willst musst DU konkrete Daten liefern. Wie wärs mit einem inxi -Fz und einem Syslog von so einem Bootvorgang nach Nopaste? Mit der Angabe wann Du Dich als was versucht hast einzuloggen?

Wenn Dir so etwas zu lästig oder zu ausforschend erscheint, lass es sein.

[fischig]

Mein lieber rhHeini

Der Bootvorgang dürfte hier gar keine Rolle spielen, die Auszeit kommt danach. Wie ich mich einzuloggen versuche steht im 1. Beitrag. Und wenn's dir nur ums Kritisieren geht, möchte ich gerne auf das Lesen deiner Beiträge verzichten.

[chrbr]

Du könntest als root mit einem Skript die Ausgabe von ps -aux sekündlich an eine Datei anhängen lassen. Wenn Du Dich danach auf einer anderen Konsole einloggst, dann könnte in der Datei etwas zu finden sein. Das ist mit Sicherheit nicht elegant. Vielleicht gibt es auch Programme, die so etwas von sich aus können. Es wäre aber zumindest ein Ansatz.

[fischig]

Du könntest als root mit einem Skript die Ausgabe von ps -aux sekündlich an eine Datei anhängen lassen.

Ich werde das aufgreifen, aber die Idee ist völlig neu für mich. Das muss ich durchdenken/ausprobieren.

[fischig]

Ich krieg' das momentan (noch) nicht gepacken chrbrs Vorschlag in eine entsprechende Schleife zu packen.

Lässt sich hiermit was anfangen: ich habe das Kommando einmal, unmittelbar nachdem der Benutzer „test“ auf tty1 eingeloggt wurde, einmal ausgeführt.
Eine willkürliche Anzahl der letzten Ausgabezeilen von

Code: Alles auswählen

ps -aux

Code: Alles auswählen

root      2714  0.0  0.0      0     0 ?        S    16:59   0:00 [nfsd]
root      2715  0.0  0.0      0     0 ?        S    16:59   0:00 [nfsd]
root      2724  0.0  0.0   5028   408 ?        Ss   16:59   0:00 /usr/sbin/rpc.mountd --manage-gids
root      2780  0.0  0.0   2488   900 ?        S    16:59   0:00 /usr/sbin/seatd -g video
root      2796  0.0  0.0   8908  1404 ?        S    16:59   0:00 /usr/sbin/smartd --pidfile /var/run/smartd.pid
root      2816  0.0  0.0  12844  3188 ?        Ss   16:59   0:00 sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups
root      2832  0.0  0.1 164796  5592 ?        Sl   16:59   0:00 /usr/bin/bluealsa
root      2835  0.0  0.0   4868  3164 tty1     Ss   16:59   0:00 /bin/login --
root      2836  0.0  0.0   5868  1008 tty2     Ss+  16:59   0:00 /sbin/getty 38400 tty2
root      2837  0.0  0.0   5868  1036 tty3     Ss+  16:59   0:00 /sbin/getty 38400 tty3
root      2838  0.0  0.0   5868  1040 tty4     Ss+  16:59   0:00 /sbin/getty 38400 tty4
root      2839  0.0  0.0   5868  1052 tty5     Ss+  16:59   0:00 /sbin/getty 38400 tty5
root      2840  0.0  0.0   5868  1056 tty6     Ss+  16:59   0:00 /sbin/getty 38400 tty6
root      2845  0.0  0.0      0     0 ?        S<   16:59   0:00 [krfcommd]
test      2856  0.0  0.1   7192  3800 tty1     S    17:00   0:00 -bash
test      2859  0.0  0.0   7740  3632 tty1     R+   17:00   0:00 ps -aux

[HumiNi]

Seit einigen Wochen beobachte ich, dass sich das System, devuan chimaera ohne Login-Manager

Unter devuan chimaera kann ich mir noch etwas vorstellen. Ein devuan release. Richtig?
Aber was bedeutet "ohne Login-Manager"? Du hast zwar gemessen an der Forenstatistik deutlich mehr Erfahrung als ich, aber du meldest dich doch nicht an der Konsole an, oder? Dazu passen deine Fragen nicht.
Was also ist "ohne Login-Manager"?

[fischig]

Statt login-Manager kann man auch Display-Manager schreiben. Ist dasselbe.

r du meldest dich doch nicht an der Konsole an, oder?

Ja, wo denn sonst?
Aber es passiert auch im GUI/Terminal, halt bei jedem Login. Und es ist relativ neu. Mehr weiß ich einstweilen nicht.

[baeuchlein]

Folgendes Skript schreibt alle paar Sekunden die letzten Zeilen von "ps -aux" auf die Konsole:

Code: Alles auswählen

#! /bin/bash
# Dieses Skript ruft in kurzen zeitlichen Abstaenden "ps -aux" auf und zeigt
# die davon kommenden Informationen an. Kann helfen, wenn man schaut, was
# fuer'n Programm o.ae. von irgendwas Anderem gestartet wird.
#
# Ob ich spaeter mal 'ne Hilfe mit "--help" anzeigen lassen sollte?

# Ueberpruefen, ob die spaeter vom Programm benutzten Variablen schon benutzt
# werden; wenn ja, dann besser das Programm abbrechen!
test _$ps_intervall != _ && echo -e '\aVariable "ps_intervall" wird bereits benutzt!' && exit 1
test _$read_cmd != _ && echo -e '\aVariable "read_cmd" wird bereits benutzt!' && exit 1

ps_intervall=1
#^Anzahl Sekunden -1 (!), die das Programm zwischen zwei "ifconfig"-Aufrufen
# wartet. Also: 1 entspricht 2s, 2 entspricht 3s, usw..

# Das Kommando "ps" lass' ich hier mal *nicht* suchen, bin zu faul zum Ein-
# programmieren...

read_cmd="ps -aux"

clear

while sleep 1 ; do $read_cmd>/tmp/ps_aux.txt && date>>/tmp/ps_aux.txt && clear && tail -n 24 /tmp/ps_aux.txt && sleep $ps_intervall ; done

Vielleicht hilft's ja. Ansonsten könnte auch "top" weiterhelfen, das macht sowas Ähnliches, bloß sortiert es die Ausgabe noch nach CPU-"Beanspruchung" oder anderen Kriterin.

[rodney]

Folgendes Skript schreibt alle paar Sekunden die letzten Zeilen von "ps -aux" auf die Konsole:

Code: Alles auswählen

#! /bin/bash
# Dieses Skript ruft in kurzen zeitlichen Abstaenden "ps -aux" auf und zeigt
# die davon kommenden Informationen an. Kann helfen, wenn man schaut, was
# fuer'n Programm o.ae. von irgendwas Anderem gestartet wird.
#
# Ob ich spaeter mal 'ne Hilfe mit "--help" anzeigen lassen sollte?

# Ueberpruefen, ob die spaeter vom Programm benutzten Variablen schon benutzt
# werden; wenn ja, dann besser das Programm abbrechen!
test _$ps_intervall != _ && echo -e '\aVariable "ps_intervall" wird bereits benutzt!' && exit 1
test _$read_cmd != _ && echo -e '\aVariable "read_cmd" wird bereits benutzt!' && exit 1

ps_intervall=1
#^Anzahl Sekunden -1 (!), die das Programm zwischen zwei "ifconfig"-Aufrufen
# wartet. Also: 1 entspricht 2s, 2 entspricht 3s, usw..

# Das Kommando "ps" lass' ich hier mal *nicht* suchen, bin zu faul zum Ein-
# programmieren...

read_cmd="ps -aux"

clear

while sleep 1 ; do $read_cmd>/tmp/ps_aux.txt && date>>/tmp/ps_aux.txt && clear && tail -n 24 /tmp/ps_aux.txt && sleep $ps_intervall ; done

Vielleicht hilft's ja. Ansonsten könnte auch "top" weiterhelfen, das macht sowas Ähnliches, bloß sortiert es die Ausgabe noch nach CPU-"Beanspruchung" oder anderen Kriterin.

Ich sehe da 2 Probleme:

1. wird bei jedem Schleifendurchlauf /tmp/ps_aux.txt mit neuem Inhalt ueberschrieben, Nicht die schlaue Art zu loggen
2. abgesehen von Punkt "1.", wuerde das eine sehr lange und uebersichtliche Logdatei anlegen. Eventuell Ausgabe von ps begrenzen

Mein (schlecht dokumentierter) Quick-and-Dirty Ansatz (ps-Ausgabe sortiert nach verstrichener Zeit mit tail begrenzt):

Code: Alles auswählen

#!/usr/bin/env bash

# Einstellungen
wieviel_minuten=2
log_laenge=10
ps_logdatei=/tmp/ps.log
# Einstellungen Ende

if [[ -f "${ps_logdatei}" ]]; then
  echo "Logdatei ${ps_logdatei} existiert. Breche ab"
  exit 1
fi

max=$(( 60 * wieviel_minuten ))
count=0

while [[ ${count} -lt ${max} ]]; do
  printf "Datum/Zeit: %s\n" $(date --iso-8601=seconds) >> "${ps_logdatei}"
  printf "\n" >> "${ps_logdatei}"
  ps -eo start,etime,user,pid,command --sort -etime | tail -n ${log_laenge} >> "${ps_logdatei}"
  printf "\n================================================================================\n" >> "${ps_logdatei}"
  count=$((count + 1))
  sleep 1
done

[baeuchlein]

Ich sehe da 2 Probleme:

1. wird bei jedem Schleifendurchlauf /tmp/ps_aux.txt mit neuem Inhalt ueberschrieben, Nicht die schlaue Art zu loggen

Richtig, das war allerdings gar nicht meine Absicht. Eine Anzeige darüber, was sich aktuell gerade tut, war der Sinn des Ganzen. Ich hab' leider nicht mehr dran gedacht, das genauer/deutlicher hinzuschreiben.

[GregorS]

Ich sehe da 2 Probleme:
1. wird bei jedem Schleifendurchlauf /tmp/ps_aux.txt mit neuem Inhalt ueberschrieben, Nicht die schlaue Art zu loggen

Richtig, das war allerdings gar nicht meine Absicht. Eine Anzeige darüber, was sich aktuell gerade tut, war der Sinn des Ganzen. Ich hab' leider nicht mehr dran gedacht, das genauer/deutlicher hinzuschreiben.

Aber entspricht/entspräche das nicht dem, was man mit top/htop gezeigt bekommt?

[fischig]

@baeuchlein
Ich komme mit shell-Syntax nicht zurecht. Ich verstehe nicht, was ich da tue.
Ich habe dein script als einfacher Benutzer bis zum vollständigen Einoggen eines 2. Benutzers (Wieder Erscheinen des Prompts nach PW-Prüfung) laufen lassen. Schlauer gemacht hat mich das nicht. Ich möchte die Datei ps_aux.txt ungern veröffentlichen (z.B. no paste). Eine Änderung habe ich vorgenommen: die Ausgabedatei ohne Pfadangabe, ergo sie landet im Home des Benutzers.
Neue Beobachtung: Ich habe einen Eigenbaukern 6.1. verwendet. Ich habe noch einen älteren Standardkernel (4.19.) auf dem System. Bei dem tritt die Auszeit beim Einloggen nicht auf

[baeuchlein]

Die 6er-Kernels habe ich bisher immer nur kurz ausprobiert. Ich kriege da unabhängig von der Hardware immer Fehlermeldungen bezüglich der Datenübertragung im Netzwerk, die mit früheren Kernels nicht auftreten. Daher nutze ich die 6er nicht, bis das mal behoben wird.

Ich hatte die durch mein Skript gewonnenen Informationen auch nicht als etwas gedacht, dass du 1:1 ins Internet postest. Es hätte halt sein können, dass man irgendeinen Prozess "erwischt", der sich nur während der Auszeit zeigt und wo dann vielleicht ein Hinweis auf die Problemursache bei 'rumkäme. Aber wie schon jemand oben schrob: Das kann man auch mit "top" machen.

[chrbr]

Ich habe das erste Posting so verstanden, dass der Rechner für 20s nicht zu bedienen ist. Die aufgezeichneten Ausgaben von ps könnte man im nachhinein untersuchen. Wenn top trotzdem funktioniert, dann um so besser. Vielleicht funktioniert auch eine Aufzeichnung mit script. Um das herauszufinden müsste man aber am Rechner sitzen. Außerdem ist aus der Entfernung leicht reden. Solche Art von Fehlern sind meist unangenehm.

[MSfree]

Die 6er-Kernels habe ich bisher immer nur kurz ausprobiert. Ich kriege da unabhängig von der Hardware immer Fehlermeldungen bezüglich der Datenübertragung im Netzwerk, die mit früheren Kernels nicht auftreten.

Die 6er Kernel haben kein Netzwerekproblem. Es kann aber nötig sein, passende Firmware für die verbaute Netzwerkhardware zu installieren. Vor allem Realteks haben oft Probleme, wenn man ihnen nicht aktuellere Firmware gibt.

@fischig
Ich hätte mir schon längst mal einen zweiten Rechner geschnappt und mich darüber per SSH beim Problemkind eingelogt, um den Loginvorgang an der Konsole zu beobachten.

Da du immer noch nicht (für mich) verständlich dein spezielles Loginverfahren beschrieben hast, kann ich nicht viel dazu sagen. Nur soviel, wer Devuan ohne Displaymanager nutzt, kann hier nicht viel Hilfestellung erwarten. Mit Debian und systemd geht jedenfalls alles ganz prima, weil da keine Würgarounds wegen fehlender systemd-Bibliotheken programmiert werden müssen, die bei Nichtvorhandensein zu Netzwerktimeouts führen, die dich Minuten warten lassen.

[rhHeini]

Die 6er-Kernels habe ich bisher immer nur kurz ausprobiert. Ich kriege da unabhängig von der Hardware immer Fehlermeldungen bezüglich der Datenübertragung im Netzwerk, die mit früheren Kernels nicht auftreten. Daher nutze ich die 6er nicht, bis das mal behoben wird.

Kann ich nicht bestätigen. Bookworm kommt per Default mit einem 6.1er Kernel, die tuns einwandfrei. Ich fahre seit längerem aber mit Backports, derzeit 6.10.11, ging durch die ganze Historie und geht ohne Netzwerk-Schluckauf.