Hallo,
Nehmen wir nochmal aus der vorherigen Mail was dazu:
hier die Ausgabe des strace -p PID kommandos:
write(1, "aliases\t\t\t nagios\raliases.d\t\t"..., 256) = -1 EMSGSIZE (Message too long) write(1, "aliases\t\t\t nagios\raliases.d\t\t"..., 256) = -1 EMSGSIZE (Message too long) write(1, "aliases\t\t\t nagios\raliases.d\t\t"..., 256) = -1 EMSGSIZE (Message too long) write(1, "aliases\t\t\t nagios\raliases.d\t\t"..., 256) = -1 EMSGSIZE (Message too long)
hier sehen wir das der write auf FD (Filedescriptor) 1 zu schreiben versucht und das mit einem EMSGSIZE (Message too long) abbricht.
Ja, so sehe ich das jetzt auch.
Der write haengt also auf dieser Session auf ax1.
_Ich_ denke nicht, das es sich um ein Problem mit dem axspawn selber handelt, sondern ein Problem zwischen Kernel-AX25 und axspawn. An der Stelle muss ich dann aber passen. Könnte es evt. sein dass ich mit einer falschen bzw. zu agressiven Firewall konfiguration irgend etwas zwischen Kernel und ax-Interface blockiere?
Eines stoert mich aber noch, warum sehen ich im write Sachen mit nagios? Hast Du nagios installiert/laufen? Aendert sich etwas, wenn Du das nagios abschaltest/deinstalliert? oder ist das der output von einem ls im /etc ? Ja, es ist der Output von ls /etc, da das problem nur bei großen Datenmengen auftritt, habe ich dies einfach mal so simuliert...
vy 73 de Manuel