Hallo,
ich habe einen schweren Fehler gefunden.
Auf meinem Beaglebone habe ich das Debian Paket fhem 5.5 installiert. Damit wird das Startscript unter /etc/init.d/fhem erstellt.
Leider verursacht das fhem Script das alle Services, welche danach gestartet werden sollen blockiert werden, da fhem nicht in einem separaten Prozess gestartet wird.
Daher ist meine Lösung im Startscript unter "start" ein "&" einzufügen.
d.h. fhem wie folgt zu starten
perl fhem.pl fhem.cfg &
Ich verstehe aber nicht warum nur ich das Problem habe.....
Kannst du das in die SVN aufnehmen, hast du eine Erklärung?
Grüße
Zitat von: ulli am 02 Januar 2014, 20:22:40Leider verursacht das fhem Script das alle Services, welche danach gestartet werden sollen blockiert werden, da fhem nicht in einem separaten Prozess gestartet wird.
Diese Behauptung halte ich für völligen Unsinn. Das Startskript funktioniert einwandfrei, vorausgesetzt, die fhem.cfg ist fehlerfrei.
Du hast nicht zufällig das globale Attribut nofork in Deiner fhem.cfg stehen?
Ich dachte Anfangs du hast recht, da ich die Demo fhem.cfg genutzt habe und dort als Logfile "-" eingetragen ist.
Aber jetzt habe ich nochmal alles durchprobiert.
Habe als Logfile
Zitatattr global logfile ./log/fhem-%Y.log
Zitatattr global nofork 0
und
Zitatattr global nofork 1
ausprobiert, aber immer bleibt der BBB scheinbar hängen.
Ich komme auf das FHEM Webinterface und der SSH Daemon ist nicht initialisiert.
Wenn ich FHEM mit "shutdown" beende oder komischerweise es mit "shutdown restart" neu starte funktioniert der SSH Zugang wieder.
Das nofork sollte am besten gar nicht vorhanden sein.
Und nochmal: ich würde darauf wetten, dass es nicht am Startskript liegt.
Hast Du mal mit einer "leeren" fhem.cfg getestet? Ich glaube nach wie vor, dass Dein Problem aus der fhem.cfg kommt.
Du bist auch nicht der erste, der hier im Forum darüber schreibt, dass das skript fehlerhaft sei, aber Du wärst definitiv der erste, der mit seiner Behauptung recht hätte. Bisher lag die Ursache jedenfalls immer irgendwo anderes, noch nie am Startskript selbst.
Wenn es nicht das nofork ist, sind Berechtigungsprobleme eine beliebte Fehlerquelle. Viel zu viele Leute basteln an den Rechtevergaben rum, ohne zu wissen (im Sinne von verstehen), was sie dabei tun. Und das alles nur, weil sie irgendwo im Internet gelesen haben, dass man das tun müsste.
Hmm vermutlich hast du recht, aber wo liegt mein Fehler.
Ich habe in meiner global.cfg folgendes:
Zitat
#cleanup Logfile
{system('echo "" > ./log/fhem-2014.log')}
####### Global Configuration #######
attr global autoload_undefined_devices 0
attr global logfile ./log/fhem-%Y.log
attr global modpath .
attr global motd Ulli´s Haussteuerung
attr global title Ulli`s Haussteuerung
attr global statefile ./log/fhem.save
attr global backup_before_update 0
attr global motd none
attr global sendStatistics never
attr global updateInBackground 1
attr global userattr devStateIcon devStateStyle icon presence presence_map sortby structexclude webCmd
attr global verbose 3
attr global room 99_System
in der user_interface.cfg
Zitat
define WEB FHEMWEB 8083 global
attr WEB stylesheetPrefix dark
attr WEB room 99_System
define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen
attr WEBphone room 99_System
define Logfile FileLog ./log/fhem-%Y.log fakelog
attr Logfile room 98_Logfiles
und in der fhem.cfg folgendes
Zitat
include ./config/global.cfg
attr global modpath .
include ./config/user_interface.cfg
die Berechtigungen habe ich nicht verändert nach der neu Installation:
Zitat
-rw-r--r-- 1 fhem dialout 59100 Jan 5 2028 CHANGED
drwxr-xr-x 2 fhem root 4096 Jan 2 21:11 config
drwxr-xr-x 26 fhem root 12288 Jan 5 2028 contrib
drwxr-xr-x 2 fhem root 4096 Jan 5 2028 demolog
drwxr-xr-x 4 fhem root 4096 Jan 5 2028 docs
drwxr-xr-x 4 fhem root 24576 Jan 2 21:15 FHEM
-rw-r--r-- 1 fhem root 16161 Jan 2 21:53 fhem.cfg
-rw-r--r-- 1 fhem root 5123 Okt 6 13:59 fhem.cfg.demo
-rwxr-xr-x 1 fhem root 95588 Jan 5 2028 fhem.pl
drwxr-xr-x 2 fhem root 4096 Jan 2 21:16 log
-rw-r--r-- 1 fhem root 761 Okt 6 13:59 README_DEMO.txt
-rw-r--r-- 1 fhem dialout 0 Jan 2 19:58 test.log
drwxr-xr-x 2 fhem dialout 4096 Jan 5 2028 unused
drwxr-xr-x 8 fhem root 4096 Jan 5 2028 www
Zitat
id fhem
uid=999(fhem) gid=20(dialout) Gruppen=20(dialout)
Wie schon gesagt: Teste mit EINER quasi leeren Konfigurationsdatei (fhem.cfg) und versuche, durch Schritt-für-Schritt-Evaluierung das Problem einzukreisen.
Was mir spontan auffällt:
1. den Systemaufruf am Anfang der global.cfg würde ich weglassen. Zumal der Befehl selbst schon keinen Sinn macht.
2. zum anderen ist Dir wohl noch nicht aufgefallen, dass Du bestimmte Einträge in Deiner Konfiguration im Laufe der Abarbeitung selbst wieder überschreibst.
attr global motd Ulli´s Haussteuerung
...
attr global motd none
3. den modpath setzt Du auch zweimal.
usw. usw.
Alles ein bisschen sehr wenig durchstrukturiert und ziemlich unlogisch.
Das komische ist das es mit der aus den SVN gezogenen demo fhem.cfg auch nicht geht wenn ich ein Logfile angebe.
Guter Punkt mit dem attr motd und modpath! Hab ich korrigiert.
Den Systemaufruf habe ich drin, dass ich nach jedem Neustart von FHEM ein leeres Logfile habe. - funktioniert gut
Ich bekomme es nur mit Anpassung de Startscriptes hin...Finde das Problem nicht
Eigenartig.
FHEM wird nur in einem einzelnen Prozess gestartet wenn die erste Zeile in der fhem.cfg die Definition des Logfiles ist.
Wenn Du das mit dem leeren Logfile wirklich unbedingt haben willst, dann lösche es einfach aus dem Startskript und nicht aus der fhem.cfg.