init-Skripte ohne Ausgabe

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

init-Skripte ohne Ausgabe

Beitrag von storm » 15.06.2013 10:40:49

Hmm, ich bin eigentlich der Meinung, dass ich mehr oder weniger jedes Problem mit Recherche und Debugging lösen kann, abgesehen von spezieller Hard- oder Software. Aber zur Zeit ist es so, dass die unstable-Kiste hier während des Bootens keine einzige Ausgabe der init-Skripte zeigt und ich trotz längerer Fehlersuche keine Ursache finde. Die Ausgaben des Kernels sind zu sehen und dann der Prompt vom getty, aber dazwischen nichts. Bin ich einmal angemeldet, kommt auch eine Ausgabe, wenn ich zum Beispiel fetchmail oder dnsmasq neustarte. Die Skripte (also rcS+rc2) werden auch ausgeführt und wenn ich in einem Skript eine Ausgabe mit Umlenkung in eine Datei einfüge, bekomme ich auch die Ausgabe in der entsprechenden Datei. Aber warum nix auf tty1? Irgend eine Idee?

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: init-Skripte ohne Ausgabe

Beitrag von rendegast » 15.06.2013 14:45:34

Irgendeine Einstellung zum log-daemon.
/etc/default/rcS, VERBOSE=yes ?


Ein Hack zum Wegblenden von iptables-Meldungen auf der Konsole war /etc/sysctl.conf

Code: Alles auswählen

#/proc/sys/kernel/printk:
# 7     4       1       7       (default, 1. Stelle relevant)
kernel.printk = 4
Wird vielleicht anders interpretiert?

/var/log/boot wird erstellt und die fehlenden Meldungen tauchen dort auf?
<-> eine vielleicht neue Einstellungen für Filtern dieser Meldungen von der Konsole.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Re: init-Skripte ohne Ausgabe

Beitrag von storm » 15.06.2013 18:58:58

rendegast hat geschrieben:Irgendeine Einstellung zum log-daemon.
/etc/default/rcS, VERBOSE=yes ?
Nope, sieht hier genauso aus und das verändert ja auch nur die Menge der ausgegebenen Informationen.
Ein Hack zum Wegblenden von iptables-Meldungen auf der Konsole war /etc/sysctl.conf

Code: Alles auswählen

#/proc/sys/kernel/printk:
# 7     4       1       7       (default, 1. Stelle relevant)
kernel.printk = 4
Wird vielleicht anders interpretiert?
Sieht hier ebenfalls genauso aus.
/var/log/boot wird erstellt und die fehlenden Meldungen tauchen dort auf?
<-> eine vielleicht neue Einstellungen für Filtern dieser Meldungen von der Konsole.
Hier wird's interessant, da der bootlogd auch schon eine Weile lang nix gespeichert hat. (Hintergrund: lange Zeit sehr zufrieden runit als Startsystem gehabt, wegen Umstieg auf 64bit und getty-Problemen wieder auf sysvinit zurück). Seit dem Umstieg zurück auf sysvinit scheint der nix mehr zu speichern.
Gerade getestet: debian-Kernel 3.9-1 installiert (vorher: selbst geklöppelter 3.9.5) und siehe da, Meldungen alle wieder da. Mal schauen, ob ich die Ursache in der .config finde.
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Re: init-Skripte ohne Ausgabe

Beitrag von storm » 25.06.2013 13:35:39

Ominös. Die Ursache dafür, dass weder ein bootlog geschrieben wurde noch eine Ausgabe der rc-Skripte auftauchte, waren die fehlenden devices /dev/stdout und /dev/stdin (jeweils Link auf /proc/self/fd/*). Seltsamerweise wurde stderr manchmal erzeugt und manchmal nicht. Da es mit dem debian-Kernel funktionierte, hab ich die Ursache im diff der .config-Dateien gesucht. Neben einigen anderen "Altlasten" fehlte zum Beispiel auch CONFIG_DEVTMPFS in der .config des selbstgebauten Kerns und irgendeine Änderung (vor kurzem) am init-system hat schließlich dazu geführt, dass das so nicht mehr funktioniert hat. Den genauen Hergang, also warum zB. trotzdem ein ramfs für /dev existierte und nur wenig Unterschiede zum regulären Aussehen zu erkennen waren bzw. warum genau die fehlenden Geräte nicht angelegt wurden, kann ich auch nicht erklären.

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Antworten