debug.cfg verschwindet

Bejobe

Neuer User
Mitglied seit
19 Mai 2005
Beiträge
163
Punkte für Reaktionen
0
Punkte
0
In meiner Fritzbox 7270 FRITZ!OS 06.04-27861 BETA (also neueste Beta) ist vor einiger Zeit (etwa Anfang April, also vor dieser letzten Beta) offenbar die debug.cfg gelöscht worden. Wodurch, weiss ich nicht.

Wenn ich die debug.cfg jetzt neu erstelle mit vi und cat dann ist sie vorhanden. Auch der Inhalt stimmt.

Aber beim nächsten Neustart der Box wird die debug.cfg wieder gelöscht und zwar offenbar bevor sie ausgeführt wird.

Ist das ein bekanntes Problem? Woran liegt's?

mit ls -l ergibt sich für die mit "cat /var/xxx/meinedatei > /var/flash/debug.cfg" "kopierte" debug.cfg:

Code:
-rw-r--r--    1 root     root           638 Apr 23 18:17 debug.cfg
crw-r--r--    1 root     root      249, 177 Jan  1  1970 dect_eeprom
crw-r--r--    1 root     root      249, 176 Jan  1  1970 dect_misc
Es fehlt das "c" und die "249,".

Bejobe
 
Zuletzt bearbeitet:
Danke für die prompten Antworten mit den richtigen Informationen.

Wenn die Möglichkeiten der Debug.cfg von Avm herausgenommen werden in neuen Firmwareversionen nicht nur der 7270 sondern auch der 7390 und der 7490 (beide hier auch im Einsatz), dann werde ich in der Zukunft andere Router von anderen Herstellern suchen müssen.

Die Möglichkeiten durch die debug.cfg sind ein wichtiges Argument für die Router von AVM. Das ist ein unverzichtbares Feature.

Hier noch einmal der schockierende Beitrag aus den weiter oben genannten Thread "FRITZ!Box 7270 v2/v3 Beta-Firmware 54/74.06.04-27861 vom 11.04.2014":

Beitrag #22: http://www.ip-phone-forum.de/showthread.php?t=269276&page=2&p=2002789&viewfull=1#post2002789 von "chked"

Ich bin jetzt wieder zurück zur 27674, debug.cfg ist wieder vorhanden, sogar der ursprüngliche Inhalt war noch da.
Anschließend habe ich die init.d Scripte der 27674 und der 27861 verglichen. Alles identisch bis auf die rc.tail.sh. Dort fehlt der folgende Abschnitt:
Code:
mknod /var/flash/debug.cfg c $tffs_major $((0x62))
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then
. /var/flash/debug.cfg
fi
Also bye bye debug.cfg ...
Ich bin enttäuscht von AVM.
 
Zuletzt bearbeitet:
Hallo,

nichts wird so heiß gegessen wie es gekocht wird. AVM hat die debug.cfg entfernt. Das bedeutet aber nicht, dass man sie nicht durch eine Modifikation (im Tread war von Freetz die rede) wieder bekommen könnte. Ich zumindest bin sehr zuversichtlich, dass die hier aktiven User eine Lösung für das Problem finden werden. Dazu kommt das es sich um eine Beta handelt und nichtmal sicher ist, ob es in der Final genauso ist. Deshalb einfach abwarten und tee trinken oder einen Patch programmieren.

LG Joe
 
nichts wird so heiß gegessen wie es gekocht wird.
Hoffentlich. Aber ich fürchte, dass das in diesem Fall leider nicht stimmt.


AVM hat die debug.cfg entfernt. Das bedeutet aber nicht, dass man sie nicht durch eine Modifikation (im Tread war von Freetz die rede) wieder bekommen könnte.
Fakt ist wohl, dass die debug.cfg weg soll. Freetz habe ich noch nie benutzt und werde es nicht benutzen. Ich bin immer mit "Bordmittel" von Avm ausgekommen und will das nicht ändern.

Ich würde sogar sagen, dass es sich bei der debug.cfg um eine zugesicherte Eigenschaft der Boxen 7270, 7390 und 7490 handelt.

Ich habe mir jedenfalls gerade die aktuellen FW-Versionen (und die Recovery-Versionen) heruntergeladen und gesichert....

Die Gruppe der Debug.cfg-Nutzer ist doch relativ klein und weiss in der Regel, was sie tut. Es sind diese Leute alle Multiplikatoren, auf deren Meinung viele andere mit Ihren Entscheidungen hören. Verärgere und enttäusche diese Leute bitte nicht, Avm.

Bejobe
 
Zuletzt bearbeitet:
Hatte den Vorschlag Anfang Mai schon an anderer Stelle gelesen, statt der nicht mehr verfügbaren debug.cfg die calllog zu verwenden, die bei jedem eingehenden Anruf aufgerufen wird. Heute bin ich dazu gekommen, das zu testen - geht prima.
So ist die Einrichtung der Datei calllog in der Telnet-Sitzung vorzunehmen:
echo "blabla" > /var/flash/calllog # initiale Bereitstellung der calllog auf der FRITZ!Box (FB)
nvi /var/flash/calllog


Im nvi dann ungefähr diesen Inhalt für calllog einfügen:
ps > /var/tmp/ps.dmp
cat /var/tmp/ps.dmp | if (! grep -q TEILSTRING_PROZESSNAME) then (/VOLLERPFAD/SHELLDATEI) fi

(für vi bzw. nvi Dummies: Nach Aufruf des nvi zunächst zweimal Taste d drücken (um die Zeile mit blabla zu löschen), Taste i (=insert) drücken, dann den vorbereiteten Inhalt für die calllog mit STRG Einfg einfügen, dann nacheinander die Tasten ESC : w q drücken. {das war jetzt die vi-Bedienung im Kern auf zwei Zeilen :D })
Oben ist einzusetzen:
TEILSTRING_PROZESSNAME : das, was man mit dem Befehl ps von dem Programm sieht, was immer in der FB laufen soll,
in meinem Fall der thttpd
/VOLLERPFAD/SHELLDATEI : In der Regel /var/media/ftp/USBSTICKNAME-01/Name_der_Shelldatei
in meinem Fall startthttpd.sh
Die Funktionsweise der calllog:
Es wird ein Dump der Prozessauflistung (ps) in ps.dmp zwischengespeichert (dieser Zwischenschrift IST NOTWENDIG, sonst grept sich das grep selbst als laufenden Prozess), dann wird ps.dmp daraufhin untersucht, ob TEILSTRING_PROZESSNAME nicht (!) darin enthalten ist. Trifft dies zu, muss die gewünschte Shelldatei aufgerufen werden, andernfalls läuft der gewünschte Prozess schon.
Nun wird natürlich die calllog nicht automatisch nach dem Hochfahren der Fritz!Box aufgerufen, aber bei JEDEM Anruf. Will man also seinen Prozess gestartet haben, ruft man einfach einmal seine FB bzw. Telefonnummer an, und schon geht's los. Bei folgenden Anrufen wird der gewünschte Prozess aber nicht erneut gestartet.
Gerade vor zehn Minuten mit einem Reboot meiner FB getestet, alles paletti!
Have fun without debug.cfg !
SEB
 
ps > /var/tmp/ps.dmp
cat /var/tmp/ps.dmp | if (! grep -q TEILSTRING_PROZESSNAME) then (/VOLLERPFAD/SHELLDATEI) fi
Nach derzeitigem Kenntnisstand baut AVM auch das Abarbeiten von /var/calllog aus neuerer Firmware aus.

dieser Zwischenschrift IST NOTWENDIG, sonst grept sich das grep selbst als laufenden Prozess
Einfacher ist:
Code:
ps w | grep -q starthttpd || starthttpd
... kommt ohne temporäre Datei aus (wenn man die Pipe nicht dazu rechnet, je nach Standpunkt) und funktioniert auch. :)

Deine Variante, mit 'cat' nach 'if' zu pipen, ist auch eher ungewöhnlich und funktioniert - mehr oder weniger - nur zufällig, weil 'if' 'stdin' nicht anfaßt und so erst 'grep' aus der Pipe liest. Besser wäre sicherlich:
Code:
if (! grep -q TEILSTRING_PROZESSNAME /var/tmp/ps.dmp) then (/VOLLERPFAD/SHELLDATEI) fi
 
Nach derzeitigem Kenntnisstand baut AVM auch das Abarbeiten von /var/calllog aus neuerer Firmware aus.
Das wäre nicht schön. Dann bleibe ich erst einmal bei diesem FRITZ!OS 06.04-27949 BETA (auf 7270v2) stehen, bis eine neue Lösung zum Starten eines eigenen Scripts verfügbar ist (abgesehen von Freetzen der FW).
Eins muss ich nämlich dieser BETA-Version zu Gute halten: Im Gegensatz zu der Beta-Version davor (ca. Anfang April 2014) und ihren Vorgängern läuft meine 7270 mit ihr dank des verbesserten Speichermanagements um Welten stabiler.

Einfacher ist:
Code:
ps w | grep -q starthttpd || starthttpd
... kommt ohne temporäre Datei aus (wenn man die Pipe nicht dazu rechnet, je nach Standpunkt) und funktioniert auch. :)
Wenn's nicht um die Auswertung von ps gehen würde, perfekt. Leider in diesem konkreten Fall nicht, weil, wie ich schon schrieb, der grep-Prozess mit dem Suchstring als Parameter im ps als Ergebnis immer drin ist - schlecht. Da hilft nur Ablegen des Suchstrings in einer Datei und dann Nutzung von grep mit -f.

Daher darf ich, basierend auf PeterPawns gutem Vorschlag, diese ebenfalls getestete Version als /var/flash/calllog empfehlen (anstelle meiner Lösung vom 18.5.):
Code:
ps | grep -q -f /var/media/NEW_LINK/thtpat || /var/media/NEW_LINK/startthttpd.sh

Dabei bitte den Suchstring (z. B. "thttpd") in eine neue Datei (hier thtpat genannt) auf dem Stick abspeichern (ohne Zeilenumbruch am Ende).

Übrigens: seit 18.5. fiel mir noch auf, dass der Pfad auf's Wurzelverzeichnis des USB-Sticks auch unter /var/media/NEW_LINK nutzbar ist anstelle von /var/media/ftp/USBSTICKNAME-01 .

Allen "debug.cfg-Amputierten" viel Erfolg!
 
Wenn's nicht um die Auswertung von ps gehen würde, perfekt. Leider in diesem konkreten Fall nicht, weil, wie ich schon schrieb, der grep-Prozess mit dem Suchstring als Parameter im ps als Ergebnis immer drin ist - schlecht. Da hilft nur Ablegen des Suchstrings in einer Datei und dann Nutzung von grep mit -f.
Das ist ein wenig ein Timing-Problem der Shell bzw. liegt bei Dir wahrscheinlich an der letzten Endes verwendeten Syntax.

Solange Du ein Shell-Kommando (oder auch eine Folge von Kommandos) ohne Not in runde Klammern einschließt - was in "echten" Programmiersprachen manchmal sogar guter Stil ist -, wird der gesamte Klammerinhalt in einer Subshell - also asynchron zum Rest des Scripts - abgearbeitet. Das ist manchmal wünschenswert, manchmal aber auch nicht.

Wenn man zum Beispiel innerhalb einer solchen Klammerung einer Shell-Variablen einen Wert zuweist, kann man auf diesen Wert von außerhalb (also quasi aus dem "Hauptprozess") trotzdem nicht zugreifen, da für die Subshell ein getrennter Variablensatz (Stichworte zum Nachschlagen: global scope, local scope) geführt wird. Die einzige Möglichkeit der "direkten" Kommunikation mit einer Subshell besteht in der Nutzung der std-Files (stdin, stderr, stdout) und dem Exit-Code, der bei Deinem ersten Posting aus dem negierten Exit-Code des 'grep -q' bestand.

Original 7390-Labor 29782 mit /bin/sh aus der busybox:
Code:
# ps w | grep ctlmgr
 7434 root     15516 S    ctlmgr -m -v
 7556 root      1304 S    tail -f /var/tmp/ctlmgrmsg.log
# ps | grep ctlmgr
 7434 root     15516 S    ctlmgr -m -v
 7556 root      1304 S    tail -f /var/tmp/ctlmgrmsg.log
# ps l | grep ctlmgr
S     0  7434     1 15516  7280 0:0   23:51 00:01:43 ctlmgr -m -v
S     0  7556  6070  1304   292 pts0  23:52 00:00:03 tail -f /var/tmp/ctlmgrmsg.log
Bei 'grep -q' ist das schlechter zu sehen ... aber selbst wenn der 'grep'-Prozess auch in der Ausgabe auftauchen sollte, ist ein
Code:
ps w | grep -v grep | grep -q 'was suche ich' || starte_irgendwas
immer noch die "lesbarere" Variante, weil man nicht erst in der bei 'grep -f' angegebenen Datei nachsehen muß, was da eigentlich gesucht wird.

der Pfad auf's Wurzelverzeichnis des USB-Sticks auch unter /var/media/NEW_LINK nutzbar ist anstelle von /var/media/ftp/USBSTICKNAME-01
Solange bloss ein USB-Datenträger vorhanden ist, klappt das. Wenn aber (bei der 7270 über einen Hub, neuere Boxen haben auch gerne mal 2 USB-Anschlüsse) ein weiterer Datenträger vorhanden ist, sollte NEW_LINK auf das zuletzt gemountete Volume verweisen. Das gilt natürlich ebenso bei einem einzelnen Datenträger mit mehreren Partitionen.
 
Zuletzt bearbeitet:
Tagchen

Oder,
Code:
ps | grep -E [c][t][l][m][g][r] ; echo $?
...es wird gleich ein regulärer Ausdruck genommen.
:rolleyes:

Der Pfad /var/media/NEW_LINK, perfekt, wie geschrieben, wenn nur 1 USB-Speicher/Gerät genutzt wird.
Mehrere machens komplizierter und erfordern meist absolute Pfadnamen.
Trotzdem, perfekt bei nur einen und so nutz ich dass auch. ;)
 
Zuletzt bearbeitet:
Das ist ein wenig ein Timing-Problem der Shell bzw. liegt bei Dir wahrscheinlich an der letzten Endes verwendeten Syntax.
Das ist kein Timing-Problem der Shell, sondern Verhalten, das von der Geschwindigkeit und Auslastung des Systems abhängt. Und daher stellt sich die Frage, ob man etwas schreibt, was manchmal funktioniert, oder lieber etwas, was immer funktioniert. Eine Pipe besteht aus Prozessen, die potentiell parallel ausgeführt werden können. Sich darauf zu verlassen, dass der ps Prozess beendet ist, bevor der grep Prozess gestartet wird, ist nicht sicher. Vielleicht funktioniert es bei Dir "immer", also in den Fällen, wo Du es getestet hast. Was ist aber, wenn es 10 (oder 1000) Prozesse mehr gibt, oder die Systemauslastung höher ist?

Oder,
Code:
ps|grep -E [c][t][l][m][g][r];echo $?
...es wird gleich ein regulärer Ausdruck genommen.
Das ist etwas übertrieben, und gleichzeitig auch problematisch, weil die Shell das als Suchmuster interpretiert.
Normalerweise schreibt man es so:
Code:
ps w | grep '[c]tlmgr'
Wenn man einen eindeutigen Namen des Programms hat, kann man auch pidof nutzen, dann hat man das Problem mit grep nicht mehr.
 
Das ist kein Timing-Problem der Shell, sondern Verhalten, das von der Geschwindigkeit und Auslastung des Systems abhängt.
Da hast Du vollkommen recht und ich hatte auch bemerkt, daß der Text nicht das zum Ausdruck brachte, was ich eigentlich zeigen wollte.

Leider ist das, was ich wirklich freigeben wollte (den Teil mit 'grep -v' von Anfang an deutlich herausgestellt und auch weitere Beispiele - mit und ohne Subshell -, wo grep mal vorhanden war und mal nicht, wenn man nicht den "negative match" Zwischenschritt geht und dass es mit meiner ersten Variante nicht deterministisch ist) wieder mal einem 404-Error zum Opfer gefallen.

Insofern ... Asche auf mein Haupt. Das Posting war so definitiv falsch.

OT: Habe ich eigentlich als einziger das Problem, daß es Server-Fehler bei fast jedem Roundtrip hagelt, sobald ich angemeldet bin ? Man versucht zwischendrin mal kurz auf "Vorschau" zu drücken und schon sind die Änderungen seit der letzten Vorschau dahin, wenn man wieder mal vergessen hat, das vorher per C&P zu sichern. Dann zurück im Browser (um den Text vielleicht doch noch zu retten) und wieder vor und es kommt Mist dabei heraus. Ich habe das Problem mit ständigen Fehlern ziemlich gut reproduzierbar auf 3 verschiedenen Windows-Maschinen (7/8/8.1) und einem Mac (10.9) mit IE (10,11), FF (ich würde sagen mindestens seit 24.0) und auf dem Mac auch mit Safari. Da auch überall unterschiedliche Add-Ons installiert sind, die sich in die Konversation mit dem Server potentiell einmischen könnten, glaube ich irgendwie nicht so recht an ein client-seitiges Problem und sehe mit den Developer-Tools der Browser auch nichts auffälliges in der Netzwerkkommunikation. Und Serverantworten wie der pure Text "Error - please try again." ohne alle HTML-Schnörkel drum herum, sollten ja wohl nicht vorkommen, oder ? Wenn nicht nachts um 4 genauso viele Leute auf dem Server unterwegs sind wie am späten Nachmittag, ist es auch nicht von der Auslastung abhängig.

Normalerweise schreibt man es so:
Wie wäre es denn mit: "Viele schreiben das so:" ? :)

Auch wenn der Aufruf von koyaanisqatsi ohne 'single quotes' um das Pattern natürlich seinen eigentlichen Zweck verfehlen würde, wenn ein File ctlmgr im aktuellen Verzeichnis liegt.

Ob dann am Schluß im grep der Overhead des Pattern-Matching für "character classes" mit nur einem Zeichen (wird das vielleicht sogar wegoptimiert ?) oder der Overhead des zusätzlichen Aufrufs von 'grep -v' (das ja leider zuerst auf die größere Datenmenge losgelassen werden muß, wenn man - wie hier - den Exit-Code des 'grep -q' auswerten will) größer wäre, kann ich nicht beurteilen.

Wenn man einen eindeutigen Namen des Programms hat, kann man auch pidof nutzen, dann hat man das Problem mit grep nicht mehr.
*Darüber* könnten wir ja mal diskutieren ... was ist eigentlich ein "Programm" ? :cool:

Leider funktioniert das mit dem pidof gerade für Scripte, die sicherlich am häufigsten der Gegenstand des "FritzBox-Moddings" sind, i.d.R. nicht und wenn man dann im Script ein Trap z.B. für USR1 aufgesetzt hat, das man mit kill auslösen will, funktioniert ohne korrekte pid einfach nichts (killall klappt nicht). Da bleibt dann nichts weiter, als die Liste in /proc selbst abzugrasen, anders macht das 'ps' im Prinzip auch nicht.

Wenn man es nicht ganz so ernst nehmen will, ist ja auch die Konstruktion (mit oder ohne '.*' vor $lookfor im grep, je nachdem, was man sucht)
Code:
lookfor="ctlmgr"; for p in /proc/[0-9]*; do grep -q "^Name:[[:space:]]$lookfor" <$p/status 2>/dev/null && echo "i hoab di, pid=${p#/proc/}" && break; done
als Ersatz für 'pidof' oder 'ps | grep' denkbar (zumindest wenn man die nötigen Rechte hat).

Und auch da kann man über den Unterschied zwischen "/proc/[0-9]?*" und "/proc/[0-9]*" oder auch "/proc/[0-9]*" vs. "/proc/[0-9]*/task/*" (ein Prozess vs. mehrere Threads) noch wunderbar streiten. :)

Wobei das oben stehende prinzipiell (allerdings auch ohne das abgewandelte echo) von mir in Boxen tatsächlich ab und an so eingesetzt wird, um die pid von "Dauer-Scripten" zu ermitteln. Da pidof nicht funktioniert und das Ausgabeformat von ps gerne mal variiert, so dass man mit cut/sed schnell mal daneben liegen kann, ist das bisher bei Scripten für mich der "kompatibelste" Weg an die pid zu kommen und nicht nur die generelle Existenz eines Prozesses zu testen.
 
Habe ich eigentlich als einziger das Problem, daß es Server-Fehler bei fast jedem Roundtrip hagelt, sobald ich angemeldet bin?
Mir ist in letzter Zeit nichts derartiges aufgefallen.
Wie wäre es denn mit: "Viele schreiben das so:" ? :)
So kann man es auch schreiben. Das würde ich von der Bedeutung sehr ähnlich sehen.
Auch wenn der Aufruf von koyaanisqatsi ohne 'single quotes' um das Pattern natürlich seinen eigentlichen Zweck verfehlen würde, wenn ein File ctlmgr im aktuellen Verzeichnis liegt.
Genau das. Ein weiterer Nachteil ist, dass das aktuelle Verzeichnis unnötigerweise gelesen wird, auch wenn sich nachher herausstellt, dass die Datei nicht vorhanden ist.
Ob dann am Schluß im grep der Overhead des Pattern-Matching für "character classes" mit nur einem Zeichen (wird das vielleicht sogar wegoptimiert ?) oder der Overhead des zusätzlichen Aufrufs von 'grep -v' (das ja leider zuerst auf die größere Datenmenge losgelassen werden muß, wenn man - wie hier - den Exit-Code des 'grep -q' auswerten will) größer wäre, kann ich nicht beurteilen.
Ich bin sicher, dass der Overhead für das Pattern-Matching kleiner ist, als einen neuen Prozess zu starten, die benötigten Libraries zu laden und zu linken.

Der effizienteste Weg um die PID eines selbst geschriebenen Skripts herauszufinden ist, die PID beim Start in eine Datei zu schreiben und nachher aus dieser Datei zu lesen. Ggf. kann man noch prüfen, ob unter dieser PID auch der richtige Prozess läuft, man muss dafür aber nicht alle Prozesse durchsuchen.
 
Mir ist in letzter Zeit nichts derartiges aufgefallen.
Immer noch OT, ich weiß bloss nicht, wohin damit ...

Heißt das, es gab früher mal Probleme, die in etwa so lagen, wie meine Schilderung es beschreibt ?
Das Konto ist (wie man sehen kann) schon sehr alt, früher habe ich aber nichts geschrieben und da fiel es mir nicht auf.

Gab es da mal bekannte Fehler ? Wenn ja, wie wurden die behoben ? Ich kann nicht einmal die Suchfunktion sinnvoll nutzen, da *jeder* Versuch mit "Error - please ..." oder 404 auf dem Server endet (da kriege ich dann noch die Info, daß die PHP-Seite für eine erweiterte 404-Beschreibung nicht vorhanden ist) ... bei der Suche ist es offenbar sogar egal, ob ich angemeldet bin oder nicht (also mit Keks oder ohne oder auch mit Dauerkeks).

Um auszuschließen, daß es am Useraccount (im IPPF) liegt, würde ich gerne mal jemandem per PM ein Kennwort zukommen lassen, damit er/sie sich an meiner Stelle einmal einloggen kann. Hinterher ändere ich dann selbstverständlich das Kennwort. :) Freiwillige vor ...

Ich bin sicher, dass der Overhead für das Pattern-Matching kleiner ist, als einen neuen Prozess zu starten, die benötigten Libraries zu laden und zu linken.
Solange wir das nicht ausmessen und zwar an einer sehr großen Zahl von Aufrufen, damit es evident wird, bleibt es wohl akademisch. ;)

Der Aufwand für ein 'fgrep' (und darauf wird es - vermute ich aber auch nur, weil ich es selbst so machen würde - verkürzt, wenn keine Permutationen möglich sind) dürfte wesentlich geringer sein (im Extremfall in C nur ein strstr pro Zeile, was je nach Prozessorarchitektur ggf. auch bis auf Maschinencode-Ebene ohne Loops o.ä. funktioniert), als der für die state machine eines regex-Matching.

Und geladen und dynamisch gelinkt sollten die Libs untereinander ja eigentlich schon sein (sofern sie geshared werden können, reicht dann das Mapping in den Speicher des neuen Prozesses), nur die Auflösung der Referenzen auf die Library-Funktionen (also das dynamische Linken gegen die Libs) müßte der Loader noch machen, wenn nicht sogar der Code des 'grep' zwischen den beiden Instanzen geshared werden kann.

Da das in unserem Falle normalerweise alles Busybox-Applets sind, müßte nach meinem Verständnis sogar mit jedem beliebigen anderen Applet geshared werden (also die ganze Busybox insgesamt nur einmal geladen und gelinkt werden). Der Rest sollte dann nur anhand der cmdline entschieden werden.

Allerdings ist das Erstellen des Prozesses sicherlich wirklich nicht zu verachten, besonders auch wenn es zu zusätzlichen Kontextwechseln kommt, weil beim Schreiben in die Pipe gewartet werden muß, bis das 'grep -q' am anderen Ende die Buffer leert. Wenn man es wirklich mal messen will, müßte man wohl auch noch unterschiedlich große Prozesslisten testen.

Der effizienteste Weg um die PID eines selbst geschriebenen Skripts herauszufinden ist, die PID beim Start in eine Datei zu schreiben und nachher aus dieser Datei zu lesen. Ggf. kann man noch prüfen, ob unter dieser PID auch der richtige Prozess läuft, man muss dafür aber nicht alle Prozesse durchsuchen.
Das klappt - bei mir - leider auch nicht immer bzw. es wäre bei mehreren Instanzen zusätzlicher Aufwand zu treiben, um einen entsprechenden Parameter zu übergeben. Das macht gerade dann in meinen Augen keinen Sinn macht, wenn das Script ansonsten eigentlich parameterlos arbeitet und man die ganze Behandlung erst noch einbauen müßte.
Und ob man die Liste durchläuft (als Script ohnehin bei mir fix und fertig vorhanden und ohne Rücksicht auf die Unterschiede zwischen Binaries und Shell-Scripten benutzbar) oder zusätzliche Tests für "orphaned pid files" einbaut, hängt sicherlich auch von der zusätzlichen 'utilization' durch das Durchlaufen der Prozessliste ab, wobei ja auch die Häufigkeit dieses Vorgangs eine Rolle spielt.
Von der fehlenden *realistischen* Möglichkeit, Scripte im SquashFS einfach um das Speichern eines PID-Files zu erweitern, mal ganz abgesehen ...
 
Heißt das, es gab früher mal Probleme, die in etwa so lagen, wie meine Schilderung es beschreibt ?
Das Konto ist (wie man sehen kann) schon sehr alt, früher habe ich aber nichts geschrieben und da fiel es mir nicht auf.
Es gab immer wieder mal Probleme. Meistens gab es dann auch Threads über Forum langsam, nicht erreichbar und ähnliches. Es betraf also nicht nur einzelne und war nicht wirklich das, was Du beschrieben hast. Meistens war wohl das Forum überlastet, oder Hardware defekt, oder was auch immer.
Um auszuschließen, daß es am Useraccount (im IPPF) liegt, würde ich gerne mal jemandem per PM ein Kennwort zukommen lassen, damit er/sie sich an meiner Stelle einmal einloggen kann. Hinterher ändere ich dann selbstverständlich das Kennwort. :) Freiwillige vor ...
Das können wir ausprobieren, aber Du schreibst ja selbst, dass es auch ohne Anmeldung passiert.


Solange wir das nicht ausmessen und zwar an einer sehr großen Zahl von Aufrufen, damit es evident wird, bleibt es wohl akademisch. ;)

Der Aufwand für ein 'fgrep' (und darauf wird es - vermute ich aber auch nur, weil ich es selbst so machen würde - verkürzt, wenn keine Permutationen möglich sind) dürfte wesentlich geringer sein (im Extremfall in C nur ein strstr pro Zeile, was je nach Prozessorarchitektur ggf. auch bis auf Maschinencode-Ebene ohne Loops o.ä. funktioniert), als der für die state machine eines regex-Matching.
Es gibt auch für regexp effiziente Implementierungen.

Und geladen und dynamisch gelinkt sollten die Libs untereinander ja eigentlich schon sein (sofern sie geshared werden können, reicht dann das Mapping in den Speicher des neuen Prozesses), nur die Auflösung der Referenzen auf die Library-Funktionen (also das dynamische Linken gegen die Libs) müßte der Loader noch machen, wenn nicht sogar der Code des 'grep' zwischen den beiden Instanzen geshared werden kann.
Die Libraries müssen zunächst gesucht werden, die Dateien geöffnet und die Segmente gemappt werden. Die Text Segmente sind wohl schon im Speicher, so dass sie nicht von Platte nachgeladen werden müssen, aber trotzdem kommt es beim Ersten Zugriff auf eine Seite zu einem Seitenfehler und die Seite wird dann in den Adressraum eingebunden. Die Datensegmente kann man nicht von einem anderen Prozess nehmen, die müssen aus der Datei nachgeladen werden. Auch wenn die Inhalte schon im Cache sind, müssen sie von dort in den Adressraum des Prozesses. Sobald der erste Schreibzugriff auf eine Seite stattfindet, muss die Seite kopiert werden. Das linken zwischen Programm und Libraries wird jedes Mal neu durchgeführt, auch wenn das gleiche Programm schon mit den gleichen Libraries läuft. Ansonsten müsste man erst einmal einen Prozess finden, in dem das gleiche Programm läuft (im Prinzip das gleiche Problem, um das es hier schon ging, einen Prozess finden, der ein bestimmtes Programm ausführt). Dann müsste man aus diesem Prozess den Speicher auslesen und auch noch hoffen, dass dort nichts (beabsichtigt oder unbeabsichtigt) verändert wurde, was zu Problemen führen kann. Statt dessen werden also bei jedem Start die dynamischen Reloc Informationen von Programm und Libraries abgearbeitet. Referenzen auf Variablen werden vor dem Start aufgelöst, Funktionsaufrufe beim ersten Aufruf.

Letztlich funktioniert das aber trotzdem schnell, vermutlich wird man den Unterschied kaum messen können.
 
Moin, ich hab seit einigen Tagen eine 7490. Vorher hatte ich eine 7270 auf der der apache auch wunderbar lief. Ich hab jetzt schon gelesen das die debug.cfg immer weg sein soll. Ich hatte in meiner debug jetzt alles zum aufruf nötige reingeschrieben und nach einem neustart ist auch alles noch vorhanden. leider bekomm ich den apache anscheinend irgendwie nicht zum laufen das virtuelle interface wird mit ifconfig eth0:1 192.168.1.130 netmask 255.255.255.0 up erstellt und funktioniert auch. Aner irgendwie will der apache nicht wirklich. Ich bin da jetzt nicht so der Linux freak aber kann mir mal jemand sagen wie ich im Telnet sehen kann ob der apache gestartet wurde? Also mein kompletter aufruf sieht so aus.

while !(ping -c 1 www.google.de); do
sleep 5
done
ifconfig eth0:1 192.168.1.130 netmask 255.255.255.0 up
/var/media/ftp/SanDisk-CruzerMicro-01/apache/bin/apache -f /var/media/ftp/SanDisk-CruzerMicro-01/apache/conf/apache.conf
 
Ja, ich denke den richtigen zu haben **apache-1.3.42_php-5.5.6_mips** aber in meiner Liste sind nur root einträge. Auch wenn ich den apache direkt mit /var/media/ftp/SanDisk-CruzerMicro-01/apache/bin/apache -f /var/media/ftp/SanDisk-CruzerMicro-01/apache/conf/apache.conf starte rödelt er kurz und springt dann ohne fehler auf # aber in der prozessliste taucht nix dergleichen auf ..... hmmm komisch
 
Ha so jetzt läufts .... Ich hab mir noch mal die Version hier runtergeladen **apache-2.2.17_php-5.4.3_mips_static** und damit läufts :-D .... Und komischerweise im positiven natürlich auch nach einem neustart meine debug.cfg bleibt erhalten.
 
Seit der 6.03 existiert ein 600er loop, weis' nicht wofür der gut ist, lässt aber den apache erst 10min. nach einem reboot starten.
Du meinst aber nicht das 600s-Sleep vor dem Ausführen von /bin/modulemem ?

Falls doch:
1. Das Script zählt (etwas merkwürdig, ohne Modifikationen der Box aber zuverlässig) 10 Minuten nach dem Start der Box (eigentlich nach rc.tail.sh) den Hauptspeicherbedarf aller dynamisch geladenen Module zusammen und schreibt diesen Wert als Dezimalzahl unter dem Tag "modulemem" in das Urlader-Environment.
2. Dadurch sollte der Start des apache *nicht* beeinflusst werden. Die Kommandokette läuft im Hintergrund ab und hält keine anderen Abläufe auf. Alles andere, was da auf /dev/console geschrieben wird (vor den Start des 'sleep' und vor dem Start von '/bin/modulemem'), ist nur Beiwerk. Wenn dadurch der Start des apache verzögert werden sollte, läuft etwas schief.

Falls nicht:
Wo wird der gestartet ? Hast Du mal eine Anzeige der Prozessliste mit diesem "Loop" ?
 
So, ich hab das jetzt noch einmal getestet. Also die **apache-1.3.42_php-5.5.6_mips** will einfach nicht starten, es kommen aber auch keine Fehlermeldungen. Wenn ich das gleiche mit der **apache-2.2.17_php-5.4.3_mips_static** oder auch mit der **apache-1.3.41_php-5.4.3_mips_disable-shared**mache klappts auf anhieb.
 
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.