shutdown restart funktioniert nicht

kadettilac89 · 14 Januar 2018, 19:35:09

Gerne. Die einzige Einschränkung wie im anderen Post geschrieben. Shutdown aus fhem funktioniert nicht mehr.

Interessehalber. Welche Hardware und welches Image? Stretch? Cubitruck oder?

Tommy82 · 14 Januar 2018, 19:40:55

Na das reine shutdown habe ich eh glaub ich nie genutzt bis jetzt.

Ist ein Cubietruck mit diesem Image https://www.armbian.com/cubietruck/
aktuelle nutze ich die Version

Code Auswählen

Linux cubietruck 4.13.16-sunxi #20 SMP Fri Nov 24 19:50:07 CET 2017 armv7l GNU/Linux

throbin · 18 Januar 2018, 22:41:11

Hi, ich habe dasselbe Problem auf einem Pi 3 mit dem neu aufgespieltem Stretch Lite:

Code Auswählen


pi@raspberrypi:~ $ sudo systemctl status fhem.service
● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Thu 2018-01-18 22:34:09 CET; 1min 22s ago
  Process: 624 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
 Main PID: 625 (code=exited, status=0/SUCCESS)

Jan 18 22:33:49 raspberrypi systemd[1]: Starting FHEM Home Automation...
Jan 18 22:33:49 raspberrypi systemd[1]: Started FHEM Home Automation.

Die fhem.service sieh so aus:

Code Auswählen



# $Id: fhem.service 15784 2018-01-05 11:29:16Z betateilchen $

[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
# uncomment next two lines if auto-restart desired

# please select restart options according your needs
# Restart=on-abnormal # uncomment for crash and watchdog event recovery only (keeps shutdown working)
 Restart=always # alternativly uncomment this line for recover always
# RestartSec=5 # uncomment always if restart required!

[Install]
WantedBy=multi-user.target

kadettilac89 · 19 Januar 2018, 10:36:51

Zitat von: throbin am 18 Januar 2018, 22:41:11
Hi, ich habe dasselbe Problem auf einem Pi 3 mit dem neu aufgespieltem Stretch Lite:

Wie soll dein Post interpretiert werden?
1) Ich habe auch einen Rasp3 und auch Stretch und kann das Verhalten auch bestätigen? OK, angekommen
2) Ich habe nicht alles gemacht was zu tun wäre, und brauche Hilfe? Welches Verhalten ist gewünscht bzw. mit welchem kannst du leben?

Wenn 1:
Wie Udo schrieb, bei ihm funktioniert alles, manche Hardware-Softwarekombi haben (aktuell?) ein anderes Verhalten ...

Wenn 2:

Code Auswählen


# uncomment next two lines if auto-restart desired

# please select restart options according your needs
# Restart=on-abnormal # uncomment for crash and watchdog event recovery only (keeps shutdown working)
 Restart=always # alternativly uncomment this line for recover always
# RestartSec=5 # uncomment always if restart required!

--> Kommentiere 2 Zeilen aus (s. Kommentar im Script) dann hast du zumindest das Verhalten, welches ich in meinem Post zu erklären versuchte.

Restart=always
RestartSec = 5
--> shutdown-restart in fhem funktioniert, service start / stop funktioniert, shutdown in fhem funktioniert nicht (da restart vom daemon)

Alternativ müsste es mit dem alten init.d Script weiterhin funktionierten. Für den Fall, dass du auch Shutdown-Funktion aus Fhem benötigst.

throbin · 19 Januar 2018, 16:32:14

Ok, danke. Das mit der zweiten Zeile hat mir gefehlt. Ich probiere es aus. Ich wollte nur mitteilen, dass es vermutlich einige Installationen betrifft.
Die Shutdown-Restart per Webinterface ist zwar bequem, aber nicht unbedingt notwendig. Wenn man aber das Problem hat (nach Umzug von Jessie > Stretch), dann sucht man eine Weile (vor allem wenn man nicht tagtäglich mit Linux unterwegs ist) und vermutet eher andere Probleme, wie "Permissions" oder Initialisierungsprobleme mit USB etc. Ich bin aber nur durch Zufall auf diesen Thread gestoßen.

gent · 23 Januar 2018, 19:54:35

Ist ja schön, dass Udo(betateilchen) das einfach mal so ändert und das nicht vorher ankündigt bzw. die user darüber informiert. Ich habe gerade eine neue Testinstallation nach offizieller Anleitung gemacht. Glücklicherweise konnte ich mich irgendwie an diesen Eintrag erinnern.

Stellt euch mal vor, nach einem Windows Update geht kein Neustart mehr. Dann sucht ihr im Netz nach Lösungen und auf irgendeiner Microsoft-Seite steht dann: Mach ein paar Änderungen in einer Datei, dann geht alles (fast) wieder. Aber ihr müsst dann beim Neustart eben noch dies und dies berücksichtigen. Die alten Verfahren gehen nicht mehr.

Jetzt nehmen wir mal den normalen User, der fhem nach Anleitung installiert, sich mit dem wiki etc. beschäftigt und bei dem nach dem ersten update und shutdown restart nichts mehr geht...

Das ist einfach nur unprofessionell und deshalb sollten solche Änderungen entweder so gemacht werden, dass jeder darauf hingewiesen wird oder man sollte es einfach lassen, in grundlegende start- oder service-scripte einzugreifen.

Meine Meinung. Gerne diskutieren.

Viele Grüße, Holger

betateilchen · 23 Januar 2018, 20:56:08

Ein solch unsachlicher Beitrag ist es nicht wert, diskutiert zu werden.

gent · 25 Januar 2018, 18:29:21

Was ist daran denn unsachlich? Der Beitrag enthält meine Meinung zu dem diskutierten Thema. Das habe ich genau so geschrieben. Es ist mir nach wie vor unklar, warum das Verhalten einfach so geändert werden kann, ohne das die User darüber informiert werden. Was wäre denn so schlimm daran, wenn man diese Änderung auch im Wiki oder auf der Installationsseite kommuniziert? Nach wie vor kommt nach einem update im log, dass man danach ein shutdown restart machen soll. Könnte man denn nicht auch in diesem Schritt darauf hinweisen, dass das nur dann geht, wenn bestimmte Voraussetzungen erfüllt sind? Möchtest Du vielleicht dazu etwas sagen oder einfach weiterhin die Meinung von anderen als "unsachlich" herabwürdigen?

ujaudio · 25 Januar 2018, 19:39:34

Ich nutze mal diesen Faden, weil der Titel (fast) passt, wenn das schlecht ist, bitte kurz meckern, dann lerne ich daraus.

Ich habe:
* Das Attribut menueEntries in WEB definiert als: Neustart,cmd=shutdown+restart --> funktioniert
* Tippe ich shutdown+restart in die FHEM Kommandozeile im Web-Frontend ein --> funktioniert
* Ich habe ein notify wie folgt definiert: FHEMReboot.on set FHEMReboot off; shutdown+restart --> funktioniert nicht

Wenn das dummy FHEMReboot auf on geht, wird das notify auch ordentlich getriggert, es setzt auch das dummy wie gewünscht zurück, aber es gibt kein Reboot von FHEM, was man im Logfile sehen kann.
Was habe ich übersehen?

KernSani · 25 Januar 2018, 19:43:21

Wenn du ein ,,list" des notifies
Liefern würdest, wäre es einfacher, ich vermute aber mal es fehlt ein zweiter Semikolon.
Und: eigentlich passt es nicht hier rein

ujaudio · 25 Januar 2018, 19:45:57

Soll ich oder nicht nun das list hier beitragen??!?

Code Auswählen

Internals:
   DEF        FHEMReboot.on set FHEMReboot off; shutdown+restart
   NAME       FHEMRebootCmd
   NR         1243
   NTFY_ORDER 50-FHEMRebootCmd
   REGEXP     FHEMReboot.on
   STATE      2018-01-25 19:38:22
   TYPE       notify
   READINGS:
     2018-01-25 19:37:55   state           active
Attributes:
   room       Technikraum,Zentrale

In fhem.cfg sind 2 Semikolons (wie es ja sein soll)

EDIT: gelöst! Verbose 4 im notify eingestellt, Logfile gelesen, "Unknown command shutdown+restart", commandref gelesen, das Plus durch ein Leerzeichen ersetzt, funktioniert.
Leider habe ich nicht gefunden, wann ein + sein muss (habe ich so, seit ich vor Jahren mit FHEM begann) und wann das Leerzeichen hingehört.