[FHEM-Bug] Startup-Script

[ulli]

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

[betateilchen]

Leider 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?

[ulli]

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

attr global logfile ./log/fhem-%Y.log

attr global nofork 0

und

attr 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.

[betateilchen]

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.

[ulli]

Hmm vermutlich hast du recht, aber wo liegt mein Fehler.
Ich habe in meiner global.cfg folgendes:

#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

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

   include ./config/global.cfg
   attr global modpath .
   include ./config/user_interface.cfg

die Berechtigungen habe ich nicht verändert  nach der neu Installation:

-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

id fhem
uid=999(fhem) gid=20(dialout) Gruppen=20(dialout)

[betateilchen]

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.

Code Auswählen Erweitern


   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.

[ulli]

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

[ulli]

Eigenartig.
FHEM wird nur in einem einzelnen Prozess gestartet wenn die erste Zeile in der fhem.cfg die Definition des Logfiles ist.

[betateilchen]

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.