(OT/HylaFax/Dringend!) FaxQueuer[...]: Assertion failed "InvalidStr[] index", file "../util/Str.h" line 106
Servus, Wir haben dieses Wochenende eine fax-Aktion (Einladungen) durchzuführen (4000 Faxe). Jedoch gibts jetzt ein paar Probleme mit einem Hylafax Server, welcher das letzte Jahr über problemlos gelaufen ist. Die einzige Änderung die ich in der letzten Zeit gemacht habe, war das sendmail durch das Exim zu ersetzen. Danach funktionierte der Fax server jedoch noch Problemlos. Aber durch einen unglücklichen Zufall gab es dann eine art Endlosschleife im Exim/FaxNotifacation, so das auf einmal ca. 500.000 Faxe in die Fax-Que geschickt wurden. Die Faxe habe ich soweit gelöscht und alle Queues sind jetzt wieder frei. Der Befehl ``sendfax -d <number> <file>'' ergibt "request id is 2 (group id 2) for host localhost (1 file)." Was mir sagt, das das spoolen des Faxauftrages soweit in Ordnung ist. Jedoch wird er Fax-Job direkt in das doneq-Verzeichnis gelegt und liegt dort tot rum. Die dadurch angelegte .tiff Datei kann ich lesen und eine Job-Info-Datei wurde in dem doneq-Verzeichnis automatisch erstellt bzw. hineinbewegt. Jedoch steht dort keine Begründung drin warum der Fax-Job fehlgeschlagen ist. Da der Job jetzt in der doneq hängt, kann ich jetzt einen Blick in das syslog werfen: +-+-+ /var/log/messages +-+-+ HylaFAX[1856]: Filesystem has SysV-style file creation semantics. FaxQueuer[1843]: FIFO RECV "Sclient/1856:17" FaxQueuer[1843]: SUBMIT JOB 17 FaxQueuer[1843]: JOB 17 (suspended dest pri 127 tts 0:00 killtime 2:59:00): CREATE FaxQueuer[1843]: Apply CanonicalNumber rules to "155" FaxQueuer[1843]: --> match rule "^[^+]", result now "+155" FaxQueuer[1843]: --> return result "+155" FaxQueuer[1843]: Apply DisplayNumber rules to "155" FaxQueuer[1843]: --> return result "155" FaxQueuer[1843]: JOB 17 (ready dest +155 pri 127 tts 0:00 killtime 2:59:00): READY FaxQueuer[1843]: FIFO SEND client/1856 msg "S*" FaxQueuer[1843]: JOB 17 (ready dest +155 pri 127 tts 0:00 killtime 2:59:00): PROCESS FaxQueuer[1843]: JOB 17 (active dest +155 pri 127 tts 0:00 killtime 2:59:00): ACTIVE FaxQueuer[1843]: JOB 17 (active dest +155 pri 127 tts 0:00 killtime 2:59:00): PREPARE START FaxQueuer[1859]: Assertion failed "Invalid Str[] index", file "../util/Str.h" line 106. FaxQueuer[1843]: JOB 17 (active dest +155 pri 127 tts 0:00 killtime 2:59:00): PREPARE DONE FaxQueuer[1843]: JOB 17: bad exit status 0x6 from sub-fork FaxQueuer[1843]: NOTIFY: bin/notify "doneq/q17" "failed" "" FaxQueuer[1843]: JOB 17 (failed dest +155 pri 127 tts 0:00 killtime 2:59:00): DEAD FaxQueuer[1843]: JOB 17 (failed dest +155 pri 127 tts 0:00 killtime 2:59:00): DELETE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sagt nicht viel aus, ausser das es einen ``Assertion failed''-Fehler gab. Hierzu hatte ich was im hylafax-Bugtracker gefunden, aber da ich SuSE's RPM version von Hylafax benutze bringt mir der dort zu Verfügung stehende Patch nix. Aus verzweifelung habe ich einen strace für den faxq-Prozess mitlaufen lassen und einfach einen normalen Test-Job reingeschickt. Den strace-Output findet ihr auf meiner Homepage: <http://neo.de/hfax-strace.txt> Kann hier jemand Helfen? Bitte? Ich werde einen Kopf kürzer gemacht wenn das bis Sonntag nicht läuft. Ich habe auf dem hylafax bugtracker einen Bug gefunden: <http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=381> welcher generell assertion failures im Str.h anspricht. Diesen habe ich in die SuSE source RPM's reingepackt und neu kompiliert und installiert. Hat leider nichts gebracht. :( Nach weiterem rumspielen mit Hylafax hab ich dann ein merkwürdiges Phänomen gefunden: Hylafax scheint die Fax-Jobs normal in die Send-q zu legen wenn -KEINE- config.faxCAPI Konfigurationsdatei in dem etc/ Verzeichnis liegt. Dann wird der Job zwar nicht geschickt (da kein ISDN-Contoller konfiguriert), er wird aber auch nicht direkt in die doneq mit einem Fehler gestellt. Nachdem man eine config.faxCAPI wieder in das etc/ Verzeichnis legt, verhält sich Hylafax so wie vorher: Alle neuen Jobs gehen direkt mit einem assertion failed in die doneq. PS: Das CAPI Zeug funktioniert Problemlos. c2faxsend und c2faxrecv machen ihre Arbeit. Von daher schätze ich mal, dass das Problem mehr bei Hylafax liegt. Server Info ------------------- o SuSE Linux 8.1 (Linux fax 2.4.19-4GB) o Single CPU 400 Mhz o 1 Active Fritz! PCI ISDN controller o Hylafax 4.1.3 (SuSE RPM: hylafax-4.1.3-145) o CAPI4Hylafax (SuSE RPM) Danke!! -- Regards, Bastian Bense "Never make anything simple and efficient when a way can be found to make it complex and wonderful."
participants (1)
-
Bastian Bense