Ich kann aber nicht erkennen, das sich diese Blocksize nicht ändern dürfte. Das ist der eine Punkt. Meine Hardware kann sich unter Linux selbst im laufenden Betrieb ändern. Und grundsätzlich darf sie das auch. Das hat doch einen Dienst nicht zu interessieren, der nix mit dem Dateisystem zu tun hat.
Und dann halt, das die Identifikation ausgerechnet über einen Hardwareabhängigen Parameter stattfindet. Ich verstehe nicht, weichen Sinn das macht.
Ich mein, ich verstehe eure Intention und in gewisser Weise kann ich das auch nachvollziehen, es ist aber irgendwie so eine Windows/Kommerz Sicht auf die Dinge. Warum werde ich als zahlender Kunde damit gegängelt? Wie gesagt, meine Blocksize geht euch doch gar nix an vom Prinzip… Das ist eben die Linux Sicht.
Alles schön und gut. Aber das heißt ja nicht, das der nicht anständig funktionieren darf. Mit dem gleichen Argument kannst du alle Features seit 1.x streichen, die sind ja alle quasi kostenlos weil nicht teurer geworden.
Es ist kommerzielle Software und die muss funktionieren. In wie weit das bei neuen Funktionen geht, das steht auf einem anderen Blatt. Aber grundsätzlich ist es so.
Nein das ist falsch gedacht.
Weil du jetzt Features meinst welche in der Software integriert sind und dafür zahlt du ja mit dem Recht auf Upgrades.
Der ConnectDienst ist aber ein serverseitiger Cloud-Dienst (wenn man dieses Wort benutzen darf).
Deine neuen Features im Dienst laufen auch nach Ablauf der Subscribtion. Der ConnectDienst nicht.
Also bitte nicht in einen Topf werfen.
Du bist ja scheinbar auch der einzige, wo dies Problem des sich ändernden Token auftritt.
Wie gesagt, ich habe auch Ubuntu mit IPS und Connect. Bei mir gibt es keine Probleme. Weder Abbrüche noch sich ändernden Token nach einem Neustart.
Ob und in wie weit das bestimmen des Token über die von Paresy genannten Parameter sinnvoll ist, werde ich mich nicht äußern. Dafür stecke ich nicht tief genug in Linux.
Michael
Aber das bedeutet ja auch nicht, dass es bei mir nicht funktionieren darf.
Und wenn ich bei mir das Filesystem virtualisiere aus Gründen, die ich für notwendig erachte und nicht weiter erörtern möchte, dann hat das doch eine xbeliebige Applikation nicht zu interessieren. Schon gar nicht, wenn die mit dem Dateisystem nicht mehr zu tun als datei open read write close.
Ich finds einfach ganz schlecht so, wie es gemacht ist. Ich ganz persönlich. Für mich.
Der Connect Dienst ist seit mehreren JAHREN BETA und wird quasi über die Subscription bezahlt ! Ich denke er sollte schön langsam aus dem BETA Status sein. Nur weil es eine neue Leistung ist, muss sich doch deshalb der Preis nicht erhöhen. Eine gewisse Weiterentwicklung wird ja genau mit der Subscription bezahlt! Dafür habe ich doch das ABO !
ich hätte dann doch noch eine - vielleicht dumme - Frage zum connect Modul.
Ich habe für unseren Verein eine Zugangs- und Maschinenverwaltung mit symcon auf einem RASPI 3 realisiert.
Diese lief schon recht zuverlässig in unseren alten Räumen, doch ich musste nach einem Umzug einiges ändern um den neuen KESO Mozy (Motorzylinder) anzusteuern.
Alle Änderungen wurden gemacht und Testweise lief das System ohne Probleme bei mir zu Hause.
Dann kam der Tag, an dem wir das System den Mitgliedern auf einem Tisch vorführen wollten und zuerst ging auch alles ohne Probleme.
Doch nach wenigen Minuten stellten sich riesige Verzögerungen ein, d.h. wir konnten in der Debug Konsole sehen, dass Signale über den seriellen am RASPI ankamen, dieser aber erst nach gefühlten Minuten entsprechend reagierte.
Der Grund dafür war/ist uns nicht unbedingt klar - aber mir viel dann plötzlich ein, dass der connect Dienst ja noch aktiviert war, wir aber in unseren Vereinsräumen (noch) keine Internetverbindung haben.
Wir haben dann versucht, den connect Dienst abzuschalten, was sich auch irgendwie schwierig gestaltete - aber nach mehreren Versuchen klappte dies dann.
Zu diesem Zeitpunkt war es dann leider schon recht spät in der Nacht und der Frustrationslevel hoch.
Jedoch schien sich unser System plötzlich wieder normal zu verhalten - muss aber noch verifiziert werden.
Nun meiner Kern-Frage:
Kann es sein, dass erfolglose Verbindungsversuche des connect-Dienstes derart ‚resourcengierig‘ sind, dass anstehende Treads über Minuten verzögert abgearbeitet werden?
ich kann mir keinen Zusammenhang erklären, da das zwei komplett voneinander gelöst Themen sind. In wiefern war das Deaktivieren denn problematisch? Es gibt beim Verbinden ein 30 Sekunden Timout - Ggf. reagiert die Konsole etwas träger beim Deaktivieren. Das sollte aber wie gesagt nicht länger als 30 Sekunden dauern.
Komisch ist auch, dass der Connect Dienst bei dir zu Hause 1A läuft und vor Ort dann ab und zu diese Aussetzer hat. Ist die Verbindung dort evtl. ab und zu gestört? (Wir haben da im aktuellsten 4.4er Update noch ein kleines Randproblem korrigiert und natürlich vor einigen Wochen am Connect Server Verbesserungen durchgeführt - somit freue ich mich natürlich über Feedback, ob es noch diese Aussetzer gibt.)
Das mit den Aussetzern war in unseren alten Räumen - wir sind zwischenzeitlich umgezogen und der Telekomiker kommt am Montag, um uns ans Netz zu bringen.
Muss dann mal sehen, ob das dort stabiler ist.
ich muss den Connect Dienst jeden Tag neu aktivieren. Selten auch 2 mal am selben Tag. Ist das normal, kann ich das umgehen? Es macht irgendwie wenig Sinn, wenn ich jeden Tag erneut in die Konsole muss um den Dienst zu aktivieren. Dann ist die Sprachsteuerung via Alexa auch nicht mehr so komfortabel
ich muss das häckchen jeden Tag neu setzen der Dienst ist einfach nicht mehr aktiv. Vor dem übernehmen muss ich auch noch immer den Server reaktivieren falls das von Bedeutung ist?!
Kernal Version: 4.30 (ist das die, die du wissen wolltest?)
@snook: Das wird das Problem sein. Wo läuft dein IP-Symcon denn drauf? Irgendwelche Hardware Gegebenheiten müssen sich bei dir ändern, sodass der Server-Token nicht stimmt.
@parsey: Ich hatte heute wieder Zeit mich mit IPS zu beschäftigen und muss leider wieder festellen, dass der Connect Dienst deaktiviert ist.
Ich verwende eine SymBox die direkt an meine Fritzbox geht. Ich wüsste nicht was sich verändern soll .
System einsehen:
Fri Jan 26 16:19:44 CET 2018
16:19:44 up 1 day, 22:27, load average: 0.00, 0.01, 0.00
Linux SymBox 4.9.61 #2 Sat Nov 18 20:43:29 UTC 2017 armv6l GNU/Linux
Und Kernel Version ist nun 4.4. Ich hatte nach unserem letzten Gespräch alles upgedatet.
kannst du uns Logs bereitstellen, die über die Zeit des Umschaltens gehen? Sprich, schalte den Connect mal wieder an. Wenn er sich dann wieder deaktiviert, dann kann man mal ins Log schauen, woran das denn liegt.
ja klar kann ich gerne machen. Aber ich weiß nie genau wann sich der Connect Deinst verabschiedet das muss meistens in der Nacht passieren?!
Ich habe jetzt die Log Datei runtergeladen, die erstellt worden ist als ich den Deinst aktiviert habe. Dann kann ich morgen früh erst die Log Datei laden, wo der Deinst nicht mehr aktiv.
du meinst ich soll mir ein Skript schreiben, welches den Dienst wieder aktiviert sobald er getrennt ist?
Ist das denn Sinn der Sache? Wenn ich das so richtig raushöre sollte der Deinst eigentlich kontinuierlich aktiv bleiben?!
ich habe jetzt eine Log-Datei. Hatte den Dienst heute morgen aktiviert und er hat sich vorhin wieder automatisch deaktivert. Vllt kann mir jemand mit den log-Datein helfen. Ich kenn mich damit zu wenig aus um daraus schlau zu werden.
