Donnerstag, Juli 02, 2009
lprng debuggen
Gerade habe ich eine Stunde mit debuggen von LPRng verbracht, bis ich schlussendlich feststellen musste, dass das angebliche Druckerproblem mit einem Kaltstart des Druckers (!) gelöst werden konnte.
Dennoch ist es für die Nachwelt sicherlich von Interesse, wie man LPRng im speziellen und Druckerprobleme unter Linux im allgemeinen debuggt.
lprng ausschalten
Damit man ungestörten Zugriff auf den Parallelport hat, schaltet man kurzerhand den von Debian automatisch geladenen Druckserver aus:
# /etc/init.d/lprng stop
Module überprüfen
Anschliessend überprüfen wir grundlegend, ob die Parallelporttreiber geladen wurden:
$ lsmod | grep lp lp 11076 0 parport 34280 2 lp,parport_pc
Berechtigungen des Parallelports
$ ls -l /dev/lp0 crw-rw---- 1 root lp 6, 0 2009-07-02 13:07 /dev/lp0
Sieht gut aus. Falls der Port nicht existiert, legt man in anhand einer anderen auf diesem Blog publizierten Anleitung an.
Auf Parallelport drucken
# cat sample.ps > /dev/lp0
ACHTUNG: Drucker, die kein Postscript sprechen (würde ich nie mehr in meinem Leben anschaffen!), werden seitenweise kryptische Codes ausdrucken. Eine Beispieldatei im Postscript-Format findet sich unter samplec.ps
In meinem Fall beendete sich dieser Befehl auch nach 20 Sekunden nicht, weshalb ich ihn mit Ctrl+C von Hand abbrechen musste (ansonsten hat man nach 1-2 Sekunden wieder freie Hand, sofern die Postscript-Datei nicht gerade 50 MB gross ist ...). Hier ging mir plötzlich ein Lichtlein auf, dass das Problem wohl nicht am Druckserver selber zu suchen war, sondern irgendwo an oder zwischen dem Drucker und dem Server lag.
lprng debuggen
Wenn bis hierhin alles geklappt hat, muss das Problem wirklich an lprng liegen. Deshalb starten wir den Druckserver im Debug-Modus:
# lpd -F -D1 >&/tmp/lprng.debug &
Ich habe Werte für D von 1, 2 und 9 ausprobiert, hat alles geklappt. In /tmp/lprng.debug werden alle Statusmeldungen akribisch aufgelistet. Anhand dieser ist es im Zusammenspiel mit Google möglich, andere Leidensgenossen zu finden und eventuell sogar die Lösung des Problems präsentiert zu erhalten.
Freitag, September 07, 2007
ktrace und kdump (strace unter Mac OS X)
Das unter GNU/Linux so nützliche Tool strace findet sich leider nicht unter Mac OS X. Glücklicherweise haben die Macher Darwin aber ktrace mitgegeben, welches die identische Aufgabe erfüllt.
Informationen dazu erhielt ich über eine Dokumentationsseite von Kaspersky sowie über eine vorzügliche Präsentation von den "Kollegen" in Zürich.
Heute habe ich dieses Tool auf der Arbeit benutzt, um auf einem widerspenstigen PowerMac G5 1.6GHz die Applikation Software Update zu debuggen. Jedes Mal, wenn man diese Applikation über das Apfel-Menu aufrief, verbreiterte sich das freie Plätzchen im Dock für einige Hundertstelsekunden, ohne dass aber das Icon erschien. Das Programm konnte aus irgendeinem Grund nicht geladen werden.
Es war wieder einmal der Zeitpunkt gekommen, an dem ich mein geballtes Mac/Unix-Fachwissen anwenden konnte *höhö*
fs_usage
Zuerst einmal durfte sich fs_usage profilieren, indem es mir aufzeigen sollte, was die Applikation beim Start so alles an Dateien aufrief (fs_usage = "Zugriffe auf des Dateisystems"):
[dkf38-222:~] mario% sudo fs_usage | grep pdat 16:19:35 getattrlist /System/Library/CoreServices/Software Update.app 0.000048 Dock 16:19:35 lstat /System/Library/CoreServices/Software Update.app 0.000031 Dock 16:19:35 stat /System/Library/CoreServices/Software Update.app/Contents 0.000016 Dock 16:19:35 open /System/Library/CoreServices/Software Update.app/Contents/Info-macos.plist 0.000039 Dock 16:19:35 open /System/Library/CoreServices/Software Update.app/Contents/Info.plist 0.000018 Dock 16:19:35 open /System/Library/CoreServices/Software Update.app/Contents/Resources 0.000020 Dock 16:19:35 open Services/Software Update.app/Contents/Resources/English.lproj/InfoPlist.strings 0.000033 Dock 16:19:35 lstat /System/Library/CoreServices/Software Update.app 0.000012 Dock 16:19:35 getattrlist /.vol/234881034/22761/Contents/Resources/Software Update.icns 0.000019 Dock
Hmmm - irgendwie nicht das Gelbe vom Ei.
ktrace und kdump
Bevor ich ktrace anwenden konnte, musste ich zuerst das Executable innerhalb des .app-Ordners ausfindig machen (.app-Bundles - dafür sollten die seligen NeXT-Entwickler den think eMeidi Liftetime Achievement-Award erhalten):
/System/Library/CoreServices/Software\ Update.app/Contents/MacOS/Software\ Update
Mit dieser Erkenntnis ausgerüstet, konnte ich mit der Brechstange ktrace hinter den Prozess:
[dkf38-222:~] mario% sudo ktrace /System/Library/CoreServices/Software\ Update.app/Contents/MacOS/Software\ Update
Nichts geschah. Häh? Erst nach reichlichen Überlegungen und Konsultationen von Web-Sites bemerkte ich die nun in ~ liegende ktrace.out, deren man nun mit kdump die Geheimnisse entlocken musste:
[dkf38-222:~] mario% sudo kdump
668 ktrace RET ktrace 0
668 ktrace CALL execve(0xbffffdff,0xbffffd7c,0xbffffd84)
668 ktrace NAMI "./Software Update"
668 ktrace RET execve -1 errno 8 Exec format error
668 ktrace CALL execve(0x9012bf18,0xbffff730,0xbffffd84)
668 ktrace NAMI "/bin/sh"
668 ktrace NAMI "/usr/lib/dyld"
668 sh RET execve 0
668 sh CALL open(0x152c,0,0)
668 sh NAMI "/usr/lib/libncurses.5.dylib"
668 sh RET open 4
668 sh CALL fstat(0x4,0xbffffaf0)
668 sh RET fstat 0
668 sh CALL load_shared_file(0x152c,0x98000,0x441d8,0xbffff900,0x4,0xbffff890,0xbffff904)
668 sh NAMI "/usr/lib/libncurses.5.dylib"
668 sh RET load_shared_file 0
668 sh CALL close(0x4)
668 sh RET close 0
668 sh CALL open(0x1560,0,0)
668 sh NAMI "/usr/lib/libSystem.B.dylib"
668 sh RET open 4
668 sh CALL fstat(0x4,0xbffffaf0)
668 sh RET fstat 0
668 sh CALL load_shared_file(0x1560,0x98000,0x1ac500,0xbffff900,0x4,0xbffff890,0xbffff904)
668 sh NAMI "/usr/lib/libSystem.B.dylib"
668 sh RET load_shared_file 0
668 sh CALL close(0x4)
668 sh RET close 0
668 sh CALL open(0x900006e8,0,0)
668 sh NAMI "/usr/lib/system/libmathCommon.A.dylib"
668 sh RET open 4
668 sh CALL fstat(0x4,0xbffffa80)
668 sh RET fstat 0
668 sh CALL load_shared_file(0x900006e8,0x98000,0x6ac4,0xbffff890,0x3,0xbffff820,0xbffff894)
668 sh NAMI "/usr/lib/system/libmathCommon.A.dylib"
668 sh RET load_shared_file 0
668 sh CALL close(0x4)
668 sh RET close 0
668 sh CALL __sysctl(0xbffffc98,0x2,0xbffffca0,0xbffffca4,0,0)
668 sh RET __sysctl 0
668 sh CALL sigprocmask(0x1,0,0x93a34)
668 sh RET sigprocmask 0
668 sh CALL open(0x797b4,0x6,0x20000000)
668 sh NAMI "/dev/tty"
668 sh RET open 4
668 sh CALL close(0x4)
668 sh RET close 0
668 sh CALL getuid
668 sh RET getuid 0
668 sh CALL getgid
668 sh RET getgid 0
668 sh CALL getuid
668 sh RET getuid 0
668 sh CALL getgid
668 sh RET getgid 0
668 sh CALL sigprocmask(0x1,0,0x93724)
668 sh RET sigprocmask 0
668 sh CALL fstat(0x2,0xbffff960)
668 sh RET fstat 0
668 sh CALL fstat(0x1,0xbffff960)
668 sh RET fstat 0
668 sh CALL sigaction(0x14,0xbffff960,0xbffff9d0)
668 sh RET sigaction 0
668 sh CALL sigaction(0x14,0xbffff960,0xbffff9d0)
668 sh RET sigaction 0
668 sh CALL sigaction(0x2,0xbffff960,0xbffff9d0)
668 sh RET sigaction 0
668 sh CALL sigaction(0x2,0xbffff960,0xbffff9d0)
668 sh RET sigaction 0
668 sh CALL sigaction(0x3,0xbffff960,0xbffff9d0)
668 sh RET sigaction 0
668 sh CALL sigaction(0x3,0xbffff960,0xbffff9d0)
668 sh RET sigaction 0
668 sh CALL sigprocmask(0x1,0,0x94128)
668 sh RET sigprocmask 0
668 sh CALL sigaction(0x3,0xbffff910,0xbffff980)
668 sh RET sigaction 0
668 sh CALL __sysctl(0xbffffa20,0x2,0xbffffa80,0xbffffa28,0,0)
668 sh RET __sysctl 0
668 sh CALL stat(0x100ef0,0xbffff8b0)
668 sh NAMI "/System/Library/CoreServices/Software Update.app/Contents/MacOS"
668 sh RET stat 0
668 sh CALL stat(0x79f24,0xbffff910)
668 sh NAMI "."
668 sh RET stat 0
668 sh CALL getpid
668 sh RET getpid 668/0x29c
668 sh CALL getpid
668 sh RET getpid 668/0x29c
668 sh CALL stat(0x79f24,0xbffff8d0)
668 sh NAMI "."
668 sh RET stat 0
668 sh CALL stat(0x1016a0,0xbffff7c0)
668 sh NAMI "/bin/sh"
668 sh RET stat 0
668 sh CALL stat(0x1016a0,0xbffff7d0)
668 sh NAMI "/bin/sh"
668 sh RET stat 0
668 sh CALL getpgrp
668 sh RET getpgrp 668/0x29c
668 sh CALL sigaction(0x14,0xbffff950,0xbffff9c0)
668 sh RET sigaction 0
668 sh CALL sigprocmask(0x1,0,0x93a34)
668 sh RET sigprocmask 0
668 sh CALL open(0x101de0,0,0x1)
668 sh NAMI "./Software Update"
668 sh RET open 4
668 sh CALL ioctl(0x4,FIODTYPE,0xbffffa60)
668 sh RET ioctl -1 errno 25 Inappropriate ioctl for device
668 sh CALL ioctl(0x4,TIOCGETA,0xbffffa30)
668 sh RET ioctl -1 errno 25 Inappropriate ioctl for device
668 sh CALL lseek(0x4,0,0,0x1)
668 sh RET lseek 0
668 sh CALL read(0x4,0xbffffac0,0x50)
668 sh GIO fd 4 read 0 bytes
""
668 sh RET read 0
668 sh CALL lseek(0x4,0,0,0)
668 sh RET lseek 0
668 sh CALL getrlimit(0x8,0xbffff9f0)
668 sh RET getrlimit 0
668 sh CALL dup2(0x4,0xff)
668 sh RET dup2 255/0xff
668 sh CALL close(0x4)
668 sh RET close 0
668 sh CALL fcntl(0xff,0x2,0x1)
668 sh RET fcntl 0
668 sh CALL fcntl(0xff,0x3,0)
668 sh RET fcntl 0
668 sh CALL fstat(0xff,0xbffffad0)
668 sh RET fstat 0
668 sh CALL lseek(0xff,0,0,0x1)
668 sh RET lseek 0
668 sh CALL sigprocmask(0x1,0,0x93a34)
668 sh RET sigprocmask 0
668 sh CALL read(0xff,0x100180,0x1)
668 sh GIO fd 255 read 0 bytes
""
668 sh RET read 0
668 sh CALL exit(0)
Hmmm. Nachdem ich mich in die Prozeduren eingelesen hatte, fielen mir folgende Zeilen auf:
668 sh CALL ioctl(0x4,FIODTYPE,0xbffffa60) 668 sh RET ioctl -1 errno 25 Inappropriate ioctl for device 668 sh CALL ioctl(0x4,TIOCGETA,0xbffffa30) 668 sh RET ioctl -1 errno 25 Inappropriate ioctl for device
Eine Google-Suche nach "ioctl -1 errno 25 Inappropriate ioctl for device" ergab zwar einige Treffer, doch ich konnte mir keinen Reim daraus machen.
Netzwerk-Einstellungen?
Durch einige gefundene Seiten sensibilisiert erachtete ich nun Netzwerk-Troubles als Ursache. Was liegt da näher, als die Netzwerkeinstellungen zurückzusetzen?
Würde die Maschine unter Windows arbeiten, wären hierzu viele komische Klicks und wohl ein Abstecher in den Registry-Dschungel nötig. Unter Mac OS X hingegen beschränkte sich der Aufwand auf ein simples:
sudo rm /Library/Preferences/SystemConfiguration/preferences.plist
Beim nächsten Zugriff auf die Netzwerkeinstellunge via Apfel-Menu > Location fand ich eine jungfräuliche Netzwerkkonfiguration vor. Leider hat auch dies nichts gebracht.
tcpdump
Nun, der Feierabend rückte unaufweigerlich näher, doch ein cooles Tool wollte ich noch ausprobieren: tcpdump. Fantastisch, was nach dem Aufruf dieses Tools alles über die Shell flimmert - in einem Unternehmens-LAN hört die TCP-Party wohl nie auf *smile*
Leider gab auch dies keine Aufschlüsse über das Problem. Immerhin weiss ich jetzt, dass IP-Adressen, die mit 224.0. beginnen, ganz besondere (Multicast-)Adressen sind ...
Labels: Debug, Linux, Mac, PC-Support
Abonnieren
