Logging über's Netz
-
- Developer
- Beiträge: 457
- Registriert: Sonntag 23. März 2003, 00:39
Logging über's Netz
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
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
-
- Senior Member
- Beiträge: 5071
- Registriert: Dienstag 18. September 2001, 00:00
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
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:
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!
..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.
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!
-
- Developer
- Beiträge: 457
- Registriert: Sonntag 23. März 2003, 00:39
-
- Foren-Moderator
- Beiträge: 1119
- Registriert: Sonntag 9. Juni 2002, 13:28
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
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
-
- Image-Team
- Beiträge: 1015
- Registriert: Freitag 7. Februar 2003, 18:37
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.ChakaZulu hat geschrieben:hi,
ok, die busybox hat ja einen syslogd. Warum wird der nicht benutzt? Ist er zu gross?
ciao,
ChakaZulu
Riker
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
-
- Foren-Moderator
- Beiträge: 297
- Registriert: Montag 11. Oktober 2004, 14:51
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
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.
-
- Developer
- Beiträge: 457
- Registriert: Sonntag 23. März 2003, 00:39
-
- Foren-Moderator
- Beiträge: 297
- Registriert: Montag 11. Oktober 2004, 14:51
Und nochwas zum Thema:
http://www.circlemud.org/~jelson/software/emlog/
http://www.circlemud.org/~jelson/software/emlog/
Wobei mir persönlich die erste Alternative besser gefielemlog -- the EMbedded-system LOG-device
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
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.ChakaZulu hat geschrieben:hi,nö, der müsste seine Daten über's Netz an einen anderen Server schicken...Und zum zweiten...wo soll denn der syslogd hinschreiben ? in ne Partition (Platz ? )
Wie stellst Du Dir das vor online 'ueber Netz'....tftp32 hat zB. einen 'Syslogserver' waere's das?
-
- Developer
- Beiträge: 457
- Registriert: Sonntag 23. März 2003, 00:39
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 einenpetgun 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.
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.
denke schon
Wie stellst Du Dir das vor online 'ueber Netz'....tftp32 hat zB. einen 'Syslogserver' waere's das?
ciao,
ChakaZulu
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
-
- Foren-Moderator
- Beiträge: 297
- Registriert: Montag 11. Oktober 2004, 14:51
Das wäre ein Beispiel, ab wann die Daten da sind:
Wie ihr seht, fehlt da eigentlich nur der Kernel selbst[...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
Deswegen bevorzuge ich auch die erstere Möglichkeit, da die Messages "on the fly" auf dem normalen PC auftauchenChakazulu 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
-
- Erleuchteter
- Beiträge: 450
- Registriert: Sonntag 28. Juli 2002, 01:18
-
- Tuxboxer
- Beiträge: 2067
- Registriert: Mittwoch 6. März 2002, 15:29
-
- Erleuchteter
- Beiträge: 682
- Registriert: Samstag 13. Juli 2002, 10:05
-
- Foren-Moderator
- Beiträge: 297
- Registriert: Montag 11. Oktober 2004, 14:51
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.
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.
-
- Developer
- Beiträge: 457
- Registriert: Sonntag 23. März 2003, 00:39
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
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.
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
-
- Foren-Moderator
- Beiträge: 297
- Registriert: Montag 11. Oktober 2004, 14:51
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, ðreq)==-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, ðreq)==-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;
}
Was den Rest betrifft, ist das so hundertprozent korrekt zusammengefasst.
-
- Developer
- Beiträge: 457
- Registriert: Sonntag 23. März 2003, 00:39
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
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
-
- Foren-Moderator
- Beiträge: 297
- Registriert: Montag 11. Oktober 2004, 14:51
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 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 ?
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 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 ?
-
- Foren-Moderator
- Beiträge: 1119
- Registriert: Sonntag 9. Juni 2002, 13:28
Ähem, nochmal zum syslogd...
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
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)
ist doch eigentlich alles was wir brauchen....oder nicht ?
Greetz
Marc
-
- Developer
- Beiträge: 457
- Registriert: Sonntag 23. März 2003, 00:39
Man könnte natürlich auch printf umbiegenhannebamb(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.
ciao,
ChakaZulu