Ereignisprotokoll der FRITZ!Box auf Linux-Server sichern

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
PeterPawn schrieb:
(E)ine offiziell benannte Schnittstelle (...) existiert m.W. (zumindest bisher) aber für das Eventlog auch nicht bzw. früher hatte das "GetDeviceLog" auf der deviceinfoSCPD.xml nicht so richtig funktioniert (abgesehen vom Ausgabeformat, was mir persönlich nicht schmeckt). Vielleicht ist das mit dem Funktionieren ja inzwischen anders ... ein einfacher SOAP-Request schafft da schon Aufklärung.
Zum Vergrößern anklicken....
So, jetzt habe ich mich mal ein bisschen mit dieser SOAP-Schnittstelle bzw. TR-064 bespaßt. (c't 6/2015 for the win!) Ich fand ein kleines Perl-Skript, im Original zum Abruf der WAN-IP-Adresse, das sich problemlos auf GetDeviceLog ändern ließ. Das funktioniert auch und liefert das Log im Text-Format. Leider aber nicht das ganze Eventlog, sondern nur das, was in der Weboberfläche unter dem Reiter "Internetverbindung" angezeigt wird. Wenn ich die AVM-Doku richtig interpretiere, gibt's da auch keine Einflussmöglichkeit. Damit ist diese Schnittstelle für meine Zwecke leider nicht brauchbar.
 
Ok, der Abruf:

Code: 
curl "http://fritz.box/system/syslog.lua" -d 'stylemode=print' -d 'sid='${_SID}
den ich im ersten Entwurf meines Skripts verwendet habe, ist auch unbrauchbar. Er hat einen gravierenden Mangel, der mir leider jetzt erst aufgefallen ist:

Sobald man in der Web-GUI auf der Ereignisse-Seite einen anderen Tab auswählt als "Alle", liefert dieser curl-Abruf nur noch die Ereignisse des angewählten Tabs - und zwar auch dann, wenn der curl-Abruf von einem anderen Rechner aus erfolgt als die WebGUI-Auswahl.

Im Klartext: wenn ich auf meinem Laptop die Ereignisse-Seite aufrufe und den Tab "Internetverbindung" anwähle, sieht das Log-Abrufskript auf meinem Linux-Server fortan nur noch die Internetverbindungs-Ereignisse - so lange, bis ich auf irgendeinem Rechner nochmal die Ereignisse-Seite aufrufe und dann den Tab "Alle" anwähle.
:confused::crazy::mad:

Jetzt hoffe ich bloß, dass query.lua nicht den gleichen Blödsinn macht ...
 
PeterPawn schrieb:
Das kommt jedenfalls davon, wenn man solche Sachen nicht selbst mal laufen läßt und nur in der Theorie entwickelt und dann zu allem Überfluß noch doppelte Kommandos vermeiden will. :blonk: Das ist aber auch wieder nicht selbst getestet ... nicht daß das jetzt falsch rüberkommt.
Zum Vergrößern anklicken....
Ich habe Deine letzte Version jetzt mal live getestet. Natürlich erst nachdem ich sie mir (wie die zuvor auch) einmal im Kopf theoretisch durchgespielt habe, aber das empfiehlst Du ja eh immer jedem (nicht blind irgend etwas auf die Box spielen :) ).
Nur so kann man auch Fehler finden. Ich habe die drittletzte Zeile mit dem 'sed' noch um ein "sortierendes 'sed'"
Code: 
[ $messages -gt 0 ] && sed -n -e "1,${messages}p" $tmpfile | sed -n '1!G;h;$p' | logger
erweitert, so dass die Reihenfolge dann auch chronologisch im Logger ankommt. Gefällt mir viel besser, als meine ursprüngliche Lösung und vor allem sind die Zeitstempel noch vollständig ;)

Da die Frage nach dem Export des Eventlogs der Fritz!Box hier im Forum (und auch in freetz) immer mal wieder hochkommt, bin ich am überlegen, ob ich die fertige (von Dir optimierte) Variante noch einmal als Datei hier hochladen sollte?
Dir auf jeden Fall schon einmal Herzeichen Dank für die Mühe und die Erklärungen :bier:
 
@KingTutt:
Für eine allgemeingültige Lösung würde ich noch das Setzen der ersten U(h)rzeit seitens der Box abwarten ... obwohl man das auch diskutieren kann.

Je nachdem, wann das Kopier-Skript gestartet wird, ist die Zeit durch chronyd noch nicht gesetzt (damit alles auf den 01.01.1970 bezogen) ... aber da ohnehin von "logger" schon Zeitstempel geschrieben werden und eigentlich bei Verwendung von inotifywait die Verzögerung - bevor das im Syslog ankommt - minimal sein sollte, könnte/sollte man ggf. sogar überlegen, mit sed noch die Zeitstempel abzuschneiden - für die ersten Zeilen nach dem Start stimmt das ohnehin nicht, was da in der Ausgabe von "eventsdump" steht, außer man startet das Kopieren erst über "onlinechanged".

EDIT: Ach ja, auch die Kategorie für das Logging würde ich zumindest optional angeben lassen ... es ist eben schöner, wenn das von einem rsyslogd oder auch einem syslog-ng anhand der "facility" in ein gesondertes File geloggt werden kann (wenn man das nicht schon anhand der Absenderadresse machen läßt).
 
Zuletzt bearbeitet:
Meine Fritz!Box hat gerade einen unerwarteten reboot hingelegt. Leider stand natürlich nichts im Logfile, aber der einzige Eintrag nach dem Neustart mit falscher Uhrzeit war "DSL ist verfügbar", alle weiteren hatten bereits eine gültige Uhrzeit.
Ich kenne nur die default facilities vom logger, die mit -p gesetzt werden. Die sind ja aber sehr limitiert, so dass man nur soetwas wie local0.info oder local.notify nehmen könnte. Hilfreich wäre es, wenn dann statt dem user "root" z.B. der Name des Scriptes oder irgend ein Nutzerstring benutzt werden könnte so wie AVM z.B. "AVMMULTID" benutzt.
Oder was meintest Du mit "Kategorie für das Logging"?

EDIT: ok, man kann natürlich das -t Flag benutzen :blonk:
 
Zuletzt bearbeitet:
@KingTutt:
"logger -t fritzbox" z.B. ... ich hoffe mal, der Reboot hatte nichts mit der Protokollierung zu tun.
 
Bin mir noch nicht sicher. Was mich etwas wundert ist der Umstand, dass die temporäre Datei 'eventsdump.log' ständig neu angelegt wird (die Uhrzeit ist immer aktuell) auch wenn gerade keine neuen Events auflaufen. Kann eigentlich nur bedeuten, das da doch eine endlosschleife läuft. Auch die is zu 20% CPU last von [ifx_ssc] deuten irgendwie darauf hin...
 
Dann laß das doch mal mit "sh -x ..." laufen, dann siehst Du ja, was da passiert. Vielleicht funktioniert ja das inotifywait nicht richtig? Obwohl dann ja eigentlich das Skript abgebrochen werden sollte, wenn da ein rc!=0 kommt.

Der einzige Grund, warum das inotifywait ausgelassen werden könnte, wäre lastmessage<0 und das dürfte eigentlich nie passieren nach dem ersten Durchlauf ...
 
Zuletzt bearbeitet:
Moins

Ich hab mal deine Idee mit /sbin/eventctrl aus Post #14 aufgegriffen.
...und mir mal eine gebastelt...
/sbin/eventctrl --> /tmp/cgi-bin/save-events

save-events
Code: 
#!/bin/sh
## saving events to flash (from /var/post_install)
#if [ -x /sbin/eventctrl ] ; then
## unblock events in case of setfactorydefaults
#/sbin/eventctrl -u
## add warm start event
#/sbin/eventadd 651
## save to flash
#/sbin/eventctrl -s
#fi

case $@ in
-r)
/bin/echo -ne > /var/flash/calllog
;;
-s)
/sbin/eventsdump > /var/flash/calllog
;;
*)
/bin/echo 'content-type: text/plain; charset="windows-1252"
'
/bin/cat /var/flash/calllog
;;
esac
exit 0
So wird hübsch bei jeden Neustart* (möglicherweise) das "Corpus Delicti" gesichert.

Dankeschön für den Tip.


* Eigentlich "Runterfahren" durch die /var/post_install
 
Zuletzt bearbeitet:
ich vermute das liegt am inotifywait

Code: 
true
+ [ 12 -ge 0 ]
+ inotifywait -e close_write /var/.ar7events
+ last_message=0
+ [ 0 -ne 0 ]
+ true
+ get_message_count
+ local num
+ testvalue /var/.ar7events 4 8
+ num=12
+ [ 0 -ne 0 ]
+ echo 12
+ messages=12
+ eventsdump
+ get_message_count
+ local num
+ testvalue /var/.ar7events 4 8
+ num=12
+ [ 0 -ne 0 ]
+ echo 12
+ new_messages=12
+ [ 12 -eq 12 ]
+ break
+ messages=0
+ [ 0 -gt 0 ]
+ lastmessage=12
+ true
+ [ 12 -ge 0 ]
+ inotifywait -e close_write /var/.ar7events
+ last_message=0
+ [ 0 -ne 0 ]
+ true
+ get_message_count
+ local num
+ testvalue /var/.ar7events 4 8
+ num=12
+ [ 0 -ne 0 ]
+ echo 12
+ messages=12
+ eventsdump
+ get_message_count
+ local num
+ testvalue /var/.ar7events 4 8
+ num=12
+ [ 0 -ne 0 ]
+ echo 12
+ new_messages=12
+ [ 12 -eq 12 ]
+ break
+ messages=0
+ [ 0 -gt 0 ]
+ lastmessage=12
+ true
+ [ 12 -ge 0 ]
+ inotifywait -e close_write /var/.ar7events
+ last_message=0
+ [ 0 -ne 0 ]
+ true
+ get_message_count
+ local num
+ testvalue /var/.ar7events 4 8
+ num=12
+ [ 0 -ne 0 ]
+ echo 12
+ messages=12
+ eventsdump
+ get_message_count
+ local num
+ testvalue /var/.ar7events 4 8
+ num=12
+ [ 0 -ne 0 ]
+ echo 12
+ new_messages=12
+ [ 12 -eq 12 ]
+ break
+ messages=0
+ [ 0 -gt 0 ]
+ lastmessage=12
 
Einzeln testen ...
Code: 
root@FB7490:~ $ inotifywait -e close_write /var/.ar7events &
root@FB7490:~ $ Setting up watches.
Watches established.
eventadd 1 "It's only a test."
/var/.ar7events CLOSE_WRITE,CLOSE
root@FB7490:~ $
[1]+  Done                       inotifywait -e close_write /var/.ar7events
root@FB7490:~ $
Notfalls finde ich auch irgendwo noch ein statisch gelinktes inotifywait bzw. den Patch gegen Freetz dafür.

EDIT:
Wenn ich mir die Ausgabe bei Dir so ansehe, würde ich fast auf einen einzelnen senkrechten Strich nach dem inotifywait tippen, denn die Zuweisung last_message=0 wird ja immer ausgeführt.
 
Zuletzt bearbeitet:
PeterPawn schrieb:
Einzeln testen ...
Zum Vergrößern anklicken....
Grr viel simpler, es gibt kein inotifywait *shame* Ich achte das wäre per default in der AVM BB :eek:

Muss ich mich wohl morgen drum kümmern, nun wird es Zeit für eine Mütze Schlaf :sad:
 
@KingTutt:
Achtung, das ist gar kein Applet der BB ... entweder Du nimmst das Freetz-Paket dazu (das ist aber dynamisch gelinkt und braucht dann die libinotify.so noch irgendwo - oder Du linkst eben statisch) oder Du greifst doch auf das inotifyd-Applet der BB zurück ... der Ablauf ist dann aber ein anderer, denn dieser Daemon ruft ein Kommando (das kann auch ein Skript sein) auf, wenn das Event (also das close_write) auftritt (s. weiter vorne, wo ich den schon mal angesprochen habe).
 
tgs-bonn schrieb:
Im Klartext: wenn ich auf meinem Laptop die Ereignisse-Seite aufrufe und den Tab "Internetverbindung" anwähle, sieht das Log-Abrufskript auf meinem Linux-Server fortan nur noch die Internetverbindungs-Ereignisse - so lange, bis ich auf irgendeinem Rechner nochmal die Ereignisse-Seite aufrufe und dann den Tab "Alle" anwähle.
:confused::crazy::mad:

Jetzt hoffe ich bloß, dass query.lua nicht den gleichen Blödsinn macht ...
Zum Vergrößern anklicken....

Doch, tut es.

AAAAAaaargh!:kotz:
Ich mag nicht mehr ...
 
@tgs-bonn:
OK, das ist zwar hier ein von Dir eröffneter Thread und Du hast auch klar geschrieben, daß Du alles von extern machen willst ... aber ab 06.30 kann man eben nicht mehr mit "webcm" und der Einstellung "logger:settings/filter=0" von außen den Protokollfilter wieder umschalten ... aber dafür kann man problemlos immer noch (vor anderen Aufrufen) die Seite "syslog.lua&tab=aus" aufrufen bzw. das einfach als zusätzlichen Parameter mit angeben, wenn man ohnehin die HTML-Ausgabe der Seite "syslog.lua" verwenden und parsen will.

Also verstehe ich irgendwie das "Angeödetsein" nicht so richtig - daß die Verarbeitung des Logs "von außen" nicht so einfach ist, habe ich Dir von Beginn an sagen wollen (bzw. ich bilde mir ein, das deutlich zum Ausdruck gebracht zu haben). Wenn Du dann etwas mehr Aufwand treiben mußt, mag Dich das zwar überraschen ... aber über "stamina" sagen solche Stellen wie
tgs-bonn schrieb:
Ich mag nicht mehr ...
Zum Vergrößern anklicken....
etwas aus, was Du sicherlich so nicht zeigen wolltest.
 
PeterPawn schrieb:
@KingTutt:
Achtung, das ist gar kein Applet der BB ... entweder Du nimmst das Freetz-Paket dazu (das ist aber dynamisch gelinkt und braucht dann die libinotify.so noch irgendwo - oder Du linkst eben statisch) oder Du greifst doch auf das inotifyd-Applet der BB zurück ... der Ablauf ist dann aber ein anderer, denn dieser Daemon ruft ein Kommando (das kann auch ein Skript sein) auf, wenn das Event (also das close_write) auftritt (s. weiter vorne, wo ich den schon mal angesprochen habe).
Zum Vergrößern anklicken....
So, neue Runde, neues Glück...

Ich habe mich der Einfachheit halber zunächst einmal für das Paket Inotify-Tools entschieden, frei nach dem Motto "erst mal eine Version ans laufen bekommen". Das Paket bringt die 'libinotifytools.so' mit. Der von Dir manuell vorgeschlagene Test funktioniert damit auch super. Nach dem Booten und bei einen Reboot kommen die Nachrichten auch wie erwartet im logger an, so dass das 'inotifywait' in der Hinsicht wie erwartet arbeite. Nur zwischen drin ist noch irgend wie der Wurm drin. Da werden neu aufgelaufene neue Events einfach nicht abgearbeitet. D.h. wenn man sich über das WebIF z.B. einloggt, oder eine Portfreigabe ändert, laufen die neuen Events zwar im Syslog des WebIF auf, nicht aber im logger. Wenn ich das richtig sehe, wird das 'inotifywait' einfach nicht getriggert, denn die neuen Nachrichten laufen schon nicht im temporären File eventsdump.log auf. Führe ich wiederum auf der Shell ein
Code: 
eventadd 1 "It's only a test."
aus, werden alle alten Ereignisse ink. dem manuell erzeugten Event abgearbeitet. D.h. das 'eventadd' triggert das 'inotifywait' so wie man es erwartet, nicht aber "der normale Weg über das WebIF". Kann es sein, dass das WebIF nur ein modify event auslöst, während das 'eventadd' auch ein close_write auslöst?
 
KingTutt schrieb:
Kann es sein, dass das WebIF nur ein modify event auslöst, während das 'eventadd' auch ein close_write auslöst?
Zum Vergrößern anklicken....
Denkbar, würde aber heißen, daß da jemand die Datei permanent offenhält. Kann ich mir eigentlich nicht vorstellen (lsof zeigt mir auch nichts in dieser Richtung an) ... vielleicht reagiert aber "close_write" auch nur auf fdclose()-Calls, wenn beim fdopen() explizit "w" abgegeben wurde. Verringere die Anforderung an der Stelle doch mal auf "close" und teste noch einmal ... dann wirst Du zwar sicherlich öfter aufgerufen (auch bei der Ausgabe von Syslog-Einträgen über das GUI), aber solange die Erkennung neuer Einträge funktioniert, muß Dich das ja nicht stören. Ich würde jedenfalls davon ausgehen, daß ein "write"-Event einfach zu häufig auftritt und vor allem, daß nach einem solchen Event die Datei nicht unbedingt in einem konsistenten Zustand ist, wie sie es nach einem "close" aber sein müßte.
 
PeterPawn schrieb:
ab 06.30 kann man eben nicht mehr mit "webcm" und der Einstellung "logger:settings/filter=0" von außen den Protokollfilter wieder umschalten
Zum Vergrößern anklicken....
Ich wusste gar nicht, dass es eine solche Möglichkeit früher gab, deshalb habe ich in dieser Richtung eh nichts erwartet.
Aber Deine Formulierung "Protokollfilter umschalten" macht auch schon wieder etwas klarer, was da abläuft. Danke!

PeterPawn schrieb:
aber dafür kann man problemlos immer noch (vor anderen Aufrufen) die Seite "syslog.lua&tab=aus" aufrufen bzw. das einfach als zusätzlichen Parameter mit angeben, wenn man ohnehin die HTML-Ausgabe der Seite "syslog.lua" verwenden und parsen will.
Zum Vergrößern anklicken....
Ich habe es nicht eigens erwähnt, aber das war auch meine erste Idee. Leider hatte keine der beiden Varianten, weder als zusätzlicher Parameter noch separater Aufruf vorweg, den gewünschten Erfolg.
Aber wenn Du sagst, das müsste gehen, experimentiere ich daran noch etwas weiter. (Lk 5,5)

EDIT: Ok, es war wieder ein curl-Problem.
Code: 
curl -s -G "${FBURL}/system/syslog.lua" -d 'tab=aus' -d 'stylemode=print' -d 'sid='${_SID}
funktioniert. Ohne die Option -G wird 'tab=aus' ignoriert. Das heißt, die FRITZ!Box interpretiert den Parameter nur, wenn sie ihn als Bestandteil der URL bekommt, nicht als POST-Parameter.

EDIT2: Der Dateianhang in #1 ist entsprechend aktualisiert.
Ich bin nun doch dabei geblieben, die Daten aus syslog.lua zu extrahieren. Da ich die ohnehin aufrufen muss, um den Protokollfilter umzuschalten, sehe ich in query.lua keinen Vorteil mehr.

PeterPawn schrieb:
Also verstehe ich irgendwie das "Angeödetsein" nicht so richtig
Zum Vergrößern anklicken....
Sorry, ich kenne die Niederungen der Fritzbox halt noch nicht so gut wie Du und habe offenbar etwas zu hohe Erwartungen. Aber ich werde mich bemühen, mich in Zukunft hier auf die Fakten zu beschränken und die persönliche Bewertung rauszulassen. Gestern abend war es halt schon etwas spät, da lässt die Selbstbeherrschung manchmal nach.
 
Zuletzt bearbeitet von einem Moderator:
PeterPawn schrieb:
Verringere die Anforderung an der Stelle doch mal auf "close" und teste noch einmal ... dann wirst Du zwar sicherlich öfter aufgerufen (auch bei der Ausgabe von Syslog-Einträgen über das GUI), aber solange die Erkennung neuer Einträge funktioniert, muß Dich das ja nicht stören.
Zum Vergrößern anklicken....
Gleiches Bild :(
Der letzte Eintrag war direkt nach dem Start im tempfile war (sogar noch mit falschem Zeitstempel)
Code: 
01.01.70 00:09:50 Running onlinechanged: online

Danach kommt erst wieder etwas (alles was aufgelaufen ist), wenn ich über die shell ein 'eventadd' auslösen. Sehr eigenartig, denn die erwarteten Prozesse laufen:
Code: 
1976 root      1304 S    {busybox} ash /var/tmp/events2syslog
2377 root      1052 S    inotifywait -e close /var/.ar7events
..
..
eventadd 1 "It's only a test."
..
..
1976 root      1304 S    {busybox} ash /var/tmp/events2syslog
3005 root      1052 S    inotifywait -e close /var/.ar7events

Der 'events2syslog' hat die gleichen PIDs, der 'inotifywait' Prozess wechselt

EDIT: Die Datei .ar7events ist bei mir übrigens von gleich mehreren Prozessen lesend geönffnet

Code: 
# lsof | grep ar7ev
ctlmgr    1060 1126    root  mem       REG       0,11    40000   6324 /var/.ar7events
multid    1108         root  mem       REG       0,11    40000   6324 /var/.ar7events
dsld      1167         root  mem       REG       0,11    40000   6324 /var/.ar7events

EDIT2: Habe auch noch mal ein 'modify' getestet, das bringt im Gegensatz zu Deiner Befürchtung noch weniger. Nicht mal ein manuelles 'eventadd' wird dann noch vom 'inotifywait' berücksichtigt :confused:
 
Zuletzt bearbeitet:
KingTutt schrieb:
Die Datei .ar7events ist bei mir übrigens von gleich mehreren Prozessen lesend geönffnet
Zum Vergrößern anklicken....
Das ist ja mal komisch ... bei mir von keinem einzigen (und die 7490 - 113.06.30 - "ackert" auch tatsächlich), hier das "komplette" lsof:
Code: 
1	/wrapper/bin/busybox	/wrapper/dev/console
1	/wrapper/bin/busybox	/wrapper/dev/console
1	/wrapper/bin/busybox	/wrapper/dev/console
555	/sbin/udevd	/dev/null
555	/sbin/udevd	/dev/null
555	/sbin/udevd	/dev/null
555	/sbin/udevd	/dev/.udev/queue.bin
555	/sbin/udevd	socket:[451]
555	/sbin/udevd	socket:[452]
555	/sbin/udevd	inotify
555	/sbin/udevd	anon_inode:[signalfd]
555	/sbin/udevd	socket:[455]
555	/sbin/udevd	socket:[456]
559	/bin/busybox	/dev/null
559	/bin/busybox	/dev/console
559	/bin/busybox	/dev/ttyS0
559	/bin/busybox	/var/tmp/nohup.out
792	/bin/configd	/dev/null
792	/bin/configd	/dev/ttyS0
792	/bin/configd	/dev/ttyS0
792	/bin/configd	socket:[1932]
792	/bin/configd	socket:[695047]
792	/bin/configd	socket:[4986]
792	/bin/configd	socket:[5118]
792	/bin/configd	socket:[5223]
843	/usr/sbin/dsl_control	/dev/ttyS0
843	/usr/sbin/dsl_control	/dev/ttyS0
843	/usr/sbin/dsl_control	/dev/ttyS0
843	/usr/sbin/dsl_control	/dev/mei_vr9
843	/usr/sbin/dsl_control	/dev/dsl_vr9/0
843	/usr/sbin/dsl_control	/dev/avm_event
843	/usr/sbin/dsl_control	/var/log/dsl_monitor.txt
857	/usr/sbin/dsl_monitor	/dev/null
857	/usr/sbin/dsl_monitor	/dev/null
857	/usr/sbin/dsl_monitor	/dev/null
857	/usr/sbin/dsl_monitor	/var/log/dsl_monitor.txt
857	/usr/sbin/dsl_monitor	/var/log/dsl_monitor.txt
857	/usr/sbin/dsl_monitor	/dev/watchdog
857	/usr/sbin/dsl_monitor	/dev/avm_event
857	/usr/sbin/dsl_monitor	/dev/led
857	/usr/sbin/dsl_monitor	/var/dsl/pipe/dslmanager.cmd
857	/usr/sbin/dsl_monitor	/dev/avm_event
997	/sbin/hd-idle	/dev/null
997	/sbin/hd-idle	/dev/null
997	/sbin/hd-idle	/dev/console
997	/sbin/hd-idle	/dev/null
997	/sbin/hd-idle	/dev/null
997	/sbin/hd-idle	/dev/null
997	/sbin/hd-idle	inotify
1024	/bin/avmipcd	/dev/null
1024	/bin/avmipcd	/dev/null
1024	/bin/avmipcd	/dev/null
1024	/bin/avmipcd	socket:[3066]
1024	/bin/avmipcd	socket:[3068]
1027	/sbin/l2tpv3d	/dev/null
1027	/sbin/l2tpv3d	/dev/null
1027	/sbin/l2tpv3d	/dev/null
1027	/sbin/l2tpv3d	socket:[3071]
1027	/sbin/l2tpv3d	socket:[3085]
1027	/sbin/l2tpv3d	/dev/watchdog
1027	/sbin/l2tpv3d	socket:[3188]
1027	/sbin/l2tpv3d	socket:[3190]
1039	/sbin/upnpd	/dev/null
1039	/sbin/upnpd	/dev/null
1039	/sbin/upnpd	/dev/null
1039	/sbin/upnpd	socket:[3125]
1039	/sbin/upnpd	/dev/watchdog
1039	/sbin/upnpd	socket:[6198]
1039	/sbin/upnpd	socket:[6227]
1039	/sbin/upnpd	socket:[6228]
1039	/sbin/upnpd	socket:[6229]
1039	/sbin/upnpd	socket:[6344]
1039	/sbin/upnpd	socket:[6360]
1039	/sbin/upnpd	socket:[695312]
1039	/sbin/upnpd	socket:[6600]
1039	/sbin/upnpd	socket:[6601]
1039	/sbin/upnpd	socket:[6602]
1039	/sbin/upnpd	socket:[696456]
1039	/sbin/upnpd	socket:[9457]
1048	/sbin/multid	/dev/null
1048	/sbin/multid	/dev/null
1048	/sbin/multid	/dev/null
1048	/sbin/multid	socket:[3184]
1048	/sbin/multid	socket:[3185]
1048	/sbin/multid	/dev/avm_event
1048	/sbin/multid	/dev/kdsld_multid
1048	/sbin/multid	socket:[4030]
1048	/sbin/multid	socket:[4035]
1048	/sbin/multid	socket:[4036]
1048	/sbin/multid	socket:[4037]
1048	/sbin/multid	socket:[4055]
1048	/sbin/multid	socket:[1736091]
1048	/sbin/multid	socket:[1736094]
1048	/sbin/multid	socket:[6644]
1048	/sbin/multid	socket:[1736098]
1048	/sbin/multid	socket:[4121]
1048	/sbin/multid	/dev/watchdog
1048	/sbin/multid	socket:[4164]
1048	/sbin/multid	socket:[4167]
1048	/sbin/multid	socket:[4799]
1048	/sbin/multid	socket:[4800]
1048	/sbin/multid	socket:[4801]
1048	/sbin/multid	socket:[4802]
1048	/sbin/multid	socket:[5042]
1048	/sbin/multid	socket:[1736099]
1053	/sbin/ddnsd	/dev/null
1053	/sbin/ddnsd	/dev/null
1053	/sbin/ddnsd	/dev/null
1053	/sbin/ddnsd	socket:[3245]
1053	/sbin/ddnsd	socket:[3247]
1053	/sbin/ddnsd	/dev/watchdog
1053	/sbin/ddnsd	socket:[3251]
1059	/sbin/upnpdevd	/dev/null
1059	/sbin/upnpdevd	/dev/null
1059	/sbin/upnpdevd	/dev/null
1059	/sbin/upnpdevd	socket:[3266]
1059	/sbin/upnpdevd	/dev/watchdog
1059	/sbin/upnpdevd	socket:[3268]
1059	/sbin/upnpdevd	socket:[3281]
1059	/sbin/upnpdevd	socket:[3298]
1069	/sbin/wland	/dev/null
1069	/sbin/wland	/dev/null
1069	/sbin/wland	/dev/null
1069	/sbin/wland	/var/tmp/wland_support.log
1069	/sbin/wland	/dev/watchdog
1069	/sbin/wland	socket:[8154]
1105	/sbin/dsld	/dev/null
1105	/sbin/dsld	/dev/null
1105	/sbin/dsld	/dev/null
1105	/sbin/dsld	socket:[3741]
1105	/sbin/dsld	socket:[3827]
1105	/sbin/dsld	/dev/kdsld
1105	/sbin/dsld	socket:[3932]
1105	/sbin/dsld	/dev/watchdog
1105	/sbin/dsld	/dev/avm_event
1105	/sbin/dsld	socket:[5774]
1105	/sbin/dsld	socket:[8488]
1105	/sbin/dsld	socket:[8701]
1153	/usr/bin/pbd	/dev/null
1153	/usr/bin/pbd	/dev/null
1153	/usr/bin/pbd	/dev/null
1153	/usr/bin/pbd	anon_inode:[eventpoll]
1153	/usr/bin/pbd	socket:[4097]
1153	/usr/bin/pbd	socket:[4099]
1153	/usr/bin/pbd	socket:[4104]
1153	/usr/bin/pbd	/dev/watchdog
1153	/usr/bin/pbd	socket:[4106]
1153	/usr/bin/pbd	socket:[4678]
1153	/usr/bin/pbd	socket:[4109]
1153	/usr/bin/pbd	socket:[4110]
1153	/usr/bin/pbd	socket:[4679]
1153	/usr/bin/pbd	socket:[695343]
1153	/usr/bin/pbd	socket:[695344]
1153	/usr/bin/pbd	socket:[5636]
1153	/usr/bin/pbd	socket:[5637]
1153	/usr/bin/pbd	/etc/htmltext_de.db
1280	/bin/busybox	/dev/null
1280	/bin/busybox	/dev/null
1280	/bin/busybox	/dev/null
1280	/bin/busybox	socket:[4673]
1280	/bin/busybox	socket:[1369920]
1280	/bin/busybox	/dev/ptmx
1280	/bin/busybox	socket:[1972464]
1280	/bin/busybox	/dev/ptmx
1280	/bin/busybox	socket:[2253158]
1280	/bin/busybox	/dev/ptmx
1283	/usr/bin/telefon	/dev/null
1283	/usr/bin/telefon	/dev/null
1283	/usr/bin/telefon	/dev/console
1283	/usr/bin/telefon	anon_inode:[eventpoll]
1283	/usr/bin/telefon	socket:[4514]
1283	/usr/bin/telefon	/dev/capi20
1283	/usr/bin/telefon	/dev/capi20
1283	/usr/bin/telefon	/dev/capi20
1283	/usr/bin/telefon	/dev/capi20
1283	/usr/bin/telefon	/dev/led
1283	/usr/bin/telefon	socket:[4670]
1283	/usr/bin/telefon	socket:[4671]
1283	/usr/bin/telefon	/dev/avm_event
1283	/usr/bin/telefon	/dev/watchdog
1283	/usr/bin/telefon	socket:[4676]
1283	/usr/bin/telefon	socket:[4677]
1283	/usr/bin/telefon	socket:[4693]
1283	/usr/bin/telefon	socket:[4695]
1283	/usr/bin/telefon	socket:[5815]
1283	/usr/bin/telefon	/var/media/ftp/system/FRITZ/voicebox/lock
1283	/usr/bin/telefon	/dev/capi20
1283	/usr/bin/telefon	socket:[5019]
1283	/usr/bin/telefon	socket:[5020]
1283	/usr/bin/telefon	socket:[649257]
1283	/usr/bin/telefon	anon_inode:[timerfd]
1283	/usr/bin/telefon	socket:[2297756]
1297	/usr/bin/dect_manager	/dev/null
1297	/usr/bin/dect_manager	/dev/null
1297	/usr/bin/dect_manager	/dev/console
1297	/usr/bin/dect_manager	pipe:[4906]
1297	/usr/bin/dect_manager	pipe:[4906]
1297	/usr/bin/dect_manager	/dev/led
1297	/usr/bin/dect_manager	socket:[4907]
1297	/usr/bin/dect_manager	socket:[4909]
1297	/usr/bin/dect_manager	/dev/dect_io
1297	/usr/bin/dect_manager	socket:[4985]
1297	/usr/bin/dect_manager	socket:[5014]
1297	/usr/bin/dect_manager	socket:[5018]
1297	/usr/bin/dect_manager	socket:[5241]
1297	/usr/bin/dect_manager	socket:[5552]
1297	/usr/bin/dect_manager	socket:[5630]
1297	/usr/bin/dect_manager	socket:[5633]
1297	/usr/bin/dect_manager	socket:[5634]
1297	/usr/bin/dect_manager	socket:[5644]
1297	/usr/bin/dect_manager	socket:[5857]
1306	/bin/voipd	/dev/null
1306	/bin/voipd	/dev/null
1306	/bin/voipd	/dev/null
1306	/bin/voipd	socket:[4862]
1306	/bin/voipd	socket:[4863]
1306	/bin/voipd	/dev/capi20
1306	/bin/voipd	/dev/capi20
1306	/bin/voipd	socket:[4864]
1306	/bin/voipd	socket:[4865]
1306	/bin/voipd	socket:[4875]
1306	/bin/voipd	/dev/watchdog
1313	/usr/bin/faxd	/dev/led
1313	/usr/bin/faxd	/dev/watchdog
1313	/usr/bin/faxd	/dev/capi20
1313	/usr/bin/faxd	/dev/capi20
1313	/usr/bin/faxd	inotify
1313	/usr/bin/faxd	/etc/htmltext_de.db
1337	/bin/busybox	/dev/null
1337	/bin/busybox	/dev/null
1337	/bin/busybox	/dev/null
1337	/bin/busybox	socket:[5213]
1337	/bin/busybox	socket:[696177]
1337	/bin/busybox	socket:[696178]
1357	/sbin/feedd	/dev/null
1357	/sbin/feedd	/dev/null
1357	/sbin/feedd	/dev/null
1357	/sbin/feedd	socket:[5109]
1357	/sbin/feedd	socket:[5117]
1357	/sbin/feedd	socket:[5120]
1357	/sbin/feedd	socket:[5247]
1357	/sbin/feedd	socket:[5645]
1362	/sbin/udevd	/dev/null
1362	/sbin/udevd	/dev/null
1362	/sbin/udevd	/dev/null
1362	/sbin/udevd	inotify
1362	/sbin/udevd	socket:[456]
1362	/sbin/udevd	socket:[5128]
1377	/bin/pictured	/var/run/pictured.pid
1377	/bin/pictured	socket:[5190]
1377	/bin/pictured	/dev/console
1377	/bin/pictured	socket:[5631]
1385	/usr/bin/audiod	/dev/null
1385	/usr/bin/audiod	/dev/null
1385	/usr/bin/audiod	/dev/null
1385	/usr/bin/audiod	socket:[5222]
1385	/usr/bin/audiod	socket:[5225]
1385	/usr/bin/audiod	socket:[5242]
1385	/usr/bin/audiod	socket:[5246]
1404	/sbin/udevd	/dev/null
1404	/sbin/udevd	/dev/null
1404	/sbin/udevd	/dev/null
1404	/sbin/udevd	inotify
1404	/sbin/udevd	socket:[456]
1404	/sbin/udevd	socket:[5256]
1406	/sbin/hostapd	/dev/null
1406	/sbin/hostapd	/dev/console
1406	/sbin/hostapd	/dev/null
1406	/sbin/hostapd	/var/tmp/wland_support.log
1406	/sbin/hostapd	socket:[3315]
1406	/sbin/hostapd	/dev/watchdog
1406	/sbin/hostapd	socket:[6785]
1406	/sbin/hostapd	socket:[5439]
1406	/sbin/hostapd	socket:[6810]
1406	/sbin/hostapd	socket:[6811]
1406	/sbin/hostapd	socket:[6812]
1406	/sbin/hostapd	socket:[6824]
1406	/sbin/hostapd	socket:[6833]
1406	/sbin/hostapd	socket:[6993]
1406	/sbin/hostapd	socket:[7265]
1406	/sbin/hostapd	socket:[7290]
1406	/sbin/hostapd	socket:[7291]
1406	/sbin/hostapd	socket:[7298]
1406	/sbin/hostapd	socket:[7306]
1406	/sbin/hostapd	socket:[7316]
1406	/sbin/hostapd	socket:[7451]
1413	/usr/bin/aha	/dev/null
1413	/usr/bin/aha	/dev/console
1413	/usr/bin/aha	/dev/console
1413	/usr/bin/aha	anon_inode:[timerfd]
1413	/usr/bin/aha	pipe:[5547]
1413	/usr/bin/aha	pipe:[5547]
1413	/usr/bin/aha	socket:[5548]
1413	/usr/bin/aha	/dev/watchdog
1413	/usr/bin/aha	socket:[5550]
1413	/usr/bin/aha	/var/flash/ahanet.cfg
1413	/usr/bin/aha	socket:[5554]
1413	/usr/bin/aha	socket:[5555]
1413	/usr/bin/aha	socket:[5556]
1413	/usr/bin/aha	socket:[5587]
1413	/usr/bin/aha	socket:[5588]
1413	/usr/bin/aha	socket:[5589]
1413	/usr/bin/aha	pipe:[5590]
1413	/usr/bin/aha	pipe:[5590]
1413	/usr/bin/aha	anon_inode:[eventpoll]
1413	/usr/bin/aha	socket:[5591]
1413	/usr/bin/aha	socket:[5742]
1413	/usr/bin/aha	socket:[5743]
1413	/usr/bin/aha	socket:[5744]
1413	/usr/bin/aha	socket:[5745]
1413	/usr/bin/aha	socket:[5746]
1413	/usr/bin/aha	socket:[5747]
1413	/usr/bin/aha	socket:[5858]
1413	/usr/bin/aha	pipe:[5859]
1413	/usr/bin/aha	pipe:[5859]
1413	/usr/bin/aha	pipe:[5860]
1413	/usr/bin/aha	pipe:[5860]
1413	/usr/bin/aha	socket:[9360]
1413	/usr/bin/aha	socket:[9361]
1468	/wrapper/bin/busybox	/dev/ttyS0
1468	/wrapper/bin/busybox	/dev/ttyS0
1468	/wrapper/bin/busybox	/dev/ttyS0
1481	/sbin/wpa_supplicant	/dev/null
1481	/sbin/wpa_supplicant	/dev/console
1481	/sbin/wpa_supplicant	/dev/null
1481	/sbin/wpa_supplicant	/var/tmp/wland_support.log
1481	/sbin/wpa_supplicant	socket:[3315]
1481	/sbin/wpa_supplicant	/dev/watchdog
1481	/sbin/wpa_supplicant	socket:[5758]
1744	/bin/busybox	socket:[6310]
1744	/bin/busybox	/dev/null
1744	/bin/busybox	/dev/null
1744	/bin/busybox	socket:[6538]
1911	/var/media/ftp/bin/dropbearmulti	/dev/null
1911	/var/media/ftp/bin/dropbearmulti	/dev/null
1911	/var/media/ftp/bin/dropbearmulti	/dev/null
1911	/var/media/ftp/bin/dropbearmulti	socket:[6581]
1911	/var/media/ftp/bin/dropbearmulti	socket:[6582]
1911	/var/media/ftp/bin/dropbearmulti	socket:[6583]
1971	/bin/busybox	/dev/null
1971	/bin/busybox	/dev/null
1971	/bin/busybox	/dev/null
1971	/bin/busybox	socket:[6847]
1991	/bin/busybox	/dev/null
1991	/bin/busybox	/var/tmp/tmp.MbB9gh
1991	/bin/busybox	/var/tmp/tmp.MbB9gh
1991	/bin/busybox	/var/custom/showvpnstate.sh
2381	/bin/usermand2	/dev/null
2381	/bin/usermand2	/dev/null
2381	/bin/usermand2	/dev/null
2381	/bin/usermand2	/dev/userman
2381	/bin/usermand2	/dev/kdsld_user
2381	/bin/usermand2	socket:[8416]
2381	/bin/usermand2	socket:[8417]
2381	/bin/usermand2	socket:[695366]
2381	/bin/usermand2	/dev/watchdog
2384	/sbin/contfiltd	/dev/null
2384	/sbin/contfiltd	/dev/null
2384	/sbin/contfiltd	/dev/null
2384	/sbin/contfiltd	socket:[8427]
2384	/sbin/contfiltd	socket:[8428]
2384	/sbin/contfiltd	/dev/userman
2384	/sbin/contfiltd	/dev/watchdog
2384	/sbin/contfiltd	/dev/userman_url
2384	/sbin/contfiltd	/etc/htmltext_de.db
2513	/bin/avmike	/dev/null
2513	/bin/avmike	/dev/null
2513	/bin/avmike	/dev/null
2513	/bin/avmike	socket:[8692]
2513	/bin/avmike	socket:[8693]
2513	/bin/avmike	socket:[8696]
2513	/bin/avmike	socket:[8699]
2513	/bin/avmike	socket:[8702]
2513	/bin/avmike	/dev/urandom
3103	/sbin/chronyd	/dev/null
3103	/sbin/chronyd	/dev/null
3103	/sbin/chronyd	/dev/null
3103	/sbin/chronyd	socket:[9708]
3103	/sbin/chronyd	socket:[9710]
3103	/sbin/chronyd	socket:[9711]
3103	/sbin/chronyd	socket:[9712]
3103	/sbin/chronyd	socket:[9713]
3104	/var/media/ftp/bin/stunnel	/dev/null
3104	/var/media/ftp/bin/stunnel	/dev/null
3104	/var/media/ftp/bin/stunnel	/dev/null
3104	/var/media/ftp/bin/stunnel	pipe:[9537]
3104	/var/media/ftp/bin/stunnel	pipe:[9537]
3104	/var/media/ftp/bin/stunnel	socket:[9718]
3104	/var/media/ftp/bin/stunnel	socket:[9719]
3104	/var/media/ftp/bin/stunnel	socket:[9720]
12780	/bin/busybox	/dev/pts/2
12780	/bin/busybox	/var/media/ftp/113.06.30_lsof.log
12780	/bin/busybox	/dev/pts/2
12780	/bin/busybox	/dev/tty
12780	/bin/busybox	/dev/pts/2
13432	/bin/busybox	/dev/pts/1
13432	/bin/busybox	/dev/pts/1
13432	/bin/busybox	/dev/pts/1
13432	/bin/busybox	/dev/tty
15917	/bin/busybox	/usr/www/avm/system/syslog.lua
15917	/bin/busybox	/dev/pts/1
15917	/bin/busybox	/dev/pts/1
15917	/bin/busybox	/dev/pts/1
16808	/bin/busybox	/dev/pts/0
16808	/bin/busybox	/dev/pts/0
16808	/bin/busybox	/dev/pts/0
16808	/bin/busybox	/dev/tty
17609	/bin/busybox	/dev/null
17609	/bin/busybox	/var/tmp/tmp.MbB9gh
17609	/bin/busybox	/var/tmp/tmp.MbB9gh
20171	/sbin/mount.davfs	/dev/null
20171	/sbin/mount.davfs	/dev/null
20171	/sbin/mount.davfs	/dev/null
20171	/sbin/mount.davfs	socket:[1980981]
20171	/sbin/mount.davfs	socket:[2039144]
20171	/sbin/mount.davfs	/dev/fuse
27455	/usr/bin/ctlmgr	/dev/null
27455	/usr/bin/ctlmgr	/dev/null
27455	/usr/bin/ctlmgr	/dev/null
27455	/usr/bin/ctlmgr	/dev/watchdog
27455	/usr/bin/ctlmgr	socket:[694917]
27455	/usr/bin/ctlmgr	socket:[694963]
27455	/usr/bin/ctlmgr	/etc/htmltext_de.db
27455	/usr/bin/ctlmgr	socket:[694988]
27455	/usr/bin/ctlmgr	/var/log/dsl_ui.txt
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	/var/log/dsl_monitor.txt
27455	/usr/bin/ctlmgr	/var/log/dsl_ui.txt
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	socket:[694991]
27455	/usr/bin/ctlmgr	socket:[695038]
27455	/usr/bin/ctlmgr	socket:[695039]
27455	/usr/bin/ctlmgr	socket:[695324]
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	socket:[695044]
27455	/usr/bin/ctlmgr	socket:[695046]
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	/dev/avm_event
27455	/usr/bin/ctlmgr	socket:[695305]
27455	/usr/bin/ctlmgr	socket:[695307]
27455	/usr/bin/ctlmgr	socket:[695309]
27455	/usr/bin/ctlmgr	socket:[695311]
27455	/usr/bin/ctlmgr	socket:[695313]
27455	/usr/bin/ctlmgr	socket:[695314]
27455	/usr/bin/ctlmgr	socket:[695315]
27455	/usr/bin/ctlmgr	socket:[695316]
27455	/usr/bin/ctlmgr	socket:[695325]
27455	/usr/bin/ctlmgr	socket:[695326]
27455	/usr/bin/ctlmgr	socket:[695327]
27455	/usr/bin/ctlmgr	socket:[695328]
27455	/usr/bin/ctlmgr	socket:[695329]
27455	/usr/bin/ctlmgr	socket:[695330]
27455	/usr/bin/ctlmgr	socket:[695331]
27455	/usr/bin/ctlmgr	socket:[695332]
27455	/usr/bin/ctlmgr	socket:[695461]
27455	/usr/bin/ctlmgr	socket:[695341]
27455	/usr/bin/ctlmgr	socket:[695342]
27455	/usr/bin/ctlmgr	socket:[695371]
27455	/usr/bin/ctlmgr	socket:[695462]
27455	/usr/bin/ctlmgr	socket:[695831]
27455	/usr/bin/ctlmgr	socket:[1366264]
27455	/usr/bin/ctlmgr	/dev/capi20
27455	/usr/bin/ctlmgr	/dev/capi20
27771	/sbin/nmbd	/dev/null
27771	/sbin/nmbd	/dev/null
27771	/sbin/nmbd	/var/tmp/samba/var/log.nmbd
27771	/sbin/nmbd	/var/tmp/samba/var/log.nmbd
27771	/sbin/nmbd	/var/tmp/samba/var/locks/nmbd.pid
27771	/sbin/nmbd	/var/tmp/samba/var/locks/messages.tdb
27771	/sbin/nmbd	socket:[696150]
27771	/sbin/nmbd	socket:[696151]
27771	/sbin/nmbd	socket:[696153]
27771	/sbin/nmbd	socket:[696154]
27771	/sbin/nmbd	pipe:[696155]
27771	/sbin/nmbd	pipe:[696155]
27771	/sbin/nmbd	/var/tmp/samba/var/locks/unexpected.tdb
Allerdings ist das bei mir ein lsof-Applet der BB und bei Dir offenbar ein gesondertes Binary.

Aber auch wenn ich direkt beim ctlmgr in das procfs schaue, sieht es nicht viel anders aus:
Code: 
root@FB7490:~ $ ls -l /proc/$(pidof ctlmgr)/fd
lrwx------    1 root     root            64 Aug  7 11:34 0 -> /dev/null
lrwx------    1 root     root            64 Aug  7 11:34 1 -> /dev/null
l-wx------    1 root     root            64 Aug  7 11:34 10 -> /var/log/dsl_monitor.txt
l-wx------    1 root     root            64 Aug  7 11:34 11 -> /var/log/dsl_ui.txt
lrwx------    1 root     root            64 Aug  7 11:34 12 -> /dev/avm_event
lrwx------    1 root     root            64 Aug  7 11:34 13 -> /dev/avm_event
lrwx------    1 root     root            64 Aug  7 11:34 14 -> /dev/avm_event
lrwx------    1 root     root            64 Aug  7 11:34 15 -> /dev/avm_event
lrwx------    1 root     root            64 Aug  7 11:34 16 -> /dev/avm_event
lrwx------    1 root     root            64 Aug  7 11:34 17 -> socket:[694991]
lrwx------    1 root     root            64 Aug  7 11:34 18 -> socket:[695038]
lrwx------    1 root     root            64 Aug  7 11:34 19 -> socket:[695039]
lrwx------    1 root     root            64 Aug  7 11:34 2 -> /dev/null
lrwx------    1 root     root            64 Aug  7 11:34 20 -> socket:[695324]
lrwx------    1 root     root            64 Aug  7 11:34 21 -> /dev/avm_event
lrwx------    1 root     root            64 Aug  7 11:34 22 -> /dev/avm_event
lrwx------    1 root     root            64 Aug  7 11:34 23 -> /dev/avm_event
lrwx------    1 root     root            64 Aug  7 11:34 24 -> socket:[695044]
lrwx------    1 root     root            64 Aug  7 11:34 25 -> socket:[695046]
lrwx------    1 root     root            64 Aug  7 11:34 26 -> /dev/avm_event
lrwx------    1 root     root            64 Aug  7 11:34 27 -> /dev/avm_event
lrwx------    1 root     root            64 Aug  7 11:34 28 -> socket:[695305]
lrwx------    1 root     root            64 Aug  7 11:34 29 -> socket:[695307]
lrwx------    1 root     root            64 Aug  7 11:34 3 -> /dev/watchdog
lrwx------    1 root     root            64 Aug  7 11:34 30 -> socket:[695309]
lrwx------    1 root     root            64 Aug  7 11:34 31 -> socket:[695311]
lrwx------    1 root     root            64 Aug  7 11:34 32 -> socket:[695313]
lrwx------    1 root     root            64 Aug  7 11:34 33 -> socket:[695314]
lrwx------    1 root     root            64 Aug  7 11:34 34 -> socket:[695315]
lrwx------    1 root     root            64 Aug  7 11:34 35 -> socket:[695316]
lrwx------    1 root     root            64 Aug  7 11:34 36 -> socket:[695325]
lrwx------    1 root     root            64 Aug  7 11:34 37 -> socket:[695326]
lrwx------    1 root     root            64 Aug  7 11:34 38 -> socket:[695327]
lrwx------    1 root     root            64 Aug  7 11:34 39 -> socket:[695328]
lrwx------    1 root     root            64 Aug  7 11:34 4 -> socket:[694917]
lrwx------    1 root     root            64 Aug  7 11:34 40 -> socket:[695329]
lrwx------    1 root     root            64 Aug  7 11:34 41 -> socket:[695330]
lrwx------    1 root     root            64 Aug  7 11:34 42 -> socket:[695331]
lrwx------    1 root     root            64 Aug  7 11:34 43 -> socket:[695332]
lrwx------    1 root     root            64 Aug  7 11:34 44 -> socket:[695461]
lrwx------    1 root     root            64 Aug  7 11:34 45 -> socket:[695341]
lrwx------    1 root     root            64 Aug  7 11:34 46 -> socket:[695342]
lrwx------    1 root     root            64 Aug  7 11:34 48 -> socket:[695371]
lrwx------    1 root     root            64 Aug  7 11:34 49 -> socket:[695462]
lrwx------    1 root     root            64 Aug  7 11:34 5 -> socket:[694963]
lrwx------    1 root     root            64 Aug  7 11:34 53 -> socket:[695831]
lrwx------    1 root     root            64 Aug  7 11:34 58 -> socket:[1366264]
lr-x------    1 root     root            64 Aug  7 11:34 6 -> /etc/htmltext_de.db
lrwx------    1 root     root            64 Aug  7 11:34 61 -> /dev/capi20
lrwx------    1 root     root            64 Aug  7 11:34 63 -> /dev/capi20
lrwx------    1 root     root            64 Aug  7 11:34 7 -> socket:[694988]
l-wx------    1 root     root            64 Aug  7 11:34 8 -> /var/log/dsl_ui.txt
lrwx------    1 root     root            64 Aug  7 11:34 9 -> /dev/avm_event
Von einem "regular file" (das REG in Deiner Ausgabe - vermute ich jedenfalls) ist da weit und breit nichts zu sehen ... wenn die Datei über irgendeinen Multiplexer beschrieben werden sollte, müßte der ja in der lsof-Ausgabe zu sehen sein. Ich muß mir wohl mal ein "ordentliches" lsof erstellen ... denn ich kriege auch keine inotify-Events von inotifywait für die .ar7events - also muß da irgendetwas anderes ablaufen. Da ich aber auch keine "modify"- oder "read"-Events erhalte, stellt sich mir die Frage, ob es am inotifywait (samt libinotifytools.so) liegt (das kriege ich mit dem inotifyd der BB heraus, der greift m.W. direkt auf die Kernel-Schnittstelle zu) oder ob da ganz simpel die "watches" zu spät kommen, weil die Files schon offen sind (das kriege ich wiederum über den Restart des ctlmgr nach dem Start von inotifywait heraus). Aber das braucht etwas, ich muß erst einmal etwas anderes machen ...
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 497 (Mitglieder: 5, Gäste: 492)

Neueste Beiträge

Statistik des Forums

Themen
246,347
Beiträge
2,250,583
Mitglieder
374,001
Neuestes Mitglied
curious2315
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück