Offline-Wiki: Problem bei automatischer Installation
Camping_RIDER
- offline-wiki
0 dedlfix
Aloha ;)
Habe eben mal versucht, unser Offline-Wiki zu installieren. Dabei gibt es ein Problem mit VC-Redist:
In Folge (vermutlich deshalb?) kann dann auch der Server nicht richtig gestartet werden. Es ergeht zwar keine Fehlermeldung, der Aufruf des Servers unter localhost:8000
führt aber ins Leere.
Insgesamt ist mir im Installationsprozess noch aufgefallen, dass es ein paar Stellen gibt, an denen die setup.cmd
sehr lange braucht, ohne, dass dabei angezeigt wird, dass gerade etwas passiert. Besonders extrem ist das vor der Installation von VC-redist; vor allem, da die dortige Erfolgsmeldung für das Entpacken der lokal vorgehaltenen Dateien den Anschein erweckt, die Installation sei schon vollkommen fertig. Das hat dazu geführt, dass ich im ersten Installationsversuch erstmal das CMD-Fenster an der Stelle geschlossen hatte, in dem Gefühl, alles sei erledigt.[1] Vielleicht hilft es, hier ein "Bitte warten Sie..." einzufügen.
Grüße,
RIDER
Klar, das war eine Fehlbedienung - wärs fertig gewesen hätte die CMD auf eine neue Eingabezeile wechseln müssen. Trotzdem fürchte ich, dass das nicht nur mir an der Stelle so geht. ↩︎
Tach!
Habe eben mal versucht, unser Offline-Wiki zu installieren. Dabei gibt es ein Problem mit VC-Redist:
In Folge (vermutlich deshalb?) kann dann auch der Server nicht richtig gestartet werden.
Eher nicht. Da ist bereits eine Version installiert, wie die Meldung sagt. Also kann diese Installation ruhig erfolglos abgebrochen werden.
Es ergeht zwar keine Fehlermeldung, der Aufruf des Servers unter
localhost:8000
führt aber ins Leere.
Wie sieht die Leere in deinem Fall aus? Erzählt der Browser, dass er keine Verbindung herstellen konnte, oder kommt eine Fehlermeldung aus der HTTP-Ebene? Oder was ganz anderes?
Die Ursache wird eine andere sein, vielleicht Ports, die bereits in Belegung sind. Auch unsachgemäßes Abbrechen der start.cmd verursacht(e) Hänger. Das Strg+C beendet zwar den Nginx, aber die Batch-Datei reagiert auch darauf und darf nicht abgebrochen werden, denn da muss noch mehr aufgeräumt werden. Andererseits hab ich eingebaut, dass beim erneuten Start Überreste beendet werden. Aber Fremdzeugs, das auf Port 8000 oder 9000 läuft, kann ich nicht beenden.
Schau auch mal ins Logfile im logs-Verzeichnis. Zur Not auch in die Ereignisanzeige (Event Viewer) von Windows. Auch Löschen des Installationsverzeichnisses und Neustart der Prozedur kann vielleicht helfen. Den Installationswunsch vom Redistributable kannst du dabei gleich ablehnen.
Insgesamt ist mir im Installationsprozess noch aufgefallen, dass es ein paar Stellen gibt, an denen die
setup.cmd
sehr lange braucht, ohne, dass dabei angezeigt wird, dass gerade etwas passiert. Besonders extrem ist das vor der Installation von VC-redist; vor allem, da die dortige Erfolgsmeldung für das Entpacken der lokal vorgehaltenen Dateien den Anschein erweckt, die Installation sei schon vollkommen fertig. Das hat dazu geführt, dass ich im ersten Installationsversuch erstmal das CMD-Fenster an der Stelle geschlossen hatte, in dem Gefühl, alles sei erledigt.[^1]
Ist dein Rechner so langsam oder deine Toleranzgrenze zu niedrig? Es gibt da zwar Aktionen mit unterdrückter Anzeige, aber so lange dauert das doch eigentlich nicht.
Vielleicht hilft es, hier ein "Bitte warten Sie..." einzufügen.
Kann man machen.
Klar, das war eine Fehlbedienung - wärs fertig gewesen hätte die CMD auf eine neue Eingabezeile wechseln müssen. Trotzdem fürchte ich, dass das nicht nur mir an der Stelle so geht.
Gab noch keine Klagen diesbezüglich.
dedlfix.
Aloha ;)
Vorweg: Ich habe das Ganze eben noch einmal versucht, und, oh Wunder, jetzt tut das Ganze auf einmal, und das ohne, dass ich irgendwas anders gemacht hätte. Dein letzter Tipp mit neu entpacken etc.pp. hat also geholfen.
Eher nicht. Da ist bereits eine Version installiert, wie die Meldung sagt. Also kann diese Installation ruhig erfolglos abgebrochen werden.
Es ergeht zwar keine Fehlermeldung, der Aufruf des Servers unter
localhost:8000
führt aber ins Leere.Wie sieht die Leere in deinem Fall aus? Erzählt der Browser, dass er keine Verbindung herstellen konnte, oder kommt eine Fehlermeldung aus der HTTP-Ebene? Oder was ganz anderes?
Die Leere war ein „der Browser kann keine Verbindung herstellen“, also keine HTTP-Fehlermeldung (sonst hätte ich ja auch gewusst, dass der Server zumindest läuft).
Die Ursache wird eine andere sein, vielleicht Ports, die bereits in Belegung sind. Auch unsachgemäßes Abbrechen der start.cmd verursacht(e) Hänger. Das Strg+C beendet zwar den Nginx, aber die Batch-Datei reagiert auch darauf und darf nicht abgebrochen werden, denn da muss noch mehr aufgeräumt werden. Andererseits hab ich eingebaut, dass beim erneuten Start Überreste beendet werden. Aber Fremdzeugs, das auf Port 8000 oder 9000 läuft, kann ich nicht beenden.
Könnte möglich sein. Eben lief bei mir auf Port 8000/9000 nichts, und ich weiß auch nicht, was da gestern hätte laufen sollen, Ich hatte bewusst nichts ungewöhnliches am Laufen, ich kann das aber natürlich auch nicht ausschließen. Sollte es nochmal zu Problemen kommen werde ich das prüfen.
Die Geschichte mit dem Abbrechen der Batch-Datei könnte tatsächlich das Problem gewesen sein, da habe ich vermutlich nicht genau genug gelesen.
Schau auch mal ins Logfile im logs-Verzeichnis. Zur Not auch in die Ereignisanzeige (Event Viewer) von Windows. Auch Löschen des Installationsverzeichnisses und Neustart der Prozedur kann vielleicht helfen. Den Installationswunsch vom Redistributable kannst du dabei gleich ablehnen.
…
Und jetzt habe ich tatsächlich das Problem gefunden. Habe das Verzeichnis von gestern wiederhergestellt um ins logs-Verzeichnis zu schauen und dabei nichts gefunden. Habe dann nochmal verucht, dort zu starten, und es ging wieder nicht. Eine Fehlermeldung bei Strg+C hat mich auf die richtige Spur gebracht: das offline-Wiki lag unterhalb eines Verzeichnisses, das ein Leerzeichen im Namen hatte. Damit kommt das offline-Wiki offensichtlich nicht klar. Ein Umbenennen des Verzeichnisses und Ersetzen des Leerzeichens durch ein - hat die Lösung gebracht, seither läuft das Ganze wie eine 1.
Ich gehe also tatsächlich davon aus, dass da noch ein Fehler in der Batch-Datei ist, da Leerzeichen offenbar nicht escaped werden. Kannst du das bestätigen?
Insgesamt ist mir im Installationsprozess noch aufgefallen, dass es ein paar Stellen gibt, an denen die
setup.cmd
sehr lange braucht, ohne, dass dabei angezeigt wird, dass gerade etwas passiert.Ist dein Rechner so langsam oder deine Toleranzgrenze zu niedrig? Es gibt da zwar Aktionen mit unterdrückter Anzeige, aber so lange dauert das doch eigentlich nicht.
Ich schätze, letzteres. Vielleicht gab es gestern an dem Ort, wo ich zunächst installiert habe, auch eine ungünstige Wechselwirkung mit dem gleichzeitigen Upload der Dateien in meine Cloud. Heute habe ich maximal 5 Sekunden gewartet, gestern war das, zumindest gefühlt, länger.
So wie das heute war stört es mich auch nicht mehr.
Klar, das war eine Fehlbedienung - wärs fertig gewesen hätte die CMD auf eine neue Eingabezeile wechseln müssen. Trotzdem fürchte ich, dass das nicht nur mir an der Stelle so geht.
Gab noch keine Klagen diesbezüglich.
Ich gehe davon aus, dass das Offline-Wiki nicht ganz so extrem häufig genutzt wird - schon allein deshalb, weil in den letzten Jahren ja die Gelegenheiten, in denen man mal ohne Internet ist, immer weiter zurückgehen, im Vergleich zu früher.
Kann also gut sein, dass der Leidensdruck bei nicht-funktionierendem Offline-Wiki nicht groß genug ist, um deshalb eine Beschwerde zu formulieren. Vielleicht wird ein Nicht-Funktionieren oft auch mit einem Achselzucken hingenommen.
Grüße,
RIDER
Hallo Camping_RIDER,
Ich gehe davon aus, dass das Offline-Wiki nicht ganz so extrem häufig genutzt wird - schon allein deshalb, weil in den letzten Jahren ja die Gelegenheiten, in denen man mal ohne Internet ist, immer weiter zurückgehen, im Vergleich zu früher.
Passend dazu war gestern in der Post:
„die Idee der Offlineversion von SelfHTML ist sehr gut. Gerade wenn man in einem HotSpot freien Zug unterwegs ist, kann man auch mal schnell nachschlagen.“
Bis demnächst
Matthias
Tach!
Und jetzt habe ich tatsächlich das Problem gefunden. [...] ein Leerzeichen im Namen [...]
Ich gehe also tatsächlich davon aus, dass da noch ein Fehler in der Batch-Datei ist, da Leerzeichen offenbar nicht escaped werden. Kannst du das bestätigen?
Zumindest ist das ein bekanntes Windows-Problem/Feature seit es mehr als 8+3-Dateinamen gibt, dass bei Leerezeichen im Pfad der Pfad quotiert werden muss. Da muss ich wohl noch ein paar Anführungszeichen in die Scripts reinwerfen.
dedlfix.
Hallo,
Ich gehe also tatsächlich davon aus, dass da noch ein Fehler in der Batch-Datei ist, da Leerzeichen offenbar nicht escaped werden. Kannst du das bestätigen?
Zumindest ist das ein bekanntes Windows-Problem/Feature seit es mehr als 8+3-Dateinamen gibt, dass bei Leerezeichen im Pfad der Pfad quotiert werden muss.
das ist aber kein Alleinstellungsmerkmal von Windows. Auch in der bash muss ein Dateiname, der Leerzeichen enthält, in Anführungszeichen gesetzt werden - oder man muss die Leerzeichen mit einem vorangestellten Backslash escapen. Diese in der bash AFAIK bevorzugte Methode kennt Windows nicht.
Da muss ich wohl noch ein paar Anführungszeichen in die Scripts reinwerfen.
Das könnte helfen.
Ciao,
Martin
Hallo
Zumindest ist das ein bekanntes Windows-Problem/Feature seit es mehr als 8+3-Dateinamen gibt, dass bei Leerezeichen im Pfad der Pfad quotiert werden muss.
das ist aber kein Alleinstellungsmerkmal von Windows. Auch in der bash muss ein Dateiname, der Leerzeichen enthält, in Anführungszeichen gesetzt werden - oder man muss die Leerzeichen mit einem vorangestellten Backslash escapen. Diese in der bash AFAIK bevorzugte Methode kennt Windows nicht.
Die wäre unter Windows, wo der Backslash die Bedeutung des Trenners zwischen den Pfadbestandteilen hat, auch eher kontraproduktiv. 😉
Tschö, Auge
Mahlzeit,
[...] die Leerzeichen mit einem vorangestellten Backslash escapen. Diese in der bash AFAIK bevorzugte Methode kennt Windows nicht.
Die wäre unter Windows, wo der Backslash die Bedeutung des Trenners zwischen den Pfadbestandteilen hat, auch eher kontraproduktiv. 😉
das liegt auf der Hand. Wenig bekannt ist allerdings, dass Windows mindestens seit 5.0 auch den normalen, vorwärts gerichteten Slash als Verzeichnistrenner versteht. Zumindest auf API-Ebene; in der Shell nicht durchgehend.
Das bevorzugte Verzeichnis-Trennzeichen wird in WIndows wohl auf absehbare Zeit der Backslash bleiben.
Ciao,
Martin
Hallo
Mahlzeit,
Dito.
… Windows, … Backslash … Trenner zwischen den Pfadbestandteilen
das liegt auf der Hand. Wenig bekannt ist allerdings, dass Windows mindestens seit 5.0 auch den normalen, vorwärts gerichteten Slash als Verzeichnistrenner versteht. Zumindest auf API-Ebene; in der Shell nicht durchgehend.
Ist mir auch schon aufgefallen. Wenn man viel mit Linux arbeitet, bleibt es nicht aus, an der Tastatur „falsche“ Bewegungsabläufe zu etablieren. Da bleibt es nicht aus, auch mal den Slash zum trennen von Verzeichnisnamen zu verwenden und sich zu wundern, dass das „aus Versehen“ funktioniert.
Tschö, Auge