FHEM Forum

Hallo Zusammen,

ich nutze monit, um ein paar Dinge zu überwachen.

Jetzt würde ich gerne auch fhem mit rein packen.
Leider gibt es ja für fhem kein PID File, auf das monit zugreifen kann.

Wie kann man dieses beim Aufruf erstellen lassen?

PS: auf den Prozess Perl track ich gerade schon über den namen, da habe ich aber das Problem, dass ich zwei Perl Prozesse am laufen habe.

Wann wirst Du endlich anfangen, die commandref zu lesen? Darin sind 90% aller von Dir hier im Forum gestellten Grundsatzfragen beantwortet. Auch die Frage nach dem pidfile.

Danke, und ja, ich sollte vorher immer lesen.

Aber meist verstehe ich dummer User die Dinge im Commanref erst gar nicht.
Und Du musst ja nicht helfen!

Im Commanref steht als Global-Attribut pidfilename, allerdings nicht, ob das mit 1 aktiviert wird, ob ich den Pfad angeben muss, etc.
Vielen Dank für eine Unterstützung.

Hi,

ich lese das gerade und habe auch mal geguckt: In der Commanref finde ich auch "pidfilename": "/var/run/fhem.pid".
Also würde ich es mal mit "attr global pidfilename /var/run/fhem.pid" probieren. Denn es heißt ja pidfilename und nicht pidfile, wo man über "1/0" nachdenken könnte.

Gruß

Frank

Es könnte auch heissen PID Fule ein oder aus / enable oder disable / 1 oder 0

Aber ich habe es mitlerweile gefunden, nur wenn ich es aktiviere, fährt fhem nicht mehr hoch

Auszug Monit CONFIGURATION EXAMPLES:
Checking process without pidfile (based on pattern):
check process pager matching "/sbin/dynamic_pager -F /private/var/vm/swapfile"

check process fhem matching "/usr/bin/perl fhem.pl fhem.cfg"

MfG

Zitat von: Mitch am 18 Dezember 2014, 10:52:39
Und Du musst ja nicht helfen!

Stimmt, niemand muss hier helfen. Ich mache das alles hier als Hobby und freiwillig. Aber im Gegensatz zu Dir verliere ich den Unterschied zwischen "jemandem um Hilfe bitten, weil man trotz erkennbarer Bemühungen nicht weiterkommt" und "jemandes Gutmütigkeit ausnützen" nicht aus den Augen.

Aber ich probiers trotzdem nochmal.

Zitat von: Mitch am 18 Dezember 2014, 10:52:39
Aber meist verstehe ich dummer User die Dinge im Commanref erst gar nicht.
...
Im Commanref steht als Global-Attribut pidfilename

Was bitte ist an dem Begriff "filename" unverständlich? Noch dazu, wo doch in der commandref eigentlich unmissverständlich und in Deutsch steht:

pidfilename
Schreibt die PERL Prozess-ID in die angegebene Datei.

Das ist eben kein Schalter, sondern ein Dateiname. Und ob Du einen Pfad angibst oder nicht, ist alleine Dir selbst überlassen.

Zitatnur wenn ich es aktiviere, fährt fhem nicht mehr hoch

Logisch, schau doch mal in Deine Systemkonsole. Ich tippe mit 99,9% Sicherheit darauf, dass fhem schlichtweg keine Schreibrechte hat, die pid-Datei dorthin zu schreiben, wo Du sie gerne haben möchtest. Fehlende Linux Grundlagen, völlig unabhängig von fhem.

---

Attribut pidfilename für Dummies

• Auf der Systemkonsole als root: "mkdir -p /var/run/fhem"
• Auf der Systemkonsole als root: "chown -R fhem:root /var/run/fhem"
• in fhem: attr global pidfilename /var/run/fhem/fhem.pid
• in fhem: save config
• in fhem: shutdown restart

Danach sollte Dein fhem neu starten und Du solltest in der Datei /var/run/fhem/fhem.pid die Prozess-Id finden.

Ich danke euch und besonders Betateilchen.

ZitatAttribut pidfilename für Dummies

Auf der Systemkonsole als root: "mkdir -p /var/run/fhem"
Auf der Systemkonsole als root: "chown -R fhem:root /var/run/fhem"
in fhem: attr global pidfilename /var/run/fhem/fhem.pid
in fhem: save config
in fhem: shutdown restart

Und genau so habe ich es gemacht, da ein paar rudimentäre Linuxkenntnisse vorhanden sind  ;)

Im Moment behelfe ich mir mit monit mit folgenden zwei Definitionen:

check process perl
       matching "perl"
       start program = "/opt/fhem/fhemstart.sh"
       stop program = "/opt/fhem/fhemstop.sh"
       if cpu usage > 95% for 10 cycles then restart

check process fhem
        matching "perl fhem.pl configDB"
        start program = "service fhem start"
        stop program = "service fhem stop"
        if failed host localhost port 7070 with send "knock\n" expect "hello." timeout 20 seconds then restart
        if 5 restarts with 5 cycles then timeout


Der Nachteil ist nur, dass systembedingt von Zeit zu Zeit ein zweiter Perl Prozess startet und Monat dadurch ins "Schleudern" kommt.

Im Prinzip will ich mich gegen den Fehler "absichern"; dass Perl auf 100% CPU läuft und damit hem steht.

Die von mir oben gepostete Anleitung funktioniert einwandfrei. Ich habe sie extra VOR dem Posten auf einem meiner beiden RaspberryPi Entwicklungssysteme getestet.


udo@fhem-dev ~ $ ls -al /var/run/fhem
insgesamt 4
drwxr-xr-x  2 fhem root     60 Dez 18 19:34 .
drwxr-xr-x 16 root root    800 Dez 18 19:43 ..
-rw-r--r--  1 fhem dialout   6 Dez 18 19:34 fhem.pid

udo@fhem-dev ~ $ cat /var/run/fhem/fhem.pid
29517


Was hast Du denn beim attribut tatsächlich eingetragen?

Ich hatte attr global /var/run/fhem.pid eingetragen.

Dies hatte dazu geführt, dass fhem nicht mehr hochkam.
Witzigerweiße lief der Prozess (perl fhem.pl configDB) und ps ax hat ihn angezeigt, allerdings wurde FHEMweb wohl nicht geladen.

Ich habe gestern dann, auch wegen meinen anderen Problemen (http://forum.fhem.de/index.php/topic,30551.0.html) angefangen, die Files aus der Datenbank zurück zu holen:
1. Export aller Files aus der configDB
2. attr global configfile fhem.cfg, save config, shutdown restart (fhem kam ohne Problem mit ein paar Warnungen hoch)
3. attr global configfile configDB, save config, shutdown restart (fhem kam ohne Probleme mit ein paar Warnungen hoch)

Nun war diese Nacht die erste seit Tagen (Wochen), wo fhem nicht abgestürzt ist.
Ob es so bleibt, kann ich noch nicht sagen.

Den Zusammenhang kann ich (asl Laie) nicht nachvollziehen.
Lag es daran, dass ich die Files aus der DB geholt habe?

Ich werde nun weiter auf configDB beleiben und sehen, wie stabil fhem nun läuft.

Zitat von: Mitch am 19 Dezember 2014, 09:13:08
Ich hatte

Code Auswählen Erweitern

attr global /var/run/fhem.pid eingetragen.

Dies hatte dazu geführt, dass fhem nicht mehr hochkam.

Das ist doch völlig logisch. Und Du hast definitiv nicht das gleiche gemacht, was in meiner Anleitung steht! Auch wenn Du felsenfest das Gegenteil behauptest. In meiner Anleitung wird das pidfile nämlich im Verzeichnis /var/run/fhem angelegt und eben nicht in /var/run.

Der Hintergrund ist doch ganz simpel: fhem hat keine Berechtigung, direkt in /var/run zu schreiben. Deshalb wird in meiner Anleitung das Verzeichnis (!) fhem in /var/run angelegt und der Eigentümer auf fhem gesetzt. In dieses Verzeichnis darf fhem jederzeit schreiben. Das pidfile wird ja bei jedem fhem-Start angelegt und bei einem shutdown wieder gelöscht. (siehe commandref!) Deshalb funktioniert das Ganze nur mit einem Verzeichnis, in dem fhem die entsprechenden Rechte hat.

Und dafür, dass Du wieder einmal nicht richtig gelesen hast (in diesem Fall die Anleitung) muss ich mich hier auch noch permanent von Dir vollmaulen lassen. Und erzähl mir bitte nix mehr von Deinen angeblich vorhandenen Linux-Grundlagenkenntnissen.

Ich maule hier niemanden an, ich werde nur von Dir angemault!!
Und das machst Du ja sehr gerne und ständig bei vielen Leuten!!
Keine Art, aber gut, jeder wie er meint.

Und mein fhem läuft als root und hat root Rechte und kann ohne Passwort alles ausführen, also hat es sehrwohl das Recht auf /var/run zuzugreifen.

Aber egal, ich bin durch.

Zitat von: Mitch am 19 Dezember 2014, 09:39:40
Und mein fhem läuft als root und hat root Rechte und kann ohne Passwort alles ausführen

Und auch diese Behauptung könnte man auf Deinem System höchstwahrscheinlich widerlegen.

schön das du das kannst...

Ich will und muss mich hier nicht rechtfertigen!

Aber falls es hier jemand interesseirt, hier der user fhem:
uid=999(fhem) gid=20(dialout) Gruppen=20(dialout),0(root),4(adm),27(sudo),29(audio),124(sambashare)


Zusätzlich in sudoers eingetragen:
fhem    ALL = NOPASSWD:ALL
damit fhem ohne Passwort Befehle ausführen kann (brauche ich für den hci lescan)

Hallo ,

das heißt aber immer noch nicht, das FHEM unter Benutzer root läuft.

Der Benutzer fhem gehört der Gruppe root an und er darf den Befehl "sudo" ohne Angabe eines Kennwortes ausführen. Was das für einen Sinn macht, kann ich nicht verstehen. Ich habe mich noch nie als Benutzer fhem angemeldet, wofür auch. Selbst wenn man sich anmelden wollte geht das nicht:
fhem:x:999:20::/opt/fhem:/bin/false

Alles andere ist Murks.

MfG

Ich melde mich auch nichts als User fhem an, allerdings rufe ich eine Befehl aus einem Modul auf (hcitool lescan), wofür ich root Rechte ohne Passwort benötige.
Deswegen ist der User fhem so eingerichtet.

Wenn das eleganter geht, bitte Info. Danke!

Naja, wenn man nur genau dieses Prog mit root-Rechten erlaubt und sonst nichts, wird schon eleganter ;)

Ja, stimmt. hcitool lescan braucht root-Rechte. Eleganter geht es leider nicht (udev, etc.). Wie hexenmeister schon schrieb nur hcitool in /etc/sudoers eintragen. Und Gruppe root vom Benutzer fhem wechmachen. Nicht immer sofort mit dem Holzhammer draufkloppen.

MfG

Muss jetzt diesen Thread mal hoch holen und hoffe, dass die Gemüter sich wieder abgekühlt haben ;)

Ich habe auch den Ordner für die Pidfile angelegt und es funktioniert. Jedoch wird dieser Ordner beim neustarten des Pi wohl gelöscht bzw ist dann nicht mehr da. Gibt es eine Möglichkeit dies zu verhindern, bzw. weiß jemand woran das liegen könnte?

Quick and Dirty:
Im Init-Script von FHEM den Ordner anlegen lassen und richtige Berechtigung setzen. Dann erst FHEM starten ...

Zitat von: Wernieman am 20 November 2015, 09:59:02
Quick and Dirty:
Im Init-Script von FHEM den Ordner anlegen lassen und richtige Berechtigung setzen. Dann erst FHEM starten ...

So habe ich es auch gemacht. Das init Script (hier nur der wesentliche Teil) sieht bei mir so aus:

case "$1" in
'start')

        echo "Starting fhem..."

# if you need a pid file create the dir on startup cause /var/run is tmpfs
       mkdir -p -m0755 /var/run/fhem
       chown fhem:root /var/run/fhem




Ich habe bei mir es einfach komplett in ein eigenes Script ausgelagert .. welches per "init-Script" aufgerufen wird ;o)

Zitat von: betateilchen am 18 Dezember 2014, 19:45:14

• Auf der Systemkonsole als root: "mkdir -p /var/run/fhem"
• Auf der Systemkonsole als root: "chown -R fhem:root /var/run/fhem"
• in fhem: attr global pidfilename /var/run/fhem/fhem.pid
• in fhem: save config
• in fhem: shutdown restart

Danach sollte Dein fhem neu starten und Du solltest in der Datei /var/run/fhem/fhem.pid die Prozess-Id finden.

Ist es normal dass nach einem reboot das Verzeichnis "/var/run/fhem" verschwindet?

Gruß,
Karsten

Zitat von: DerFrickler am 17 Februar 2017, 20:48:29
Ist es normal dass nach einem reboot das Verzeichnis "/var/run/fhem" verschwindet?

Vermutlich ja ;)

Probiere mal:
ls -l /var/run
Damit weiß du, wohin es wirklich zeigt.
Bei mir:

Zitatlrwxrwxrwx 1 root root 4 Aug 14  2015 /var/run -> /run

und dann:
df

bei mir:

ZitatFilesystem     1K-blocks      Used Available Use% Mounted on
rootfs           7640344   3053648   4268988  42% /
/dev/root        7640344   3053648   4268988  42% /
devtmpfs         1023324         0   1023324   0% /dev
tmpfs             131072      4476    126596   4% /run
tmpfs               5120         0      5120   0% /run/lock
tmpfs             131072         0    131072   0% /run/shm
/dev/sda1      950585404 596170032 306128448  67% /mnt/data
tmpfs            1048576         0   1048576   0% /tmp
/dev/root        7640344   3053648   4268988  42% /var/log.hdd
ramlog-tmpfs      524288      5168    519120   1% /var/log

Wie man sieht, liegt "/var/run" auf einer 'RAM-Disk'  ;)