Hallo zusammen, ich bin aus Sicherheitsgründen und Hardwareumbau auf SuSE 9.2 umgestiegen (zuvor 8.0 mit 2.4.22 Kernel). Ich habe alle Konfig-Scripts usw. von meinem alten System übernommen, was eigentlich auch ufb geklappt hat. AX25 läuft. Nun zum problem, wenn ich von aussen mein System Connecte, ist erstmal alles Okay. Sobald ich dann einen Befehl absetze, kommt nichts vom Linux System zurück (also keine Daten, die Pakete werden ufb bestätigt!). Dabei steigt die CPU Last vom AXSPAWN auf 100% an. Ist dies ein BUG im AXSPAWN von SuSE 9.2, oder habe ich evt. doch probleme mit den übernommenen Konfigurationen. Hier ein auszug: # /etc/ax25/ax25d.conf # Startport1 [DO2GM-11 via port1 ] default * * * * * * - root /usr/sbin/axspawn axspawn %u + #default * * * * * * - root /usr/sbin/node node NOCALL * * * * * * L # Endport1 # Startport2 [DO2GM-10 via port2 ] NOCALL * * * * * * L default * * * * * * - root /usr/sbin/axspawn axspawn %u + #default * * * * * * - root /usr/sbin/node node # Endport2 # /etc/ax25/axspawn.conf create no guest no group ax25 home /home/ shell /bin/bash associate yes Mir ist das ganze auf PORT2 aufgefallen, den PORT1 benutze ich z.Z. garnicht... Kann mir da evt. jemand einen Tipp geben!? vy 73 de Manuel DO 2 GM
Hallo noch mal, ich habe das ganze noch einmal beobachtet, wenn nur "kleine" Datenmengen übertragen werden, funktioniert alles ufb, aber sobald mehrere Datenpakete zusammen kommen, ist es vorbei.. :-( Was mir auch noch aufgefallen ist, der Befehl CALL funktioniert ufb, bei dem Befehl AX25_CALL kommen aber auch laufend pakete abhanden.. :-( Im LISTEN ist alles vorhanden und zu sehen. Hat einer einen Rat? vy 73 de Manuel ________________________________________ Von: Manuel [mailto:baeri3@gmx.de] Gesendet: Freitag, 11. Februar 2005 11:32 An: suse-ham@suse.com Betreff: [suse-ham] AXSPAWN erzeugt 100% CPU Last Hallo zusammen, ich bin aus Sicherheitsgründen und Hardwareumbau auf SuSE 9.2 umgestiegen (zuvor 8.0 mit 2.4.22 Kernel). Ich habe alle Konfig-Scripts usw. von meinem alten System übernommen, was eigentlich auch ufb geklappt hat. AX25 läuft. Nun zum problem, wenn ich von aussen mein System Connecte, ist erstmal alles Okay. Sobald ich dann einen Befehl absetze, kommt nichts vom Linux System zurück (also keine Daten, die Pakete werden ufb bestätigt!). Dabei steigt die CPU Last vom AXSPAWN auf 100% an. Ist dies ein BUG im AXSPAWN von SuSE 9.2, oder habe ich evt. doch probleme mit den übernommenen Konfigurationen. Hier ein auszug: # /etc/ax25/ax25d.conf # Startport1 [DO2GM-11 via port1 ] default * * * * * * - root /usr/sbin/axspawn axspawn %u + #default * * * * * * - root /usr/sbin/node node NOCALL * * * * * * L # Endport1 # Startport2 [DO2GM-10 via port2 ] NOCALL * * * * * * L default * * * * * * - root /usr/sbin/axspawn axspawn %u + #default * * * * * * - root /usr/sbin/node node # Endport2 # /etc/ax25/axspawn.conf create no guest no group ax25 home /home/ shell /bin/bash associate yes Mir ist das ganze auf PORT2 aufgefallen, den PORT1 benutze ich z.Z. garnicht... Kann mir da evt. jemand einen Tipp geben!? vy 73 de Manuel DO 2 GM
On Sun, Feb 27, 2005 at 10:00:11AM +0100, Manuel wrote:
Hallo noch mal,
ich habe das ganze noch einmal beobachtet, wenn nur "kleine" Datenmengen ?bertragen werden, funktioniert alles ufb, aber sobald mehrere Datenpakete zusammen kommen, ist es vorbei.. :-(
Wenn der axspan 100%COU zieht solltest Du mal mit dem ps Kommando die PID des prozesses suchen. Dannach solltest Du mit dem Kommando strace -p PID mal nachschauen, was der axspawn treibt. Wenn da viele durchlaeuft ist der prozess im userspace, sprich es ist der axspawn der looped. Kommt da gar nix, oder seehr wenig dann wird die Zeit im Kernel verbraten. 73 Christian / DG7PC -- Christian Hilgers chris@familie-hilgers.com
Hallo Christian, 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) 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) Genau wie du vermutet hast, in einer Loop. Was kann ich dagegen tun? Muss ich den axspawn patchen? Hängt das problem mit dem ax25_call und axspawn irgendwie zusammen? vy 73 de Manuel DO 2 GM -----Ursprüngliche Nachricht----- Von: Christian Hilgers [mailto:chris@familie-hilgers.com] Gesendet: Sonntag, 27. Februar 2005 10:58 An: Manuel Cc: suse-ham@suse.com Betreff: Re: [suse-ham] AXSPAWN erzeugt 100% CPU Last On Sun, Feb 27, 2005 at 10:00:11AM +0100, Manuel wrote:
Hallo noch mal,
ich habe das ganze noch einmal beobachtet, wenn nur "kleine" Datenmengen ?bertragen werden, funktioniert alles ufb, aber sobald mehrere Datenpakete zusammen kommen, ist es vorbei.. :-(
Wenn der axspan 100%COU zieht solltest Du mal mit dem ps Kommando die PID des prozesses suchen. Dannach solltest Du mit dem Kommando strace -p PID mal nachschauen, was der axspawn treibt. Wenn da viele durchlaeuft ist der prozess im userspace, sprich es ist der axspawn der looped. Kommt da gar nix, oder seehr wenig dann wird die Zeit im Kernel verbraten. 73 Christian / DG7PC -- Christian Hilgers chris@familie-hilgers.com -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-ham-unsubscribe@suse.com Um eine Liste aller verf|gbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-ham-help@suse.com
Manuel schrieb:
Hallo Christian,
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) 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)
Ok. dann solltest Du als naechstes per lsof -p PID-axspawn man nachschauen was der Descriptor 1 ist
-----Ursprüngliche Nachricht----- Von: Christian Hilgers [mailto:chris@familie-hilgers.com]
Und lerne bbitte richtig zu quoten: http://learn.to/quote 73 de Christian ----------------------------------------------------------------- Christian Hilgers chris@familie-hilgers.com
Hallo,
Ok. dann solltest Du als naechstes per lsof -p PID-axspawn man nachschauen was der Descriptor 1 ist
Hier die komplette Ausgabe von lsof -p PID : COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME axspawn 23110 root cwd DIR 3,2 560 2 / axspawn 23110 root rtd DIR 3,2 560 2 / axspawn 23110 root txt REG 3,2 34152 146424 /usr/sbin/axspawn axspawn 23110 root mem REG 3,2 106308 7971 /lib/ld-2.3.3.so axspawn 23110 root mem REG 3,2 77223 146542 /usr/local/lib/libax25.so.0.0.0 axspawn 23110 root mem REG 3,2 12643 7995 /lib/libutil.so.1 axspawn 23110 root mem REG 3,2 1359489 7997 /lib/tls/libc.so.6 axspawn 23110 root mem REG 3,2 217016 138945 /var/run/nscd/group axspawn 23110 root mem REG 3,2 217016 138944 /var/run/nscd/passwd axspawn 23110 root 0u ax25 ax1 407174 DO2GM-10->DO2GM-0,HB9AK-0 (Sq=0 Rq=0 State=3, ESTABLISHED) axspawn 23110 root 1u ax25 ax1 407174 DO2GM-10->DO2GM-0,HB9AK-0 (Sq=0 Rq=0 State=3, ESTABLISHED) axspawn 23110 root 2w FIFO 0,7 392134 pipe axspawn 23110 root 3u CHR 5,2 28570 /dev/ptmx axspawn 23110 root 4r REG 0,3 0 4026532834 /proc/net/ax25_calls axspawn 23110 root 7w FIFO 0,7 199215 pipe axspawn 23110 root 8u sock 0,4 215328 can't identify protocol axspawn 23110 root 10u sock 0,4 199399 can't identify protocol axspawn 23110 root 11u sock 0,4 252745 can't identify protocol axspawn 23110 root 12u sock 0,4 266194 can't identify protocol axspawn 23110 root 13u sock 0,4 281540 can't identify protocol axspawn 23110 root 14u sock 0,4 293593 can't identify protocol axspawn 23110 root 15u sock 0,4 312424 can't identify protocol axspawn 23110 root 16u sock 0,4 315588 can't identify protocol axspawn 23110 root 17u sock 0,4 315622 can't identify protocol axspawn 23110 root 18u sock 0,4 326725 can't identify protocol axspawn 23110 root 19u sock 0,4 343592 can't identify protocol axspawn 23110 root 20u sock 0,4 359457 can't identify protocol axspawn 23110 root 21u sock 0,4 377342 can't identify protocol axspawn 23110 root 22u sock 0,4 392126 can't identify protocol axspawn 23110 root 23u sock 0,4 392128 can't identify protocol
Und lerne bbitte richtig zu quoten: http://learn.to/quote Hoffe dass ich es jetzt besser gemacht habe.. ;_)
vy 73 de Manuel
Manuel schrieb:
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.
Ok. dann solltest Du als naechstes per lsof -p PID-axspawn man nachschauen was der Descriptor 1 ist
Hier die komplette Ausgabe von lsof -p PID :
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME axspawn 23110 root cwd DIR 3,2 560 2 / axspawn 23110 root rtd DIR 3,2 560 2 / axspawn 23110 root txt REG 3,2 34152 146424 /usr/sbin/axspawn axspawn 23110 root mem REG 3,2 106308 7971 /lib/ld-2.3.3.so axspawn 23110 root mem REG 3,2 77223 146542 /usr/local/lib/libax25.so.0.0.0 axspawn 23110 root mem REG 3,2 12643 7995 /lib/libutil.so.1 axspawn 23110 root mem REG 3,2 1359489 7997 /lib/tls/libc.so.6 axspawn 23110 root mem REG 3,2 217016 138945 /var/run/nscd/group axspawn 23110 root mem REG 3,2 217016 138944 /var/run/nscd/passwd
das ist FD 0:
axspawn 23110 root 0u ax25 ax1 407174 DO2GM-10->DO2GM-0,HB9AK-0 (Sq=0 Rq=0 State=3, ESTABLISHED)
und das hier FD 1:
axspawn 23110 root 1u ax25 ax1 407174 DO2GM-10->DO2GM-0,HB9AK-0 (Sq=0 Rq=0 State=3, ESTABLISHED) das ist also eine Session ueber das ax1 Interface.
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. 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 ?
Und lerne bbitte richtig zu quoten: http://learn.to/quote
Hoffe dass ich es jetzt besser gemacht habe.. ;_)
so ist das klasse! Leider kann ich hier nicht mehr viel weiterhelfen. 73 de Christian ----------------------------------------------------------------- Christian Hilgers chris@familie-hilgers.com
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
participants (2)
-
Christian Hilgers -
Manuel