visu_config_preview.xml fehlt

[NightRacer]

Moinmoin,

irgendwie hab ich mir was zerschossen:

die visu_config_preview.xml ist weg und wenn ich dann den Editor aufrufe kann ich natürlich weder "preview" noch "save" ausführen.
Wie kann ich das wieder richten?


OK: Kommando zurück! Habs wieder grade gebogen.

[Chris M.]

Die visu_config_preview.xml sollte sich selbst neu anlegen. Probleme könnte es höchstens durch mangelnde Datei-Berechtigungen geben.

Wichtig: Wenn man nur den integrierten Editor nutzt, kann diese Datei nicht verloren gehen. D.h. für normale Anwender ist hier nichts zu beachten.

[NightRacer]

Moin,

ist jetzt schon wieder ne weile her.
Also Schuld war ich selbst, habe die Datei aus versehen gelöscht.
Angelegt hat Sie sich aber nicht selbst neu.
Wenn ichs noch richtig weiß hab ich dann eine neue leere visu_config_preview.XML angelegt. Da gabs dann noch ne Fehlermeldung, die kam von der
falschen/fehlenden Berechtigung. Also ich die richtig gesetzt hatte wars dann OK.


mfg

Michael

[NightRacer]

nAbend,

jetzt muss ich mich nochmal an meinen eigenen Thread anhängen.

Ich habe aktuell wieder das Problem mit der visu_config.xml bzw. visu_config_previewtemp.xml

Ich versuche nochmal genau zu beschreiben.

Ausgangslage:

visu_config.xml: vorhanden, valide und funktionsfähig,
visu_config_previewtemp.xml: vorhanden und vom Inhalt her genau gleich wie die visu_config.xml
Gruppe/Eigentümer/Rechte: www-data/www-data/rwxrw-rw- (ist das OK?, da hab ich aber auch schon alle möglichen anderen Kombinationen durch...)


Wenn ich in der cv über den footer den internen Editor aufrufe und entweder

a) den button SAVE drücke (egal ob mit oder ohne vorherige Änderung) kommt configuration was saved wenn ich reloade kommt
config file error und die visu_config.xml ist leer (0KB).

oder

b) den button PREVIEW drücke kommt direkt config file error und die visu_config_previewtemp.xml ist leer (0KB).

Das ganze richte ich dann wieder indem ich aus dem backup ordner ein file rüberziehe und entsprechend umbenenne.

Phänomen tritt auf egal ob ich die config per Windows PC (Firefox) oder Handy/Tablet Browser editieren will.


Meine Konfig: RaspPi 2B, Image von MichiX, cv 0.9.2



Weiß jemand Rat?



Grüße


Michael

[NightRacer]

...keiner eine Idee?

[Chris M.]

Von der Berechtigung sollte ein "-rw-rw-r-- www-data www-data" schon richtig sein - natürlich unter der Annahme, dass der Web-Server auch als User www-data mit der Gruppe www-data läuft.
Auf dem Wiregate ist das der Fall, auf deinem RPi weiß ich das allerdings nicht.

Dass eine 0 kB Datei als fehlerhaft erkannt wird ist verständlich. Die spannende Frage ist, warum die Datei nur 0 kB hat...

[NightRacer]

Von der Berechtigung sollte ein "-rw-rw-r-- www-data www-data" schon richtig sein - natürlich unter der Annahme, dass der Web-Server auch als User www-data mit der Gruppe www-data läuft.
Auf dem Wiregate ist das der Fall, auf deinem RPi weiß ich das allerdings nicht.

Dass eine 0 kB Datei als fehlerhaft erkannt wird ist verständlich. Die spannende Frage ist, warum die Datei nur 0 kB hat...

-Wie finde ich raus unter welcher berechtigung der Webserver läuft?
Ich habe mal geschaut: bei meinen alten installationen (z.B. 0.9.0 oder 0.8.5) lief die visu_config.xml mit [root]
Der Fehler schaut mir doch irgendwie nicht nach falsch gesetzten Rechten bzw. Gruppen aus, da würde er docjh irgend ne meldung bringen und nicht die Datei
zerhauen?

-Wie gesagt, die visu_config.xml verhauts immer genau in dem moment wenn ich im editor SAVE clicke, bzw. die visu_config_previewtemp.xml wenn ich im editor PREVIEW clicke.

Frage zur previewtemp: wie ist denn "normalerweise" der Inhalt der Datei wenn alles passt? Sind die beiden dann Inhaltlich genau gleich?



lg

Michael

[NightRacer]

So,

ich hab mir jetzt (bei dem Regenwetter) mal ne Stunde Zeit genommen und die Gruppen/Eigentümer/Rechte der einzelnen Dateien/Ordner nochmal genau mit den früheren, funktionierenden installationen vergleichen.
Was soll ich sagen es funktioniert tatsächlich wieder. Vorgehensweise war:
aktuelle valide und funktionierende visu_config ist vorhanden, visu_config_previewtemp fehlt.
ich habe eine leere visu_config_preview_temp erstellt.
Einstellungen :
visu_config [root] rw-rw-rw-
visu_config_previewtemp [pi] rw-rw-rw-

ab da konnte ich im editor wieder die buttons prewiev und save benutzen


greetz

Michael

[Chris M.]

Was soll ich sagen es funktioniert tatsächlich wieder.

Sehr schön.

Um den Inhalt in diesem Thread vollständig zu machen:

-Wie finde ich raus unter welcher berechtigung der Webserver läuft?

Mit "ps aux" sieht man alle laufenden Prozesse mit u.a. ihrem Besitzer. Bei mir auf dem WireGate kommt so z.B.:

# ps aux | grep lighttpd
root     10751  0.0  0.3   4128   748 pts/0    S+   17:46   0:00 grep lighttpd
www-data 22016  0.5  1.1   6728  2664 ?        S    06:27   4:03 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf

Die erste Antwort-Zeile kann man ignorieren, das ist ja das grep selbst, in der zweiten Antwort-Zeile sieht man, dass "www-data" der Besitzer des Prozesses ist, der lighttpd ausführt.

Wenn Du nun einen Apache benutzt, dann solltest Du das grep natürlich auch nach apache und nicht nach lighttpd suchen lassen (d.h. "ps aux | grep apache" ausführen)

Der Fehler schaut mir doch irgendwie nicht nach falsch gesetzten Rechten bzw. Gruppen aus, da würde er docjh irgend ne meldung bringen und nicht die Datei
zerhauen?

Eigentlich ja. Warum aber kein Inhalt kommt, wenn er doch was speichern kann, ist mir auch nicht klar.
Wenn ich wüsste, wie ich dieses Fehlverhalten nachstellen kann, könnte ich auch etwas tiefer analysieren.

Frage zur previewtemp: wie ist denn "normalerweise" der Inhalt der Datei wenn alles passt? Sind die beiden dann Inhaltlich genau gleich?

Die previewtemp hat nur einen besonderen Dateinamen, der Inhalt entspricht einer ganz normalen Config-Datei.

[NightRacer]

Hi Chris,

erst mal danke das du dich so kümmerst.
Leider ist das Thema anscheinend noch nicht durch.
Denn wie beim erstem mal als ich das Problem hatte (als ich diesen Thread hier eröffnete)
war das Problem anscheinen behoben (wie jetzt nach meinem letzten Beitrag)
und ist danach aber wieder aufgetreten obwohl sich an den im letzten Beitrag beschriebenen
Rechten und Besitzern nichts geändert hat.
Jetzt gerade eben funktioniert´s wieder!

Ich verzweifle an dem Thema echt noch weil ich so nie dazu komm mal anständig an der visu weiter zu machen.


Zum Thema "ps aux": da kommt dies hier zurück. Was mir nicht klar ist: weshalb läuft das 7x unter [www-data] und noch einmal unter [root]

root@raspberrypi:~# ps aux | grep apache
root      2095  0.2  2.4  78868 23320 ?        Ss   11:47   0:00 /usr/sbin/apache2 -k start
www-data  2478  0.0  0.8  78932  7680 ?        S    11:47   0:00 /usr/sbin/apache2 -k start
www-data  2479  0.0  0.8  78932  7680 ?        S    11:47   0:00 /usr/sbin/apache2 -k start
www-data  2480  0.0  0.7  78892  6720 ?        S    11:47   0:00 /usr/sbin/apache2 -k start
www-data  2481  0.0  0.7  78892  6720 ?        S    11:47   0:00 /usr/sbin/apache2 -k start
www-data  2483  0.0  0.7  78892  6720 ?        S    11:47   0:00 /usr/sbin/apache2 -k start
www-data  2860  0.0  0.7  78892  6720 ?        S    11:47   0:00 /usr/sbin/apache2 -k start
www-data  2979  0.0  0.7  78892  6720 ?        S    11:48   0:00 /usr/sbin/apache2 -k start
root      2999  0.0  0.1   3608  1696 pts/0    S+   11:49   0:00 grep apache

Wenn ich wüsste, wie ich dieses Fehlverhalten nachstellen kann, könnte ich auch etwas tiefer analysieren.

Genau das ist auch mein Problem das ich nicht erkennen kann wie, wann oder weshalb der Fehler zustande kommt.

Gibt's da noch irgendwelche log Dateien die man sich anschauen könnte?

chris : wenn du lust hättest könnte man sich das auch gerne mal per teamviewer anschauen...aber grade funtionierts ja



Grüße

Michael

[Chris M.]

Zum Thema "ps aux": da kommt dies hier zurück. Was mir nicht klar ist: weshalb läuft das 7x unter [www-data] und noch einmal unter [root]

Auf einem Rechner auf dem Apache läuft habe ich mal gegengecheckt, da ist das genau so. Ich schätze, dass der als root laufende Prozess einfach nur der Meister ist, der die anderen Slaves startet und ggf. beendet.

Genau das ist auch mein Problem das ich nicht erkennen kann wie, wann oder weshalb der Fehler zustande kommt.

Gibt's da noch irgendwelche log Dateien die man sich anschauen könnte?

chris : wenn du lust hättest könnte man sich das auch gerne mal per teamviewer anschauen...aber grade funtionierts ja

Log Dateien dürften (erst mal) nicht wirklich weiterhelfen. Auch der teamviewer.
Was wir jetzt brauchen ist eine Vorgehensweise, die zu dem Fehlerbild führt und ggf. wie man wieder raus kommt.
Im nächsten Schritt müsste man diese Schritte dann so vereinfachen, dass nur noch die wirklichen relevanten Aktionen übrig bleiben.

Dann entscheidet sich ob direktes Nachstellen geht, Log-Dateien helfen oder es ein teamviewer sein muss.

(Als Zwischenlösung zum Arbeiten sollte es ja ausreichen in der Shell einfach passende Rechte drüber zu bügeln)

[Michixx]

Genau das ist auch mein Problem das ich nicht erkennen kann wie, wann oder weshalb der Fehler zustande kommt.

Ich vermute dass diene Speicherkarte eine Macke hat.
Ersetze die mal zum Test gegen eine neue und berichte dann mal.

Gruß
Michael