NEWS
SQL-Adapter beim Update zerschossen
-
Hallo zusammen,
nachdem ich jetzt schon den ganzen Abend verzweifelt versucht habe meinen SQL-Adapter wieder ans Laufen zu bekommen muss ich jetzt doch mal eure geballte Intelligenz in Anspruch nehmen
Ich wollte eigentlich nur meinen SQL-Adapter auf die aktuellste Version (von 1.5.3) updaten. Beim Update hat es mir aber die Installation komplett zerschossen, d.h. er hat dann beim Start des Adapters diverse Dateien in einem Pfad "/null" gesucht und natürlich nix gefunden. Der Pfad "iobroker.sql" unter "..\iobroker\node-modules" ist auch gar nicht mehr vorhanden - obwohl der Adapter im Admin immer noch als installiert angezeigt wird. Hab's auch schon mit Neuinstallation des Adapters versucht - die läuft sogar ohne Fehlermeldungen durch, aber hinterher ist genau so NICHTS da was funktionieren würde Momentan macht sich totale Ratlosigkeit breit... Natürlich könnte ich das letzte Backup einspielen, aber erstens hab ich dann trotzdem wieder eine ziemlich alte Version des SQL-Adapters drauf und muss mal wieder upgraden und außerdem bin ich überhaupt kein Freund davon Fehler aller Art durch Neuinstallation oder Rollback zu "beheben" - ich will schon herausfinden wo der Pfeffer im Hasen liegt...Meine Versionen:
JS-Controller: 1.5.7
Node: 8.11.3
npm: 6.9.0Hier mal noch das Log vom letzten Updateversuch
-
@Thisoft
Als erstes bitte node updaten.
8.11 hat ein speicherleck -
So. Node hab ich updated. Das war aber mit Sicherheit nicht die Ursache. Es geht genau so wenig wie vorher:-(
Hab mittlerweile verschiedenes und mehrfach versucht... Der SQL-Adapter will einfach nicht mehr zu mir... Ich bin mir mittlerweile ziemlich sicher dass es ein Problem mit den windows-build-tools gibt. Hab die auch mittelsnpm install --global windows-build-tools
neu installiert was auch lt. Konsole fehlerfrei durchgelaufen ist. Aber die Installation des SQL-Adapters geht trotzdem nicht. Hier das aktuelle Log:
Wäre toll wenn jemand noch eine Idee für mich hätte...
Update:
Hab inzwischen nochmal Node kpl. deinstalliert und jetzt mal die 10.9er Version installiert. Die Installation hat auch soweit geklappt und ioBroker läuft wieder. Was mir aber jetzt aufgefallen ist: Lt. Konsolenausgabe habe ich kein NodeJs mehr...C:\ioBroker>npm -v 6.9.0 C:\ioBroker>node -v v10.9.0 C:\ioBroker>nodejs -v Der Befehl "nodejs" ist entweder falsch geschrieben oder konnte nicht gefunden werden.
Hab nochmal die Reparaturinstallation drüber gelassen und in der Path-Systemvariablen steht auch der Pfad korrekt drin...???
Noch eine Frage: Was bedeutet denn eigentlich dieses Node-gyp-Gedöns? Da meckert er ja offensichtlich auch was rum damit...
gyp ERR! node-gyp -v v3.8.0 gyp ERR! not ok npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! mmmagic@0.5.2 install: `node-gyp rebuild` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the mmmagic@0.5.2 install script
-
Muss das mal nach oben holen Keiner eine Idee???
Hab mittlerweile nochmal Node komplett runtergeschmissen und neu installiert
Jetzt sieht die Versionskontrolle so aus:C:\ioBroker>npm -v 6.4.1 C:\ioBroker>node -v v10.15.3 C:\ioBroker>nodejs -v Der Befehl "nodejs" ist entweder falsch geschrieben oder konnte nicht gefunden werden.
Ich denke dass da was im Argen liegt weil "nodejs" unbekannt ist - aber wo könnte das Problem sein? Ansonsten läuft aber der ioBroker wieder, nur der SQL-Adapter ist nach wie vor ein Problem. Wenn ich einen versuche hinzuzufügen tut er das:
$ ./iobroker add sql 0 --host Acer2 ERROR: events.js:174 throw er; // Unhandled 'error' event ^ Error: listen EADDRINUSE: address already in use 0.0.0.0:9001 at Server.setupListenHandle [as _listen2] (net.js:1270:14) at listenInCluster (net.js:1318:12) at doListen (net.js:1451:7) at process._tickCallback (internal/process/next_tick.js:63:19) Emitted 'error' event at: at emitErrorNT (net.js:1297:8) at process._tickCallback (internal/process/next_tick.js:63:19) ERROR: process exited with code 1
Ist zwar jetzt mal was Anderes, aber was sucht er denn da auf der Adresse 0.0.0.0:9001 ???
Bitte um Ideen - will doch nur meinen SQL-Adapter wiederhaben...:-(:-(
-
kann dir nur bestätigen, das das Upgrade diesen Fehler auftreten lässt.
Bin mittels Backup wieder zurück. -
@Jeeper-at Danke, das beruhigt mich zumindest in sofern dass es nicht nur alleine meine Dummheit ist
Dann sind das wohl die Nachteile von OpenSource - viele Programmierer verderben den Versions-Brei
Hilft mir zwar nicht wirklich weiter... mal sehen, ob Dr.Google noch was dazu erzählt... Vielleicht kann ja @apollon77 als Adapter-Pfleger noch was dazu sagen...
-
@Thisoft sagte in SQL-Adapter beim Update zerschossen:
Ich denke dass da was im Argen liegt weil "nodejs" unbekannt ist
Wieso?
Nodejs war zu früheren zeiten, jetzt heisst es nur noch node.
Wie die pakete unter Windows heißen weiss ich nicht, aber wenn nodejs nicht gefunden wird uss das noch lange nicht schlecht sein.Wenn natürlich ein altes programm den befehl nodejs benutzen würde sollte per symlink node aufgerufen werden. Allerdings kenne ich mich mit Windows nicht aus.
@Thisoft sagte in SQL-Adapter beim Update zerschossen:
Dann sind das wohl die Nachteile von OpenSource - viele Programmierer verderben den Versions-Brei
Den Satz verstehe ich jetzt gar nicht. Kannst du mal sagen was du damit meinst.
-
@Homoran sagte in SQL-Adapter beim Update zerschossen:
Dann sind das wohl die Nachteile von OpenSource - viele Programmierer verderben den Versions-Brei
Den Satz verstehe ich jetzt gar nicht. Kannst du mal sagen was du damit meinst.
Ist nicht böse gemeint - ist halt so, bei anderer Software gibt's wieder andere Probleme. Ich meinte damit nur, dass ein Programmierer (z.B. der des Adapters) sich ja wieder auf Abhängigkeiten anderer Software (z.B. Node) verlässt (verlassen muss). Wenn dann an einem Ende bzw. zwischendurch ein Stück Software upgradet wird (was ja auch gut ist - sonst wär sie ja tot) dann ist halt nicht immer kontrollier- bzw. vorhersehbar was mit den nachfolgenden Abhängigkeiten passiert.
Nodejs war zu früheren zeiten, jetzt heisst es nur noch node.
Wie die pakete unter Windows heißen weiss ich nicht, aber wenn nodejs nicht gefunden wird uss das noch lange nicht schlecht sein.
Wenn das so ist dann wäre der Punkt ja schon mal geklärt und ich kann woanders weitersuchen. Ich dachte nur es wird gebraucht weil es in meiner bisherigen Installation (Node8.11) verfügbar war.
Jetzt brauch ich nur weitere Ideen...
-
Noch eine Frage dazu:
gyp ERR! node -v v10.15.3 gyp ERR! node-gyp -v v3.8.0 gyp ERR! not ok npm ERR! code ELIFECYCLEnpm ERR! errno 1 npm ERR! mmmagic@0.5.2 install: `node-gyp rebuild` npm ERR! Exit status 1
Was ist denn das "node-gyp" was da möglicherweise eine falsche Version hat oder anderweitig einen Fehler liefert?
-
@Thisoft @Jeeper-at Ja hat er:
Sorry, absoluter Müll! Die Version 1.9.4 ist von Anfang März und 1521 mal installiert ... also liegt es gaaaanz bestimmt an dieser Version und an den Open-Source-Entwicklern ... WTF ... Sorry, aber Bullshit. Solche Kommentare nerven ungemein. ja ich habe gelesen was Du weiter unten geschrieben hast, dennoch ...
@Jeeper-at Und wenn es mit einer Version bekannterweise Probleme gibt ... wo ist das GitHub issue?Damit mal zur Realität: Am Adapter hat sich seit laaaangem nichts mehr geändert! Der Adapter und das Adapter Update ist es nicht!
Jetzt mal zu Hilfeversuchen:
Wie weiter oben von Thisoft schon korrekt vermutet liegt die wahre Ursache darin das der Fehler auftritt:npm ERR! mmmagic@0.5.2 install:
node-gyp rebuild
Warum ist jetzt die interessante Frage. node-gyp ist der Teil der native kompilierte Module bei der Installation auf Deinem System jeweils neu baut.Weiterhin hattest Du Zu beginn node 8, jetzt node 10. Hast Du generell ein "npm rebuild" ausgeführt wie man es bei nodejs Updates braucht? Sonst kann gerade noch mehr defekt sein. Das "Nodejs" unbekannt ist könnte zu anderen Dingen führen, aber ich denke hat mit dem Problem nichts zu tun.
Mit einer Google Suche kommst Du ganz schnell zu https://github.com/mscdex/mmmagic/issues/135 ... und schau mal von wem das ist ... Also Ja es liegt an Deinen Build Tools denke ich. Diese mmmagic braucht seit node 10 (was Du ja jetzt hast) eine höhere Version der MS VS Libs, nämlich mindestens 2015 ... An sich sollte das aber bei den Build Tools installiert werden (https://www.npmjs.com/package/windows-build-tools#visual-studio-2017-vs-visual-studio-2015) Schau da nochmal rein ...
-
@apollon77 sagte in SQL-Adapter beim Update zerschossen:
Sorry, absoluter Müll! Die Version 1.9.4 ist von Anfang März und 1521 mal installiert ... also liegt es gaaaanz bestimmt an dieser Version und an den Open-Source-Entwicklern ... WTF ... Sorry, aber Bullshit. Solche Kommentare nerven ungemein. ja ich habe gelesen was Du weiter unten geschrieben hast, dennoch ...
Ich weiß selber aus Erfahrung dass solche "Verallgemeinerungen" ungemein nerven können. Sorry wenn ich da schief rüberkam, ich hab aber auch nirgends behauptet dass das an den Entwicklern liegt...
Ich weiß dass die Version von Anfang März ist, eben deshalb fand ich jetzt dass es mal Zeit wäre upzudaten
"npm rebuild" hab ich nach jeder Node-Neuinstallation gemacht. Das Node-Upgrade hab ich übrigens gemacht weil Homoran oben meinte dass die 8er-Version ein Speicherleck hätte...
Mit den Windows-Build-Tools hab ich mich auch schon beschäftigt. Die sind mit Sicherheit hier der Kern des Übels. Ich hab die auch gleich nach dem ersten Fehlschlag mit "npm install --global windows-build-tools" upgedated - dachte ich zumindest. Leider verweist da wohl irgendwo irgendwas irgendwie auf die falsche Version. Zwischendurch stand mal in der Konsole dass er die "V141" sucht und diese aber in einem Pfad namens "...\V140" nicht finden kann - verständlich.
Die V141 sind lt. Google die MSBuildTools 2017, diese waren aber bereits installiert und ich hab das alles auch nochmal neu installiert, zwischendurch die 2015er Version auch mal runtergeworfen...
Hat bis jetzt alles nichts geholfen:-( Von der Warte bin ich eben mittlerweile auch so bisschen an dem Punkt wo ich das nur noch als nervigen Bullshit finde - ich hoffe das ist auch ein wenig verständlich...Wie auch immer - irgendwie muss ich durch - ich plage mich mal weiter mit den Build-Tools herum...
-
Hey,
alles gut.
Naja hättest auf in der 8er Linie updazen können - denke das meinte Homoran eher Alles unter 8.15 hatte nen memory-leak, aber alles danach nicht mehr. Also ein Update auf 8.15 hätte gereicht, aber jetzt bist Du denke einige Schritte weiter.
Das das mit den Build Tools nervt kann ich verstehen, da bin ich dann aber leider kein Windows-User der da viel helfen könnte Vllt mal über Windows-Einstellungen MS VS xx Pakete deinstallieren falls die da drin gelistet sind
Danach dann über die windows-build-tools neu installieren ?!
Drücke die Daumen das Du es hinbekommst -
@Jeeper-at Und wenn es mit einer Version bekannterweise Probleme gibt ... wo ist das GitHub issue?
Was ein GIT Issue bringt sehe ich ja am Plumb. Der ist sei Monaten offen. Ach ja, der ist ja nur auf Platz 246 der Wichtigkeitskala.
Ich kann nur sagen, das nach dem Upgrade der SQL nicht mehr funktioniert hat. Und zwar genauso wie der TE geschrieben hat. Ob du das jetzt Müll findest bleibt dir überlassen.
-
@Jeeper-at Habs ja fast geahnt das das Deine Antwort ist. Äpfel und Birnen ...
Fakten zu "nach dem Update tut es nicht mehr" stehen oben, wenn Du dazu etwas neues beizutragen hast dann jederzeit gern. Ich persönlich habe sql unter node 8 und 10 unter Linux laufen ohne Probleme und das automatische Adapter-Testing läuft mit MSVS2015 ebenfalls problemlos mit nodejs 10. Probleme, siehe oben, sind momentan nur bekannt unter Windows und mit nodejs 10 und MSVS <2015.
-
So - mal wieder ein kleines Update - hatte die Feiertage nicht wirklich Zeit für diese Baustelle...
Ich habe:
-erstmal alle (also ALLE) MS C++ Redistributables deinstalliert
-dann mal Reboot und alles nochmal gecheckt ob's weg ist
-dann ein "npm install --global windows-build-Tools"; damit hab ich die 2017er Version bekommen
-wieder ein Reboot
-nochmal zur Sicherheit "npm rebuild" (weiß nicht ob das nötig war - dieses ständige Neukompilierungskonzept von Linux hab ich noch nicht wirklich verstanden...)
-dann neuer Versuch; wieder erfolglos allerdings mit etwas anderen Fehlermeldungen:C:\ioBroker>iobroker install sql@latest --production C:\ioBroker>node node_modules/iobroker.js-controller/iobroker.js install sql@latest --production NPM version: 6.4.1 npm install iobroker.sql@latest --production --save --prefix "C:/ioBroker" (System call) npm WARN deprecated sprintf@0.1.5: The sprintf package is deprecated in favor of sprintf-js. npm WARN deprecated core-js@1.2.7: core-js@<2.6.5 is no longer maintained. Please, upgrade to core-js@3 or at least to actual version of core-js@2. gyp ERR! build error gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1 gyp ERR! stack at ChildProcess.onExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\build.js:262:23) gyp ERR! stack at ChildProcess.emit (events.js:189:13) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12) gyp ERR! System Windows_NT 10.0.17134 gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild" gyp ERR! cwd C:\ioBroker\node_modules\iobroker.sql\node_modules\mmmagic gyp ERR! node -v v10.15.3 gyp ERR! node-gyp -v v3.8.0 gyp ERR! not ok npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! mmmagic@0.5.2 install: `node-gyp rebuild` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the mmmagic@0.5.2 install script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR! A complete log of this run can be found in: npm ERR! C:\Users\Thilo\AppData\Roaming\npm-cache\_logs\2019-04-23T07_25_53_799Z-debug.log host.Acer2 Adapter directory "null" does not exists Cannot parse null/io-package.json:Error: ENOENT: no such file or directory, open 'null/io-package.json'`` Kann mir bitte jemand helfen, was ich jetzt gegen diesen node-gyp-Error 1 und ELIFECYCLE tun müsste? Verzweifelte Grüße Thilo
-
Hey, das ist Mist
Der "Neukompilierungskram von Linux" hat in dem Fall nichts mit Linux zu tun. Es geht simpel um Performance. Einige nodejs Module haben "binäre" teile die nicht in Javascript geschrieben sind sondern in C/C++, meistens wegen performance oder weil man nur so System-Libs nutzen kann. Das kann man zum Teil "vorkompilieren" und laden aber einige hängt auch von anderen lokalen Libraries auf dem Zielsystem ab. Damit bleibt nur der Weg diese binären Teile bei der Installation zu kompilieren. Und das ist das was hier passiert. Also nix Linux Auch Windows ...
Am besten probier das doch mal getrennt von iobroker aus ... Leg ein verzeichnis an egal wo und öffne shell dahin. Dann
"npm install mmmagic@0.5.2 --production"
Dann sollte der gleiche Fehler kommen. Dann aber mal das Logfile was da angegeben wird posten, vllt ist da ja was hilfreiches drin
-
@apollon77
Also --- der Fehler bleibt der Gleiche, egal wohin ich mmmagic versuche zu installieren.
Was lt. Log IMO das Problem sein dürfte:Der Buildvorgang wurde am 23.04.2019 18:06:37 gestartet. Projekt "C:\ioBroker\node_modules\mmmagic\build\binding.sln" auf Knoten "1" (Standardziele). ValidateSolutionConfiguration: Die Projektmappenkonfiguration "Release|x64" wird erstellt. Das Projekt "C:\ioBroker\node_modules\mmmagic\build\binding.sln" (1) erstellt "C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj" (2) auf Knoten "1" (Standardziele). C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj(20,3): error MSB4019: Das importierte Projekt "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Cpp.Default.props" wurde nicht gefunden. Vergewissern Sie sich, dass der Pfad in der <Import>-Deklaration korrekt und die Datei auf dem Datentr„ger vorhanden ist. Die Erstellung des Projekts "C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj" ist abgeschlossen (Standardziele) -- FEHLER. Die Erstellung des Projekts "C:\ioBroker\node_modules\mmmagic\build\binding.sln" ist abgeschlossen (Standardziele) -- FEHLER. Fehler beim Buildvorgang. "C:\ioBroker\node_modules\mmmagic\build\binding.sln" (Standardziel) (1) -> "C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj" (Standardziel) (2) -> C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj(20,3): error MSB4019: Das importierte Projekt "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Cpp.Default.props" wurde nicht gefunden. Vergewissern Sie sich, dass der Pfad in der <Import>-Deklaration korrekt und die Datei auf dem Datentr„ger vorhanden ist. 0 Warnung(en) 1 Fehler
Irgendwie kann ich auch nichts finden dass während der Installation überhaupt der Ordner "..\mmmagic" erstellt würde geschweige denn irgendwelcher Inhalt... Schreibrechte hab ich aber, kann den Ordner aus der Konsole heraus anlegen...
Wäre das ein Ansatzpunkt?
-
@Thisoft sagte in SQL-Adapter beim Update zerschossen:
"C:\Program Files (x86)\MSBuild\14.0\Microsoft.Cpp.Default.props" wurde nicht gefunden
Ich habe mal etwas gegoogelt, vllt ist ja hier was drin:
https://stackoverflow.com/questions/16092169/why-does-msbuild-look-in-c-for-microsoft-cpp-default-props-instead-of-c-progr
https://stackoverflow.com/questions/49327432/microsoft-cpp-default-props-not-found-when-running-npm-install
https://stackoverflow.com/questions/41695251/c-microsoft-cpp-default-props-was-not-found -
Hurra - er läuft wieder
Deine Links waren zwar noch nicht die eigentliche Lösung aber der richtige Weg. Die Systemvariable "VCTargetsPath" war falsch. Allerdings waren alle Pfade die in den Links angegeben waren auch falsch. Ich habe dann auf meiner Platte erstmal nach Dateien namens "Microsoft.cpp" gesucht. Die liegen bei mir seltsamerweise in einem völlig anderen Pfad als überall von Dr.Google ausgespuckt wird... Kann sein, dass sich der Pfad mit der 2017er Version geändert hat, dass dann allerdings die entsprechenden Umgebungsvariablen nicht richtig gesetzt werden ist wohl entweder eine unglückliche Konstellation auf meinem Rechner oder ein Bug von Windows.
Jedenfalls habe ich dann die beiden Umgebungsvariablen wie folgt gesetzt:
C:\ioBroker>set VCTargetsPath=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets C:\ioBroker>set VS140COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\Tools
und dann lief die Installation des Adapters fehlerfrei durch Juhu - nach einer Woche endlich wieder geloggte Daten...
-
@Thisoft Cool gratuliere!
@Jeeper-at Vllt willst Du es auch mal so versuchen? Oder hast Du kein Windows und ein anderes Problem?