Drei Dinge fallen auf:
1. FHEM wird automatisch von user fhem gestartet, verwendet man das /etc/init.d/fhem skript um FHEM anzuhalten und wieder zu starten, wird FHEM nicht von user fhem gestartet sondern vom aktuell verwendeten Benutzer. Das führt zu Problemen mit dem Zugriff auf Dateien die fhem gehören (Logfiles, etc.). Man könnte das umgehen, wenn im Startskript statt perl fhem.pl fhem.cfg etwa sudo -u fhem perl fhem.pl fhem.cfg verwendet würde. Alternativ starten als service fhem start, macht aber vermutlich nicht jeder, jedenfalls sollte es keinen Unterschied machen ob der Dienst so oder so gestartet wird.
2. Das Anhalten wird im Skript mit perl fhem.pl $port "shutdown" realisiert, das funktioniert aber nur wenn fhem fehlerfrei läuft. Hat man eine deadlock situation e.g. Man ruft aus FHEM ein Skript oder Programm auf, das seinerseits eine Anfrage an FHEM richtet, geht gar nichts mehr, und auch das Start/Stop Skript hängt fest. Besser wäre kill -9 $(ps -u fhem | cut -d " " -f 1), das ist zwar nicht sonderlich elegant aber wirkungsvoll und stoppt _alle_ prozesse die von fhem gestartet wurden.
3. Die Zuordnung der Dateien unter /opt/fhem erfolgt nicht einheitlich. Nach Installation und update gehören zwar alle Dateien fhem, sind aber mal der Gruppe dialout und mal der Gruppe root zugeordnet.
Kannst Du einen getesteten Patch liefern fuer alle drei Bemerkungen?
Fuer 1 und 2 muss man contrib/init-scripts/fhem.3 aendern, fuer 3 contrib/DEBIAN/postinst.
zu 1: Die Behauptung ist falsch. Bei mir läuft fhem auch dann unter dem user "fhem", wenn ich es als root per "/etc/init.d/fhem start" aufrufe.
zu 2: Bei mir wird fhem im Skript per "pkill perl" beendet - ok, ich weiss aber auch, dass fhem die einzige perl-Anwendung ist, die auf meinem System läuft.
zu 3: ich würde eine generelle Zuordnung zu fhem:root bevorzugen anstatt zu fhem:dialout
da es mich interessiert hat habe ich es gleich einmal getestet und Punkt 1 kann ich so nicht nachvollziehen. fhem läuft als user fhem, auch wenn es durch root über "/etc/init.d/fhem start" gestartet wird.
zu 2. finde ich das es keinen Sinn macht von einem nicht funktionierenden FHEM auszugehen und so den Prozess grundsätzlich hart zu killen (den Fall hatte ich ehrlich gesagt auch mit FHEM noch nicht)
mal in die Windows-Welt geschaut: ein Programm/Dienst schließe/beende ich normal auch nicht über Taskmanager oder Eingabeaufforderung sonder nur wenn er /es wirklich mal abschmiert.
zu3. da ich mit dem Linux-Rechtesystem noch nicht soo viel zu tun hatte: ist es nicht relativ egal solange user fhem owner ist ? ist user root nicht eh auch in dialout / steht darüber und hat so zugriff?
1. das Problem von mimue ist, dass wenn der Desktop-Benutzer (also nicht root) FHEM via /etc/init.d/fhem startet, dann startet zwar FHEM, spaeter gibt es aber diverse Zugriffs-Probleme. Inwieweit man sowas mit "selbst schuld" abtun kann ist diskussionswuerdig.
2. "kill -9" beim Herunterfahren ist falsch (ich habe vorhin nicht nachgedacht), da FHEM keine Chance hat die diversen Stati und einmalige at Definitionen zu speichern. Das Init-System sollte eine bestimmte Zeit auf das normale Beenden warten, und wenn das nicht funktioniert, trotzdem weitermachen. Weiss jemand, ob das unter debian/ubuntu der Fall ist, oder ob man sowas selbst Programmieren muss?
3. ist nur ein Schoenheitsfehler, ist aber unproblematisch zu beheben.
zu Punkt 1 sehe ich eigentlich keinen Handlungsbedarf.
zu Punkt 2 bin ich grade am Testen verschiedener Varianten
zu Punkt 3 erledigt.
zu 2: ich schlage vor, das Beenden von fhem über
pkill -U fhem perl
auszulösen. In diesem Fall wird allen vom User "fhem" gestarteten Prozessen ein TERM geschickt anstatt ein SIGKILL. Das sollte in 99.9% eine zuverlässige Lösung darstellen.
Wobei ich anmerken möchte, dass ich das eingangs beschriebene Problem mit einer Deadlock-Situatuon, in der das Beenden per shutdown nicht funktioniert, bisher noch nie hatte.
Wo wir gerade beim Debian Paket sind... was wäre denn vom Vorschlag zu halten, spätestens zum nächsten Release ein echtes Debian repository bereitzustellen, sodass fhem einfach per "apt-get install" installiert und alle Abhängigkeiten automatisch beim Installieren berücksichtigt und aufgelöst werden können?
Bin gerne bereit, hierfür die entsprechenden Vorbereitungen zu treffen.
@betateilchen: Nur zu.
lüppt :)
1. gpg key des neuen repository ergänzen:wget -qO - http://fhem.betateilchen.de/repo/PublicKey | apt-key add -2. in /etc/apt/sources.list folgende Zeile ergänzen:deb http://fhem.betateilchen.de/repo ./3. die interne Paketverwaltung updaten:apt-get updateErgebnis:
Zitat
OK http://mirror.pmf.kg.ac.rs wheezy Release.gpg
OK http://security.debian.org wheezy/updates Release.gpg
OK http://mirror.pmf.kg.ac.rs wheezy-updates Release.gpg
OK http://mirror.pmf.kg.ac.rs wheezy Release
OK http://security.debian.org wheezy/updates Release
Holen: 1 http://fhem.betateilchen.de ./ Release.gpg [490 B]
OK http://mirror.pmf.kg.ac.rs wheezy-updates Release
Holen: 2 http://fhem.betateilchen.de ./ Release [1.202 B]
OK http://security.debian.org wheezy/updates/main Sources
OK http://mirror.pmf.kg.ac.rs wheezy/main Sources
OK http://mirror.pmf.kg.ac.rs wheezy/main i386 Packages
OK http://mirror.pmf.kg.ac.rs wheezy/main Translation-de_DE
OK http://security.debian.org wheezy/updates/main i386 Packages
OK http://mirror.pmf.kg.ac.rs wheezy/main Translation-de
Holen: 3 http://fhem.betateilchen.de ./ Packages [578 B]
OK http://mirror.pmf.kg.ac.rs wheezy/main Translation-en
OK http://mirror.pmf.kg.ac.rs wheezy-updates/main Sources
OK http://mirror.pmf.kg.ac.rs wheezy-updates/main i386 Packages/DiffIndex
OK http://mirror.pmf.kg.ac.rs wheezy-updates/main Translation-en/DiffIndex
OK http://security.debian.org wheezy/updates/main Translation-en
Ign http://fhem.betateilchen.de ./ Translation-de_DE
Ign http://fhem.betateilchen.de ./ Translation-de
Ign http://fhem.betateilchen.de ./ Translation-en
Es wurden 2.270 B in 3 s geholt (646 B/s).
Paketlisten werden gelesen... Fertig
4. fhem installieren, alle Paketabhängigkeiten auflösen:
apt-get -s install fhem
liefert folgende Ausgabe (Parameter -s bewirkt lediglich die Simulation der gesamten Installation):
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
libdevice-serialport-perl libencode-locale-perl libfile-listing-perl libfont-afm-perl libhtml-form-perl libhtml-format-perl
libhtml-parser-perl libhtml-tagset-perl libhtml-tree-perl libhttp-cookies-perl libhttp-daemon-perl libhttp-date-perl
libhttp-message-perl libhttp-negotiate-perl libio-socket-ip-perl libio-socket-ssl-perl liblwp-mediatypes-perl
liblwp-protocol-https-perl libmailtools-perl libnet-http-perl libnet-ssleay-perl libsocket-perl libtimedate-perl liburi-perl
libwww-perl libwww-robotrules-perl
Vorgeschlagene Pakete:
libdata-dump-perl libcrypt-ssleay-perl libauthen-ntlm-perl
Die folgenden NEUEN Pakete werden installiert:
fhem libdevice-serialport-perl libencode-locale-perl libfile-listing-perl libfont-afm-perl libhtml-form-perl libhtml-format-perl
libhtml-parser-perl libhtml-tagset-perl libhtml-tree-perl libhttp-cookies-perl libhttp-daemon-perl libhttp-date-perl
libhttp-message-perl libhttp-negotiate-perl libio-socket-ip-perl libio-socket-ssl-perl liblwp-mediatypes-perl
liblwp-protocol-https-perl libmailtools-perl libnet-http-perl libnet-ssleay-perl libsocket-perl libtimedate-perl liburi-perl
libwww-perl libwww-robotrules-perl
0 aktualisiert, 27 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Inst libencode-locale-perl (1.03-1 Debian:7.6/stable [all])
Inst libtimedate-perl (1.2000-1 Debian:7.6/stable [all])
Inst libhttp-date-perl (6.02-1 Debian:7.6/stable [all])
Inst libfile-listing-perl (6.04-1 Debian:7.6/stable [all])
Inst libfont-afm-perl (1.20-1 Debian:7.6/stable [all])
Inst liburi-perl (1.60-1 Debian:7.6/stable [all])
Inst libhtml-tagset-perl (3.20-2 Debian:7.6/stable [all])
Inst libhtml-parser-perl (3.69-2 Debian:7.6/stable [i386])
Inst liblwp-mediatypes-perl (6.02-1 Debian:7.6/stable [all])
Inst libhttp-message-perl (6.03-1 Debian:7.6/stable [all])
Inst libhtml-form-perl (6.03-1 Debian:7.6/stable [all])
Inst libhtml-tree-perl (5.02-1 Debian:7.6/stable [all])
Inst libhtml-format-perl (2.10-1 Debian:7.6/stable [all])
Inst libhttp-cookies-perl (6.00-2 Debian:7.6/stable [all])
Inst libhttp-daemon-perl (6.01-1 Debian:7.6/stable [all])
Inst libhttp-negotiate-perl (6.00-2 Debian:7.6/stable [all])
Inst libsocket-perl (2.002-1 Debian:7.6/stable [i386])
Inst libio-socket-ip-perl (0.16-2 Debian:7.6/stable [all])
Inst libnet-ssleay-perl (1.48-1+b1 Debian:7.6/stable [i386])
Inst libio-socket-ssl-perl (1.76-2 Debian:7.6/stable [all])
Inst libnet-http-perl (6.03-2 Debian:7.6/stable [all])
Inst libwww-robotrules-perl (6.01-1 Debian:7.6/stable [all])
Inst libwww-perl (6.04-1 Debian:7.6/stable [all]) []
Inst liblwp-protocol-https-perl (6.03-1 Debian:7.6/stable [all])
Inst libmailtools-perl (2.09-1 Debian:7.6/stable [all])
Inst libdevice-serialport-perl (1.04-2+b3 Debian:7.6/stable [i386])
Inst fhem (5.5 fhem.betateilchen.de [all])
Conf libencode-locale-perl (1.03-1 Debian:7.6/stable [all])
Conf libtimedate-perl (1.2000-1 Debian:7.6/stable [all])
Conf libhttp-date-perl (6.02-1 Debian:7.6/stable [all])
Conf libfile-listing-perl (6.04-1 Debian:7.6/stable [all])
Conf libfont-afm-perl (1.20-1 Debian:7.6/stable [all])
Conf liburi-perl (1.60-1 Debian:7.6/stable [all])
Conf libhtml-tagset-perl (3.20-2 Debian:7.6/stable [all])
Conf libhtml-parser-perl (3.69-2 Debian:7.6/stable [i386])
Conf liblwp-mediatypes-perl (6.02-1 Debian:7.6/stable [all])
Conf libhttp-message-perl (6.03-1 Debian:7.6/stable [all])
Conf libhtml-form-perl (6.03-1 Debian:7.6/stable [all])
Conf libhtml-tree-perl (5.02-1 Debian:7.6/stable [all])
Conf libhtml-format-perl (2.10-1 Debian:7.6/stable [all])
Conf libhttp-cookies-perl (6.00-2 Debian:7.6/stable [all])
Conf libhttp-daemon-perl (6.01-1 Debian:7.6/stable [all])
Conf libhttp-negotiate-perl (6.00-2 Debian:7.6/stable [all])
Conf libsocket-perl (2.002-1 Debian:7.6/stable [i386])
Conf libio-socket-ip-perl (0.16-2 Debian:7.6/stable [all])
Conf libnet-ssleay-perl (1.48-1+b1 Debian:7.6/stable [i386])
Conf libio-socket-ssl-perl (1.76-2 Debian:7.6/stable [all])
Conf libnet-http-perl (6.03-2 Debian:7.6/stable [all])
Conf libwww-robotrules-perl (6.01-1 Debian:7.6/stable [all])
Conf libwww-perl (6.04-1 Debian:7.6/stable [all])
Conf liblwp-protocol-https-perl (6.03-1 Debian:7.6/stable [all])
Conf libmailtools-perl (2.09-1 Debian:7.6/stable [all])
Conf libdevice-serialport-perl (1.04-2+b3 Debian:7.6/stable [i386])
Conf fhem (5.5 fhem.betateilchen.de [all])
Das Ganze funktioniert so für das aktuell bereitstehende Paket fhem-5.5.deb aus Oktober 2013.
Falls Du das hosten willst, und fhem.betateilchen.de eine feste IP hat, dann kann ich eine Umleitung fuer z.Bsp. apt.fhem.de einrichten.
Gute Idee (vorausgesetzt, Du kannst das tatsächlich über einen DNS-Redirect machen), ich melde mich per email in dieser Sache.
Zitat von: betateilchen am 04 Oktober 2014, 10:25:40
zu 2: ich schlage vor, das Beenden von fhem über
pkill -U fhem perl
auszulösen.
Da bisher keine Einwände gegen den Vorschlag kamen, habe ich diese Änderung heute eingebaut und eingecheckt.
Zitat von: mimue am 02 Oktober 2014, 19:49:54
Drei Dinge fallen auf:
Heute fiel mir noch ein 4tes "Ding" auf. Bei der Überführung von FHEM von Fritz!Box auf Raspberry Pi (Debian Wheezy) bekomme ich plötzlich Logeinträge wie:
sh: 30: ./bin/fhem-readleveljet: Bad substitutionNachdem ich mir fast einenWolf gesucht habe, stelle ich fest, daß Debian keine Standard-Shell verwendet, sondern "dash"
https://wiki.debian.org/DashAsBinSh (https://wiki.debian.org/DashAsBinSh)
Das ist fest verlinkt als /bin/sh, somit werden alle Skripte, die von FHEM aufgerufen werden, unter dash ausgeführt.
Also entweder /etc/init.d/fhem anpassen ( #!/bin/bash statt #!/bin/sh ) oder die Verlinkung auf "dash" auf "sh" oder "bash" setzen.
mimue
Da bist Du aber bisher der Einzige, der mit /bin/sh unter Debian ein Problem hat - vielleicht liegts ja schlichtweg an Deiner Linux-Installation selbst?
Zitat von: betateilchen am 07 Oktober 2014, 19:46:32
Da bist Du aber bisher der Einzige, der mit /bin/sh unter Debian ein Problem hat - vielleicht liegts ja schlichtweg an Deiner Linux-Installation selbst?
Zum Einen habe ich kein Problem mit /bin/sh sondern mit
ln -s /bin/dash/ /bin/sh (Wer lesen kann ist klar im Vorteil), zum anderen verwende ich die Installation von Debian so, wie sie für Raspberry Pi angeboten wird plus das Debian-Archiv von fhem.de.
Ob ich der Einzige damit bin weiß ich nicht, vermutlich haben's die Anderen bislang nicht als Ursache für ihre Probleme identifiziert.
Zitat von: mimue am 07 Oktober 2014, 20:02:47
(Wer lesen kann ist klar im Vorteil)
Keine Sorge, das hatte ich sehr wohl gelesen. Es ändert nichts an meiner Aussage.
Zitat von: betateilchen am 03 Oktober 2014, 11:05:13
zu 1: Die Behauptung ist falsch. Bei mir läuft fhem auch dann unter dem user "fhem", wenn ich es als root per "/etc/init.d/fhem start" aufrufe.
Ich habe das nochmal überprüft, wenn man als root angemeldet ist, ändert fhem.pl den Benutzer automatisch auf fhem ab ( kann man im Quellcode nachlesen ).
Startet man irgendeinen service unter Debian und seinen Derivaten als Benutzer X mit sudo, läuft der Dienst anschließend unter dem Benutzer X. Das kann weder gewollt noch gesund sein. Hat aber wohl mehr mit Debian als mit FHEM zu tun.