Inhalt

17. Fehlersuche

Sollte Das alles trotz meiner Anleitung noch nicht auf Anhieb funktionieren, so gibt es noch diverse Möglichkeiten, einen Fehler aufzuspüren.

Wichtigstes Tool hierzu ist das Programm ifstat, welches anzeigt, welche Pakete für welche Adresse bereit liegen. Hier sollte man sich nicht wundern, wenn die Pakete nach dem Start von ifpoll plötzlich geschrumpft sind, das liegt nämlich daran, daß die Mails dann zu ZIP-Files gepackt wurden.

17.1 Mail wird nicht verarbeitet

Hier ist es sinnvoll, das Debug-Level von rfc2ftn in /etc/smail/transports bzw. im /etc/sendmail.cf hochzusetzen. Hierzu gibt man im entsprechenden Netz den zusätzlichen Parameter -v bei rfc2ftn an (ggf. auch mehrfach, dann wird das Debug-Level entsprechend höher, ich verwende meist -vvvvvvvvvvvvvvvvvvvvv oder so). Um die Debug-Meldungen dann wirklich in die Hand zu bekommen, schicke ich die Mail einfach mit einer Kopie an eine nicht existente Adresse und bekomme dann den Rückläufer mit sämtlichen Debug-Meldungen. Kommt der Rückläufer überhaupt nicht, so kann es durchaus sein, daß irgendwelche Permissions nicht stimmen und das System einfach wartet (man sieht das daran, daß noch sendmail und rfc2ftn als Prozesse laufen). Dann findet sich das aktuelle Debug-File in /var/spool/smail/msglog. Unter /var/spool/smail findet man dann auch die liegengebliebenen Messages. Bei Verwendung von Sendmail werden die Log-Meldungen dagegen per syslog ins Syslogfile geschrieben, während die liegengebliebenen Messages in /var/spool/mqueue landen.

17.2 News werden nicht verarbeitet

Analog zum Vorgehen bei Mail kann man auch bei News verfahren. Hier gehe ich gewöhnlich so vor, daß ich in /usr/lib/newsbin/batch/viafido (cnews) bzw. /usr/local/lib/news/send-fidogate (INN) die entsprechenden -v's einbaue und dann an die entsprechende Zeile ein 2> /tmp/fgate.out anhänge, was dazu führt, daß stderr nach /tmp/fgate.out umgeleitet wird, das ich mir dann anschauen kann.

Ansonsten sollte man bei cnews zwischen dem Aufruf von newsrun und run-batch nachsehen, ob der Artikel in /var/spool/news/out.going/*/togo aufgelistet wurde und dort anschließend auch wieder gelöscht wurde. Manchmal (je nach cnews-Version) werden die Artikel auch in /var/spool/news/in.coming zwischengelagert.

Bei INN sollten die Artikel sofort ins Newssystem aufgenommen werden, und damit auch direkt im File /var/spool/news/out.going/* erscheinen. Nach dem send-fidogate sollten sie dort verschwinden und im Fido-Outbound landen.

Weiterhin sollte man sich alle vorhandenen Logfiles ansehen:

smail

/var/spool/smail/log/logfile

Sendmail

/var/log/mail

cnews

/var/lib/news/log.* /var/lib/news/batchlog.* /var/lib/news/errlog.*

INN

/usr/local/lib/news/log /usr/local/lib/news/errlog /var/log/inn/*

fidogate

/var/log/fnet/log

ifcico

/var/log/fnet/ifmail /var/log/fnet/iflog /var/log/fnet/ifdebug

Um die Korrektheit erstellter Pakete zu erkunden oder Probleme in bestehenden Paketen zu finden, enthält FidoGate das Programm pktdebug. Braucht man mehr Informationen, so sollte man sich das DOS-Programm Inspect besorgen, welches problemlos in der Dosemu läuft und wenn man die Verzeichnisse entsprechend freigibt und die Dosemu dann als User uucp startet, dann kann man die .pkt-Files und Archive sogar verändern.

Hängt CNews komplett, so bleibt einem nur ein Debugging der diversen cnews-Shell-Scripts. Hierzu sollte man in das jeweilige Skript ein "set -xv" am Anfang einbauen, welches genau ausgibt, welche Zeilen des Skripts in welcher Reihenfolge und mit welchen Parametern aufgerufen werden. Für weitere Informationen dazu empfehle ich die Manpage der bash.

Falls nur das Posten von News-Artikeln nicht klappt, kann man auch mal versuchen, mit Pnews aus dem Paket trn direkt zu posten. Selbiges ist nämlich im Gegensatz zu tin ein einfaches Shell-Skript, bei dem die Fehlermeldungen von cnews immerhin so lange stehen bleiben, bis man sie gelesen hat (bei tin werden die direkt wieder vom Menü überschrieben).


Inhalt