Logging über's Netz

ChakaZulu
Developer
Beiträge: 457
Registriert: Sonntag 23. März 2003, 00:39

Logging über's Netz

Beitrag von ChakaZulu »

Hi,

da hier immer wieder Leute rumturnen, die keine serielle Verbindung haben, wollte ich mich nach Alternativen umschauen (v.a. für das Anwendungdebugging) . Da ich mich nicht 100%ig mit den Basics des Bootprozesses auskenne, gibt es vielleicht eine einfachere Lösung, aber hier mal meine:

- da sich die kernel logs in /dev/kmsg befinden, die auch nachträglich noch ausgelesen werden können, muss hier nichts gemacht werden.

- die busybox wird so angepasst, dass sie auch nach /dev/dbox2log schreibt. /dev/dbox2log wird über ein Kernelmodul oder eine Kernelerweiterung bereitgestellt, die ein paar kb puffert

- ein Prozess ließt von /dev/dbox2log und schreibt die Daten z.B. auf einen share, sobald dieser verfügbar ist. Da das Modul die Daten puffert sollte es kein Problem sein, dass das Netzwerk erst später zur Verfügung steht.

Gibt es evtl. eine Möglichkeit, die Buffergrösse eines FIFOs/PIPE anzpassen (<edit>hm, anscheinend nur über die kernel-sourcen</edit>)? Die busybox sollte nicht blockiert werden, wenn zuviel geschrieben wurde, aber niemand die Daten abholt. Dann bräuchte man kein extra Modul wie dbox2log (obwohl das nicht allzu viel Aufwand darstellen sollte). Im Modul würden dafür einfach die ältesten Einträge überschrieben werden.

Ich habe Patches für eine netconsole für 2.4.10 o.ä. gefunden, aber nichts aktuelleres (ehrlich gesagt habe ich aber nicht versucht, die auf den 2.4.27er anzuwenden). Aber anscheinend müssen die Netzwerktreiber dafür verändert werden, hat sich damit schonmal jemand beschäftigt? RedHat scheint da auch aktiv zu sein, allerdings habe ich nicht viel gefunden, ausser:
http://www.redhat.com/archives/fedora-d ... 00208.html


In der Hoffnung auf noch ein paar Vorschläge,

ChakaZulu
rasc
Senior Member
Beiträge: 5071
Registriert: Dienstag 18. September 2001, 00:00

Beitrag von rasc »

ideal waere eigentlich ein syslogd
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

hi,
..die sicher nicht neue Idee finde ich gut...bei der Oleg Firmware auf der WL-HDD gibt's zB. auch ein sehr informatives Logfile...inkl. Bootprozess...laesst sich sogar uebers Webinterface abrufen:

Code: Alles auswählen

Jan  1 01:00:09 syslogd started: BusyBox v1.00 (2005.05.11-18:29+0000)
Jan  1 01:00:09 kernel: Loading BCM4710 MMU routines.
Jan  1 01:00:09 kernel: Primary instruction cache 8kb, linesize 16 bytes (2 ways)
Jan  1 01:00:09 kernel: Primary data cache 4kb, linesize 16 bytes (2 ways)
Jan  1 01:00:09 kernel: Linux version 2.4.20 (root@omnibook) (gcc version 3.2.3 with Broadcom modifications) #5 Wed May 11 22:33:36 MSD 2005
Jan  1 01:00:09 kernel: Setting the PFC value as 0x15
Jan  1 01:00:09 kernel: Determined physical RAM map:
Jan  1 01:00:09 kernel:  memory: 01000000 @ 00000000 (usable)
Jan  1 01:00:09 kernel: On node 0 totalpages: 4096
Jan  1 01:00:09 kernel: zone(0): 4096 pages.
Jan  1 01:00:09 kernel: zone(1): 0 pages.
Jan  1 01:00:09 kernel: zone(2): 0 pages.
Jan  1 01:00:09 kernel: Kernel command line: root=/dev/mtdblock2 noinitrd init=/linuxrc console=ttyS0,115200
Jan  1 01:00:09 kernel: CPU: BCM4710 rev 0 at 125 MHz
Jan  1 01:00:09 kernel: !unable to setup serial console!
Jan  1 01:00:09 kernel: Calibrating delay loop... 82.94 BogoMIPS
Jan  1 01:00:09 kernel: Memory: 13876k/16384k available (1763k kernel code, 2508k reserved, 248k data, 72k init, 0k highmem)
Jan  1 01:00:09 kernel: Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Jan  1 01:00:09 kernel: Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Jan  1 01:00:09 kernel: Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Jan  1 01:00:09 kernel: Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Jan  1 01:00:09 kernel: Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Jan  1 01:00:09 kernel: Checking for 'wait' instruction...  unavailable.
Jan  1 01:00:09 kernel: POSIX conformance testing by UNIFIX
Jan  1 01:00:09 kernel: PCI: Fixing up bus 0
Jan  1 01:00:09 kernel: PCI: Fixing up bridge
Jan  1 01:00:09 kernel: PCI: Fixing up bus 1
Jan  1 01:00:09 kernel: Linux NET4.0 for Linux 2.4
Jan  1 01:00:09 kernel: Based upon Swansea University Computer Society NET3.039
Jan  1 01:00:09 kernel: Initializing RT netlink socket
Jan  1 01:00:09 kernel: Starting kswapd
Jan  1 01:00:09 kernel: Journalled Block Device driver loaded
Jan  1 01:00:09 kernel: devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
Jan  1 01:00:09 kernel: devfs: boot_options: 0x1
Jan  1 01:00:09 kernel: NTFS driver v1.1.22 [Flags: R/O]
Jan  1 01:00:09 kernel: pty: 256 Unix98 ptys configured
Jan  1 01:00:09 kernel: Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
Jan  1 01:00:09 kernel: loop: loaded (max 8 devices)
Jan  1 01:00:09 kernel: PPP generic driver version 2.4.2
Jan  1 01:00:09 kernel: PPP Deflate Compression module registered
Jan  1 01:00:09 kernel: PPP BSD Compression module registered
Jan  1 01:00:09 kernel: MPPE/MPPC encryption/compression module registered
Jan  1 01:00:09 kernel:  Amd/Fujitsu Extended Query Table v1.1 at 0x0040
Jan  1 01:00:09 kernel: Physically mapped flash: Swapping erase regions for broken CFI table.
Jan  1 01:00:09 kernel: number of CFI chips: 1
Jan  1 01:00:09 kernel: Flash device: 0x400000 at 0x1fc00000
Jan  1 01:00:09 kernel: Physically mapped flash: squashfs filesystem found at block 941
Jan  1 01:00:09 kernel: Creating 5 MTD partitions on "Physically mapped flash":
Jan  1 01:00:09 kernel: 0x00000000-0x00040000 : "pmon"
Jan  1 01:00:09 kernel: 0x00040000-0x003e0000 : "linux"
Jan  1 01:00:09 kernel: 0x000eb5b4-0x003e0000 : "rootfs"
Jan  1 01:00:09 kernel: 0x003f0000-0x00400000 : "nvram"
Jan  1 01:00:09 kernel: 0x003e0000-0x003f0000 : "config"
Jan  1 01:00:09 kernel: sflash: chipcommon not found
.usw.
die Sourcen gibt's natuerlich...aber keine Ahnung ob Dir das was nuetzt.

viel Erfolg,
peter

PS:Waehrend ich das hier geschrieben habe, hat Rasc schon das Stichwort 'syslogd' gegegben...das iss es dann wohl auch...bin dafuer!
ChakaZulu
Developer
Beiträge: 457
Registriert: Sonntag 23. März 2003, 00:39

Beitrag von ChakaZulu »

hi,

ok, die busybox hat ja einen syslogd. Warum wird der nicht benutzt? Ist er zu gross?

ciao,

ChakaZulu
MarcM
Foren-Moderator
Beiträge: 1119
Registriert: Sonntag 9. Juni 2002, 13:28

Beitrag von MarcM »

Hi,

Theoretisch isses kein Problem den syslogd mit in die Busybox mit reinzunehmen. Bleiben aber immernoch 2 Sachen.....wie groß ist die Busybox mit zusätzlich syslogd ? Bis jetzt ist die schon ~290Kb ?!?. Ich hatte hier schonmal probiert stty mit reinzunehmen. Das waren schon 35Kb mehr....Und der Syslogd wird denk ich auch sowas in der Richtung haben. Ich weiß nicht wieviel Platz noch übrig bleibt.....

Und zum zweiten...wo soll denn der syslogd hinschreiben ? in ne Partition (Platz ? ) ? ins /tmp (denkt mal an Leute die tagelang ihre Box nicht rebooten/runterfahren, dann wird auch /tmp irgendwann voll...) ? in ne Ramdisk ? hmmm

Müßte man sich mal gedanken machen......

dmesg gibt zwar einiges aus, aber ein ordentliches Bootlog hätte was...

Greetz

Marc
JtG-Riker
Image-Team
Beiträge: 1015
Registriert: Freitag 7. Februar 2003, 18:37

Beitrag von JtG-Riker »

ChakaZulu hat geschrieben:hi,

ok, die busybox hat ja einen syslogd. Warum wird der nicht benutzt? Ist er zu gross?

ciao,

ChakaZulu
ist nicht schwer groß, ich hab das im Jtg Image vor einiger Zeit mal mit eingebaut, weil ich an meiner Nokia im Wohnzimmer ca 10m Kabel dran hatte, seriell - und wenn der Rechner aus ist macht die immer Probleme.

Riker
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

MarcM hat geschrieben:Und zum zweiten...wo soll denn der syslogd hinschreiben ?....
..wie waere es mit einem Ringbuffer in /tmp der zumindest das komplette Bootlog aufnehmen kann...20k sollten da doch schon reichen..
hannebamb(el)
Foren-Moderator
Beiträge: 297
Registriert: Montag 11. Oktober 2004, 14:51

Beitrag von hannebamb(el) »

also,

den netconsole patch hab ich mal zurückportiert aus dem 2.6er Branch plus ein wenig Zusatz patchen. Klappt auch soweit problemlos. Dabei ist es egal, ob man das Ganze als module oder direkt in den kernel hinein kompiliert, man gewinnt keine Meldungen. Als module hat es den Vorteil der einfacheren Parameterübergabe(Zielhost für's Logging).

Ein Problem ist jedoch, das damit nur die Ausgaben der module/des kernels über's netz kommen, sprich nur printk's.

Zusätzlich hab ich mal socat auf der Box ans Laufen gebracht, funktioniert auch soweit ganz gut, man etabliert ein UDP tty und setzt /dev/console um. Nachteil an socat ist zur Zeit noch, daß es von etlichen libs abhängt, das ist so einfach zu groß. Hatte bisher noch keinen Nerv, die benötigten Funktionen aus den libs wieder rauszupuhlen :-)

Unter

http://www.dbox2world.de/board/thread.p ... =6436&sid=

und

http://www.dbox2world.de/board/thread.p ... =6416&sid=

sind die Sourcen zu den bisherigen Versuchen hinterlegt, wer es mal testen mag.
Die Netconsole selbst ist meines Erachtens nach OK so wie sie ist und könnte bei Interesse ins cvs, an der socat Geschichte müssten wir dann noch was drehen

cya

Hannebambel
Zuletzt geändert von hannebamb(el) am Montag 23. Mai 2005, 23:32, insgesamt 2-mal geändert.
ChakaZulu
Developer
Beiträge: 457
Registriert: Sonntag 23. März 2003, 00:39

Beitrag von ChakaZulu »

hi,
Und zum zweiten...wo soll denn der syslogd hinschreiben ? in ne Partition (Platz ? )
nö, der müsste seine Daten über's Netz an einen anderen Server schicken...
Mit den Imagegrössen usw. kenne ich mich auch nicht aus.

ciao,

ChakaZulu
hannebamb(el)
Foren-Moderator
Beiträge: 297
Registriert: Montag 11. Oktober 2004, 14:51

Beitrag von hannebamb(el) »

Und nochwas zum Thema:

http://www.circlemud.org/~jelson/software/emlog/
emlog -- the EMbedded-system LOG-device
Wobei mir persönlich die erste Alternative besser gefiel
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

ChakaZulu hat geschrieben:hi,
Und zum zweiten...wo soll denn der syslogd hinschreiben ? in ne Partition (Platz ? )
nö, der müsste seine Daten über's Netz an einen anderen Server schicken...
ja sorry, das passt auch besser zu Deinem Vorschlag...aber ich denke mehr an die Situationen in denen hier von den Supportern ein Bootlog gefragt ist...bootlog.txt mit ftp aus /tmp zu fischen sollte jeder hinbekommen.
Wie stellst Du Dir das vor online 'ueber Netz'....tftp32 hat zB. einen 'Syslogserver' waere's das?
ChakaZulu
Developer
Beiträge: 457
Registriert: Sonntag 23. März 2003, 00:39

Beitrag von ChakaZulu »

petgun hat geschrieben: ja sorry, das passt auch besser zu Deinem Vorschlag...aber ich denke mehr an die Situationen in denen hier von den Supportern ein Bootlog gefragt ist...bootlog.txt mit ftp aus /tmp zu fischen sollte jeder hinbekommen.
ich war ja eher am Applikationsdebugging interessiert, damit z.B. endlich mal logs vom timerd usw. kommen. Wo gibt es einen Unterschied zw. /dev/kmsg und der netconsole-Ausgabe? Ok, bei nem oops gibt's bestimmt einen ;)
emlog kann man wohl auch nutzen, ich hatte sowas schonmal angefangen (das o.g. dbox2log :))
Bei einer Kopie über's Netz hat man die Daten halt gleich. Ich bin aber eben nicht sicher, ab wann das Netzinterface da ist und was vorher potenziell noch schiefgehen könnte, so dass man trotzdem keine Informationen über den Fehler hat.

Wie stellst Du Dir das vor online 'ueber Netz'....tftp32 hat zB. einen 'Syslogserver' waere's das?
denke schon

ciao,

ChakaZulu
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

...ein Syslogserver ist sicher die bessere und elegantere Loesung....ich bin interessiert, kann aber leider nix mehr zum Thema beisteuern.

viel Erfolg,
peter
hannebamb(el)
Foren-Moderator
Beiträge: 297
Registriert: Montag 11. Oktober 2004, 14:51

Beitrag von hannebamb(el) »

Das wäre ein Beispiel, ab wann die Daten da sind:
[...network console startup...]
netconsole: network logging started
Using /lib/modules/2.4.27-dbox2/misc/event.o
event: $Id: event.c,v 1.12 2003/09/30 05:45:38 obi Exp $
Using /lib/modules/2.4.27-dbox2/misc/tuxbox.o
Using /lib/modules/2.4.27-dbox2/misc/dvb-core.o
Using /lib/modules/2.4.27-dbox2/misc/dbox2_i2c.o
[i2c-8xx]: mpc 8xx i2c init
[i2c-8xx]: adapter: 0
Using /lib/modules/2.4.27-dbox2/misc/dbox2_fp.o
Using /lib/modules/2.4.27-dbox2/misc/dbox2_fp_input.o
Using /lib/modules/2.4.27-dbox2/misc/avs.o
Using /lib/modules/2.4.27-dbox2/misc/saa7126.o
Detected STB:
Vendor: Sagem
Model: D-BOX2
Using /lib/modules/2.4.27-dbox2/misc/cam.o
$Id: cam.c,v 1.30 2004/01/10 16:36:34 alexw Exp $
cam: no firmware file found
Using /lib/modules/2.4.27-dbox2/misc/dvb_i2c_bridge.o
Using /lib/modules/2.4.27-dbox2/misc/avia_napi.o
$Id: avia_napi.c,v 1.18 2003/11/24 09:53:01 obi Exp $
DVB: registering new adapter (C-Cube AViA GTX/eNX with AViA 500/600).
dvb_i2c_bridge: enabled DVB i2c bridge to PowerPC 8xx I2C adapter
Using /lib/modules/2.4.27-dbox2/misc/cam_napi.o
$Id: cam_napi.c,v 1.8 2003/09/30 05:45:34 obi Exp $
Using /lib/modules/2.4.27-dbox2/misc/dbox2_fp_napi.o
Using /lib/modules/2.4.27-dbox2/misc/avia_av.o
avia_av: $Id: avia_av_core.c,v 1.98 2004/11/21 20:33:38 carjay Exp $
avia_av_core.c: avia_av_firmware_read: Unable to load '/var/tuxbox/ucodes/avia600.ux'.
avia_av: microcode not found, setting up dummy
avia_av_proc: $Id: avia_av_proc.c,v 1.14 2004/01/21 20:02:29 carjay Exp $
Using /lib/modules/2.4.27-dbox2/misc/avia_gt.o
avia_gt_core: $Id: avia_gt_core.c,v 1.48 2004/12/20 01:01:22 carjay Exp $
avia_gt_core: autodetecting chip type... eNX
avia_gt_enx: $Id: avia_gt_enx.c,v 1.21 2003/09/30 05:45:35 obi Exp $
avia_gt_accel: $Id: avia_gt_accel.c,v 1.19 2003/09/30 05:45:35 obi Exp $
avia_gt_dmx: $Id: avia_gt_dmx.c,v 1.210 2004/06/26 16:08:15 carjay Exp $
avia_gt_ucode: loaded ucode v0014
avia_gt_ucode: ucode section filters enabled.
avia_gt_dmx: warning, misaligned queue 0 (is 0xFD200, size 65536), aligning...
avia_gt_gv: $Id: avia_gt_gv.c,v 1.39 2004/08/28 16:44:56 carjay Exp $
avia_gt_gv: set_input_size (width=720, height=576)
avia_gt_pcm: $Id: avia_gt_pcm.c,v 1.29 2004/01/29 19:38:20 zwen Exp $
avia_gt_pcm_set_rate(44100)
avia_gt_capture: $Id: avia_gt_capture.c,v 1.32 2003/09/30 05:45:35 obi Exp $
avia_gt_pig: $Id: avia_gt_pig.c,v 1.40 2003/09/30 05:45:35 obi Exp $
avia_gt_vbi: $Id: avia_gt_vbi.c,v 1.26 2003/08/01 17:31:22 obi Exp $
avia_gt_core: Loaded AViA eNX/GTX driver
Using /lib/modules/2.4.27-dbox2/misc/avia_gt_fb.o
avia_av_core: Starting avia_gt_wdt thread.
avia_gt_fb: $Id: avia_gt_fb_core.c,v 1.54 2004/03/17 18:42:18 zwen Exp $
avia_gt_gv: set_input_mode (mode=2)
avia_gt_gv: set_input_size (width=720, height=576)
avia_gt_gv: set_input_mode (mode=2)
avia_gt_gv: set_input_size (width=720, height=576)
avia_gt_gv: set_input_mode (mode=2)
avia_gt_gv: set_input_size (width=720, height=576)
Console: switching to colour frame buffer device 82x32
avia_gt_fb: fb0: AViA eNX/GTX Framebuffer frame buffer device
Using /lib/modules/2.4.27-dbox2/misc/lcd.o
lcd.o: init lcd driver module
lcd.o: found KS0713/SED153X lcd interface
Using /lib/modules/2.4.27-dbox2/misc/avia_gt_lirc.o
avia_gt_lirc: $Id: avia_gt_lirc.c,v 1.14 2003/09/30 05:45:35 obi Exp $
avia_gt_ir: $Id: avia_gt_ir.c,v 1.30 2003/09/30 05:45:35 obi Exp $
Using /lib/modules/2.4.27-dbox2/misc/avia_gt_oss.o
avia_oss: $Id: avia_gt_oss.c,v 1.26 2004/05/31 22:56:02 carjay Exp $
avia_gt_pcm_set_rate(44100)
Using /lib/modules/2.4.27-dbox2/misc/avia_gt_v4l2.o
avia_gt_v4l2: $Id: avia_gt_v4l2.c,v 1.12 2003/09/30 04:54:03 obi Exp $
Using /lib/modules/2.4.27-dbox2/misc/at76c651.o
Using /lib/modules/2.4.27-dbox2/misc/ves1x93.o
DVB: registering frontend 0:0 (VES1993)...
Using /lib/modules/2.4.27-dbox2/misc/avia_av_napi.o
avia_av_napi.c: $Id: avia_av_napi.c,v 1.33 2004/03/11 15:30:27 derget Exp $
Using /lib/modules/2.4.27-dbox2/misc/avia_gt_napi.o
avia_gt_napi: $Id: avia_gt_napi.c,v 1.203 2005/01/05 05:49:56 carjay Exp $
Using /lib/modules/2.4.27-dbox2/misc/dvb2eth.o
Using /lib/modules/2.4.27-dbox2/misc/aviaEXT.o
Starting pid 84, console /dev/console: '/etc/init.d/start'

Please press Enter to activate this console. $Id: sectionsd.cpp,v 1.181 2005/03/08 13:39:08 metallica Exp $
caching 504 hours
events are old 180min after their end time
[[camd] CA_SEND_MSG: No such device
[camd] CA_SEND_MSG: No such device
ConfigFile] Unable to open file /var/tuxbox/config/timerd.conf for reading.
$Id: zapit.cpp,v 1.370 2005/03/14 19:58:48 mws Exp $
/var/tuxbox/config/zapit/services.xml: No such file or directory
[zapit.cpp:main:1841] error parsing services
$Id: controld.cpp,v 1.117 2004/05/22 14:34:09 carjay Exp $

[controld] Boxtype detected: (3, Sagem D-BOX2)
[nhttpd] Neutrino HTTP-Server starting..
avia_av: new_audio_config timeout
[frontend.cpp:setDiseqcType:371] NO_DISEQC
avia_av: new_audio_config timeout
[neutrino] frameBuffer Instance created
812k video mem
avia_gt_gv: set_input_mode (mode=2)
avia_gt_gv: set_input_size (width=720, height=576)
[neutrino] Software update enabled
[neutrino] enable flash
[lcdd] time-skin not found -> using default...
[lcdd] weekday-skin not found -> using default...
[lcdd] date-skin not found -> using default...
[lcdd] month-skin not found -> using default...
[LCDFONT] initializing core...
[LCDFONT] adding font /share/fonts/12.pcf.gz...OK (Fix12/Regular)
[LCDFONT] adding font /share/fonts/14B.pcf.gz...OK (Fix14/Bold)
[LCDFONT] adding font /share/fonts/15B.pcf.gz...OK (Fix15/Bold)
[LCDFONT] Intializing font cache...
[LCDFONT] FTC_Face_Requester (Fix15/Bold)
[LCDFONT] FTC_Face_Requester (Fix14/Bold)
/dev/input/event1: No such file or directory
[neutrino] menue setup
loading locales: scandir: No such file or directory
[neutrino] received 17 sats
[neutrino] registering as event client
Wie ihr seht, fehlt da eigentlich nur der Kernel selbst
Chakazulu hat geschrieben: ich war ja eher am Applikationsdebugging interessiert, damit z.B. endlich mal logs vom timerd usw. kommen. Wo gibt es einen Unterschied zw. /dev/kmsg und der netconsole-Ausgabe? Ok, bei nem oops gibt's bestimmt einen
Deswegen bevorzuge ich auch die erstere Möglichkeit, da die Messages "on the fly" auf dem normalen PC auftauchen
AudioSlyer
Erleuchteter
Erleuchteter
Beiträge: 450
Registriert: Sonntag 28. Juli 2002, 01:18

Beitrag von AudioSlyer »

Ich finde das hat unser HB-Männchen sehr gut gemacht *respekt :)
zexma
Tuxboxer
Tuxboxer
Beiträge: 2067
Registriert: Mittwoch 6. März 2002, 15:29

Beitrag von zexma »

klasse, und nun bitte (endlich) ins (tuxbox)-cvs einchecken 8) :P
saruman
Erleuchteter
Erleuchteter
Beiträge: 682
Registriert: Samstag 13. Juli 2002, 10:05

Beitrag von saruman »

@HB: War das jetzt mit dem syslogd oder mit Deinem dbox2log?

Bin nämlich auch sehr am syslogd interessiert - war aber bisher noch immer zu faul, mein CDK mal selber zu compilieren. :)
hannebamb(el)
Foren-Moderator
Beiträge: 297
Registriert: Montag 11. Oktober 2004, 14:51

Beitrag von hannebamb(el) »

Moin auch,

das war mit meiner log Variante, die einfach eine console (Pseudo tty) über das Netz schickt.

Für den Syslog muß die Applikation wissen, das sie das loggen soll, sprich ein einfaches printf, wie es häufig zum debuggen benutzt wird, kommt so nicht rüber, man korrigiere mich, wenn ich da falsch liegen sollte. Daher der Ansatz über das socat und das Aufsetzen des /dev/ttyP0 devices.
ChakaZulu
Developer
Beiträge: 457
Registriert: Sonntag 23. März 2003, 00:39

Beitrag von ChakaZulu »

hi,

also um alles nochmal zusammenzufassen:

syslogd schreibt übers Netz, aber nur Ausgaben, welche über syslog() geloggt werden (wobei ich glaube mich erinnern zu können, dass die Busybox alle messages (also auch alles, was auf der console auftaucht) auch an den syslogd weitergibt, müsste man nochmal schauen (<edit>: hab ich wohl falsch gesehen, es werden stdout und stderr auf das jeweilige Terminal umgeleitet</edit>). Der syslogd der busybox würde eingesetzt werden (genauer Platzbedarf noch unbekannt). Ein Client bräuchte einen laufenden Syslogd.

netconsole Einsatz wäre möglich, ist aber eher für Kerneldebugging zu benutzen, da nur printks geliefert werden. Ansonsten ist der Patch verfügbar.
Ein Client bräuchte eine spezielle Applikation?

socatAlle Ausgaben nach /dev/console werden auf ein Pseudoterminal umgeleitet, welches die Nachrichten per UDP weiterleitet. Patch wäre grundsätzlich verfügbar, allerdings müsste das Paket noch verkleinert werden (ungenutze Funktionen aus den Libs herausnehmen).
Ein Client bräuchte eine spezielle Applikation?

Ich werde mal schauen, wieviel Platz der sylsogd der busybox braucht.


ciao,

ChakaZulu
Zuletzt geändert von ChakaZulu am Dienstag 24. Mai 2005, 17:44, insgesamt 1-mal geändert.
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Frage geloescht
Zuletzt geändert von petgun am Dienstag 24. Mai 2005, 21:05, insgesamt 1-mal geändert.
hannebamb(el)
Foren-Moderator
Beiträge: 297
Registriert: Montag 11. Oktober 2004, 14:51

Beitrag von hannebamb(el) »

ChakaZulu hat geschrieben:hi,

also um alles nochmal zusammenzufassen:

.....

Ein Client bräuchte eine spezielle Applikation?

.....

ciao,

ChakaZulu

die applikation liegt als "quick and dirty" version vor:

Code: Alles auswählen

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>

#include <sys/socket.h>
#include <sys/types.h>
#include <linux/in.h>
#include <linux/if_ether.h>
#include <net/if.h>
#include <sys/ioctl.h>


/*#include <stdlib.h>

#include <sys/dir.h>


#include <signal.h>
#include <sys/wait.h>

#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>

*/

#define PORT 6666
//#define DEBUG 1


//----------------------------------Global Vars -----------------------------------------------------




//---------------------------------Rec-func for messages-------------------------------------------
void recfunc()
{
  int socket_descriptor;
  int setval=1;
  
  struct sockaddr_in address;
  // For broadcasting, this socket can be treated like a UDP socket:
  socket_descriptor = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
  if (socket_descriptor == -1) {
    perror("[kernel-logger] Error opening socket for receiving\n");
    return;
  }
  memset(&address, 0, sizeof(address));
  address.sin_family = AF_INET;
  address.sin_addr.s_addr = INADDR_ANY;
  //address.sin_port = PORT;
  address.sin_port = htons(PORT); //Same as above: network byte orde is opposite of byte orde on system on x86
  int addr_len=sizeof(address);
  int temp=1;
   //Set socket option to broadcast
  setsockopt(socket_descriptor,SOL_SOCKET, SO_BROADCAST,(void *) &temp,sizeof(temp));
  
  setsockopt(socket_descriptor,SOL_SOCKET, SO_REUSEADDR,(void *) &temp,sizeof(temp));
  

  //We need to set the card into promiscous mode to be
  //able to receive packets not destined to our MAC
  //e.g. Broadcast Ethernet Frames
  struct ifreq ethreq;
  strncpy(ethreq.ifr_name,"eth0",IFNAMSIZ);
  //ioctl the device to get the current flags filled
  if (ioctl(socket_descriptor,SIOCGIFFLAGS, &ethreq)==-1)
  {
    perror("[kernel-logger] error requesting device settings\n");
    close (socket_descriptor);
    return;
  }
  
  //Enable promiscous mode:
  //OR the IFF_PROMISC flag to the flags
  ethreq.ifr_flags|=IFF_PROMISC;
  
  //ioctl the device to set the flags 
  if (ioctl(socket_descriptor,SIOCGIFFLAGS, &ethreq)==-1)
  {
    perror("[kernel-logger] error setting promiscous mode\n");
    close (socket_descriptor);
    return;
  }
  else
  {
    printf("[kernel-logger] successfully set card to promiscous mode\n");
  }
  
  
  if(bind(socket_descriptor,(struct sockaddr *)&address, addr_len)==-1)
  {
    perror("[kernel-logger] Error in binding to socket for receiving\n");
    return;
  }
  
  
  unsigned char buffer[512];
  
  //Be informative
  printf("[kernel-logger] Listening for packets on Port: %i\n",PORT);

/*  while(read (socket_descriptor,buffer,8192)>0)
  {
    printf("caught packet: %s, bufferlen: %i\n",buffer,strlen(buffer));
  }
*/
  while (1) 
  {
    memset(buffer,0,sizeof(buffer));
    //recvfrom is a blocking call, which means, the functions just sits there and sleeps, until something
    //arrives or an error occurs	
    //if (recvfrom(socket_descriptor,buffer, sizeof(buffer), 0, (struct sockaddr *)&address, &addr_len) < 0) 
    
    int n=recvfrom(socket_descriptor,buffer, sizeof(buffer), 0, NULL,NULL);
#ifdef DEBUG	
    printf("received %d bytes\n",n);
#endif
    if(n<1)
    {
      perror("[kernel-logger] Error in receiving\n");
      return;
    }
    else
    {
	int i;
#ifdef DEBUG	
	printf("[kernel-logger] network packet received(hex):");
	for (i = 0; i< n;i++)
	{
	    printf(" %02x",buffer[i]);
	}
	printf("\n");
	printf("[kernel-logger] network packet received(ascii-text): ");
	for (i = 5; i< n;i++)
	{
	    printf("%c",buffer[i]);
	}
	printf("\n");
#endif	
	
	//Serch for netconsole header-magic
	if(buffer[0]==0x01 && buffer[1]==0x00 && buffer[2]==0x00)
	{
	    for (i = 5; i< n;i++)
	    {
		printf("%c",buffer[i]);
	    }
	}	
	else
	{
	    //we have a usual packet from redirected console
	    for (i = 0; i< n;i++)
	    {
		printf("%c",buffer[i]);
	    }
	}
    }
  }

}

//-----------------------------------Main--------------------------------------------------------------------
int main(int argc, char **argv)
{
  
  int argcount;
  for(argcount=1;argcount<argc;argcount++)
  {

  }
  printf("[kernel-logger] v 0.1 hannebambel Exp $\n");
  recfunc();

  return 0;
}


Vielleicht könnte das mal einer durch nen MS Developer Studio jagen um zu sehen, ob das auch unter Win32 compiled ?


Was den Rest betrifft, ist das so hundertprozent korrekt zusammengefasst.
ChakaZulu
Developer
Beiträge: 457
Registriert: Sonntag 23. März 2003, 00:39

Beitrag von ChakaZulu »

hi,

hab jetzt mal nachgeschaut, der syslogd würde nur 5kb brauchen. Ich habe nicht ausprobiert, ob das korrekt funktioniert, kann jemand die Grösse bestätigen?
Bleibt die Frage, ob man lieber socat abspeckt oder etwas bastelt, das stdout/stderr-Ausgaben in den syslogd schiebt (über den o.g. Ringbuffer und einen kleinen Daemon, der alles per syslog() weiterleitet).

Ich habe kein Win, kann deshalb auch nichts zur Portabilität Deines Codes sagen...

ciao,

ChakaZulu
hannebamb(el)
Foren-Moderator
Beiträge: 297
Registriert: Montag 11. Oktober 2004, 14:51

Beitrag von hannebamb(el) »

Hi Chakazulu,

hmm, bezüglich der Größe weiß ich nicht, hatte das vor ewig mal getestet, könnte stimmen.

Zu der socat Geschichte:

das hängt noch von einigen libs ab, die so standardmäßig nicht zum make flash-..... gehören oder zu weit gestrippt sind:
-libreadline
-libutil
-libcurl

und ich glaub noch etwas. Die Funktionen müssten da halt rausgepuhlt werden und direkt in das socat reingeschrieben werden. Leider fehlt mir da ein wenig der Durchblick :gruebel: und die Zeit.

Ich weiß halt im Moment nicht, wie man stdout/stderr anders umleiten kann, daher der Versuch mit socat, da das wie gesagt ein /dev/ptyP device aufsetzen kann und man mit ioctl TIOCCONS die Konsole halt auf das pty device verbiegen konnte.

Vielleicht hast du ja eine andere Idee um das auf ein UDP device oder so zu verbiegen ?
MarcM
Foren-Moderator
Beiträge: 1119
Registriert: Sonntag 9. Juni 2002, 13:28

Beitrag von MarcM »

Ähem, nochmal zum syslogd...

Code: Alles auswählen

syslogd
    syslogd [OPTION]... 

    Linux system and kernel logging utility. Note that this version of syslogd ignores /etc/syslog.conf.

    Options:

        -m MIN          Minutes between MARK lines (default=20, 0=off)
        -n              Run as a foreground process
        -O FILE         Use an alternate log file (default=/var/log/messages)
        -S              Make logging output smaller.
        -s SIZE         Max size (KB) before rotate (default=200KB, 0=off)
        -b NUM          Number of rotated logs to keep (default=1, max=99, 0=purge)
        -R HOST[:PORT]  Log to IP or hostname on PORT (default PORT=514/UDP)
        -L              Log locally and via network logging (default is network only)
        -C [size(KiB)]  Log to a circular buffer (read the buffer using logread)
In der Busybox-Syslogd Version ist doch alles drin ?! Der kann rotieren (File-Größe einstellbar), er kann übers Netzwerk loggen...

ist doch eigentlich alles was wir brauchen....oder nicht ?

Greetz
Marc
ChakaZulu
Developer
Beiträge: 457
Registriert: Sonntag 23. März 2003, 00:39

Beitrag von ChakaZulu »

hannebamb(el) hat geschrieben: Für den Syslog muß die Applikation wissen, das sie das loggen soll, sprich ein einfaches printf, wie es häufig zum debuggen benutzt wird, kommt so nicht rüber, man korrigiere mich, wenn ich da falsch liegen sollte. Daher der Ansatz über das socat und das Aufsetzen des /dev/ttyP0 devices.
Man könnte natürlich auch printf umbiegen ;)

ciao,

ChakaZulu