Wie kann ich FHEM einrichten damit das Programm immer selbstständig gestartet wird?
google...
https://forum.fhem.de/index.php?topic=17279.0 (https://forum.fhem.de/index.php?topic=17279.0)
http://mkleine.de/blog/2014/01/19/raspberry-pi-autostart-von-fhem/ (http://mkleine.de/blog/2014/01/19/raspberry-pi-autostart-von-fhem/)
Wenn du fhem aus dem dpkg-Paket installierst, startet es bereits automatisch.
Die Installation von FHEM erfolgte so.
sudo wget http://fhem.de/fhem-5.7.deb -O /tmp/fhem-5.7.deb && sudo dpkg -i /tmp/fhem-5.7.deb
Früher hatte der Autostart funktioniert.
Seit ich den Raspberry völlig neu installiert habe funktioniert kein Autostart mehr.
Alternativ wenn gar nix hilft nen Cronjob bei restart - sudo service fhem start
Gibt es eigentlich einen Grund, warum so wenige mit init-scripten arbeiten? Das ist doch imho der beste Weg, oder?
Wie geht das mit den init-scripten?
Hast du für die init-scripten eine Anleitung wie ich das aufbauen kann?
http://www.forum-raspberrypi.de/Thread-tutorial-automatisches-starten-von-scripte-programme-autostart (http://www.forum-raspberrypi.de/Thread-tutorial-automatisches-starten-von-scripte-programme-autostart)
Was Goo*** doch so alles findet ::)
Das ist jetzt aber nur eine Seite - Treffer hat es ganz schön viele gegeben.
Ich habe auch sehr viele Seiten gefunden (nach dem Betreff suchen), aber fuer diesen Fall wuerde ich was anderes vorschlagen:
Ausgangslage: /opt/fhem gerettet, Rest des Systems komplett neu aufgesetzt. Damit ist das fhem-init-Skript verlorengegangen, genauso wie Benutzer und Paketinformationen. Vorschlag (ungetestet): /opt/fhem nach /opt/fhem.wichtig umbenennen, danach von http://fhem.de fhem-X.Y.deb installieren, /opt/fhem loeschen, und /opt/fhem.wichtig nach /opt/fhem zurueckschieben. Danach reboot, um zu testen.
Bei anderen Ausgangslagen ist diese Methode Murks(TM)!
außerdem befindet sich im Installationspaket von fhem auch das Script, welches unter /etc/init.d/fhem liegen sollte....
Das muss dannn nur noch wie oben im Link beschrieben, eingetragen werden.
Wenn ich das richtig verstehe, hätte durch die Neuinstallation des Raspy und FHEM eigentlich ein Autostart des FHEM von vorne herein funktionieren sollen, aber tut es nicht.
Und es liegt auch ein Script in dem Verzeichnis /etc/init.d
#!/bin/sh
# description: Start or stop the fhem server
# Added by Alex Peuchert
### BEGIN INIT INFO
# Provides: fhem.pl
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: FHEM server
### END INIT INFO
set -e
cd /opt/fhem
port=7072
if test "$2" != "noaptmark"; then
apt-mark hold fhem > /dev/null
fi
case "$1" in
'start')
echo "Starting fhem..."
# if you need to start hmland for use with
# Homematic, please start the hmland daemon
# like this (please use correct path and port,
# depending on your installation!)
#
# /opt/hmcfgusb/hmland -d -p 1234 -r 0
#
perl fhem.pl fhem.cfg
# if you want to use configDB for configuration,
# use this command to start fhem:
#
# perl fhem.pl configDB
#
# and remove/comment the above line including fhem.cfg
RETVAL=$?
;;
'stop')
echo "Stopping fhem..."
# if you want to stop hmland during fhem stop:
# pkill hmland
pkill -U fhem perl
RETVAL=$?
;;
'status')
cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
if [ "$cnt" -eq "0" ] ; then
echo "fhem is not running"
else
echo "fhem is running"
fi
;;
*)
echo "Usage: $0 { start | stop | status }"
RETVAL=1
;;
esac
exit $RETVAL
Habe die Scripte nochmals mit
sudo update-rc.d fhem defaults
sudo update-rc.d watchdog defaults
eingebunden. Hat aber nichts gebracht. Keines dieser Scripte wird automatisch gestartet nach dem Reboot.
Muss diese genauso manuell starten.
sudo /etc/init.d/fhem start
sudo /etc/init.d/watchdog start
Eines was mich an dem Linux nervt ist das für Linux ein Verzeichnis das gleiche ist wie eine Datei.
Möchte ich das fhem Script in einem Laufwerk ablegen wo sich ein Ordner mit FHEM befindet, jammert Linux im Desktop Modus ob es die Datei ersetzten soll.
Aus manchen werde ich bei Linux nicht schlau.
Was Du noch nachsehen kannst:
- Ist das Startscript auführbar (ls -la /etc/init.d/fhem)
- Den Start in das System eintragen (sudo update-rc.d fhem enable)
Also da habe ich nichts gemerkt das FHEM gestartet wird.
pi@ccs-ht-rasp04:~ $ ls -la /etc/init.d/fhem
-rwxr-xr-x 1 root root 1442 Apr 9 13:12 /etc/init.d/fhem
pi@ccs-ht-rasp04:~ $ sudo update-rc.d fhem enable
pi@ccs-ht-rasp04:~ $
Nach dem Reboot ist genauso Ruhe wie vorher.
ZitatEines was mich an dem Linux nervt ist das für Linux ein Verzeichnis das gleiche ist wie eine Datei.
So ? Ich nutze zwar Linux seit mehr als 25 Jahren, aber da lernt man doch immer noch dazu.
LG
pah
Hi,
versuchs mit
sudo update-rc.d fhem defaults
Ich glaube, bei "enable" musst du die gewünschten runlevel angeben.
Wenns dann noch nicht klappt, mit
runlevel
den aktuellen runlevel ausgeben und in
ls /etc/rcX.d
schauen, ob sich dort ein S**fhem befindet:(die ** bedeuten eine erstmal beliebige Zahl).
lrwxrwxrwx 1 root root 14 Apr 13 17:08 S03fhem -> ../init.d/fhem*
Btw möchte ich vorschlagen, in das INIT-Script von fhem die Zeile
# Should-Start: mysql owhttpd
mit aufzunehmen ( kein Anspruch auf vollständigkeit, da ich nicht weiss, auf welche Systemprozesse fhem möglicherweise noch angewiesen ist), um zu erreichen, dass fhem erst gestartet wird, nachdem die Logdatenbank und owserver verfügbar sind. Falls diese nicht installiert sind (weil sie nicht gebraucht werden) wird der Parameter von update-rc.d ignoriert.
Grüße
Stephan
Hallo Stefan!
Das heist du hast dich mit root angemeldet?
Mit root unter putty bekomme ich Access denied obwohl das Passwort passt.
Mit User pi ist der runlevel 5.
Hast du ein
ls /etc/rc5.d/
gemacht? Bitte poste die Ausgabe.
Dass man sich auf dem pi nicht direkt als root anmelden kann, ist korrekt.
Du kannst mit
sudo su
root werden, falls das notwendig ist ( für die o.g. Aufgabe ist es das nicht).
Grüße
StePHan
ZitatDass man sich auf dem pi nicht direkt als root anmelden kann, ist korrekt.
Ist es nicht. Durch Ändern einer Zeile in der Datei /etc/ssh/sshd_config,
PermitRootLogin yeskann man sich selbstverständlich als root anmelden. Spart viel Zeit.
LG
pah
Hi pah,
um genau zu sein, ist der root-login unter raspian auf "without-password" gestellt, was bedeutet, dass man sich nicht mit einem
Passwort anmelden kann, sondern
nur mit einem ssh-key. Wenn man das auf yes stellt, ist weiterhin sicherzustellen, dass man auch ein root-Passwort vergeben hat, sonst geht's nämlich immer noch nicht.
Und wenn man alternativ PermitEmptyPasswords noch auf yes stellt, muss man nicht mal mehr ein Passwort eingeben ;D<- Achtung, Ironie !! :-)
Da ist dann doch eher zu empfehlen, unter ~/.ssh/ mit "ssh-keygen" einen Schlüssel zu erstellen und zu verwenden. Und wenn man unter ~/.ssh/config noch eine Datei mit
Host dev
HostName dev.example.com
Port 22000
User fooeyanlegt, spart man noch deutlich mehr Tipparbeit, jedes Mal wenn man sich verbindet.
Ich glaube aber, das sprengt nicht nur die Frage, sondern auch den Wissensumfang des TE bei weitem, fachlich wars natürlich inkorrekt von mir.
Zitat von: abc2006 am 13 April 2016, 20:19:40
... root werden, falls das notwendig ist ( für die o.g. Aufgabe ist es das nicht).
Ich hätte schreiben sollen
Zitat von: abc2006 am 13 April 2016, 20:19:40
Dass man sich auf dem pi per Default nicht direkt als root anmelden kann, ist korrekt.
Was mich aber zu der Frage bringt:
ist /etc/init.d/fhem beim TE jetzt nach /etc/rc5.d/ verlinkt?
Grüße
Stephan
Habe hier einmal ein paar Printscreens des PI's.
Wie muss ich eine korrekte Verlinkung dann einrichten um bei einem Reboot des PI's die benötigten Programme zu starten.
Hi,
also die Datei ist schonmal da, wo sie sein soll (im Verzeichnis rc5.d). Ob die Berechtigungen richtig gesetzt sind, kann man auf den Bildern leider nicht sehen.
Deshalb kann ich nur noch einmal vorschlagen:
Zitat von: abc2006 am 13 April 2016, 20:19:40
Hast du ein
ls -alh] /etc/rc5.d/
gemacht? Bitte poste die Ausgabe.
Du kannst dann auch mal probieren, was
sudo /etc/init.d/fhem status
sudo /etc/init.d/fhem start für Ausgaben liefern.
Grüße
Stephan
ls -alh /etc/rc5.d/ ergibt auf den Gerät 1 folgendes:
pi@ccs-ht-rasp01:~ $ ls -alh /etc/rc5.d/
insgesamt 12K
drwxr-xr-x 2 root root 4,0K Mär 30 09:58 .
drwxr-xr-x 110 root root 4,0K Apr 15 08:10 ..
-rw-r--r-- 1 root root 677 Apr 6 2015 README
lrwxrwxrwx 1 root root 18 Mär 18 09:07 S01bootlogs -> ../init.d/bootlogs
lrwxrwxrwx 1 root root 16 Mär 18 09:15 S01dhcpcd -> ../init.d/dhcpcd
lrwxrwxrwx 1 root root 14 Mär 30 09:30 S01fhem -> ../init.d/fhem
lrwxrwxrwx 1 root root 14 Mär 18 09:07 S01motd -> ../init.d/motd
lrwxrwxrwx 1 root root 14 Mär 30 09:05 S01nmbd -> ../init.d/nmbd
lrwxrwxrwx 1 root root 17 Mär 18 09:08 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root 21 Mär 30 09:05 S01samba-ad-dc -> ../init.d/samba-ad-dc
lrwxrwxrwx 1 root root 22 Mär 18 09:10 S01triggerhappy -> ../init.d/triggerhappy
lrwxrwxrwx 1 root root 22 Mär 30 09:58 S01wd_keepalive -> ../init.d/wd_keepalive
lrwxrwxrwx 1 root root 14 Mär 30 08:59 S01xrdp -> ../init.d/xrdp
lrwxrwxrwx 1 root root 14 Mär 18 09:08 S02cron -> ../init.d/cron
lrwxrwxrwx 1 root root 14 Mär 18 09:13 S02dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 24 Mär 18 09:15 S02dphys-swapfile -> ../init.d/dphys-swapfile
lrwxrwxrwx 1 root root 13 Mär 18 09:14 S02ntp -> ../init.d/ntp
lrwxrwxrwx 1 root root 15 Mär 18 09:24 S02rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root 14 Mär 30 09:05 S02smbd -> ../init.d/smbd
lrwxrwxrwx 1 root root 13 Mär 18 09:58 S02ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 22 Mär 18 09:14 S03avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 19 Mär 18 09:14 S03bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 17 Mär 18 09:22 S03lightdm -> ../init.d/lightdm
lrwxrwxrwx 1 root root 18 Mär 18 09:14 S04plymouth -> ../init.d/plymouth
lrwxrwxrwx 1 root root 18 Mär 18 09:14 S04rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root 19 Mär 18 09:14 S04rmnologin -> ../init.d/rmnologin
lrwxrwxrwx 1 root root 18 Mär 30 09:58 S04watchdog -> ../init.d/watchdog
pi@ccs-ht-rasp01:~ $
ls -alh /etc/rc5.d/ ergibt auf den Gerät 2 folgendes:
pi@ccs-ht-rasp02:~ $ ls -alh /etc/rc5.d/
insgesamt 12K
drwxr-xr-x 2 root root 4,0K Dez 21 18:23 .
drwxr-xr-x 114 root root 4,0K Apr 16 18:28 ..
-rw-r--r-- 1 root root 677 Apr 6 2015 README
lrwxrwxrwx 1 root root 18 Nov 21 19:51 S01bootlogs -> ../init.d/bootlogs
lrwxrwxrwx 1 root root 16 Nov 21 21:34 S01dhcpcd -> ../init.d/dhcpcd
lrwxrwxrwx 1 root root 14 Dez 20 16:40 S01fhem -> ../init.d/fhem
lrwxrwxrwx 1 root root 14 Nov 21 19:51 S01motd -> ../init.d/motd
lrwxrwxrwx 1 root root 14 Dez 20 16:19 S01nmbd -> ../init.d/nmbd
lrwxrwxrwx 1 root root 17 Nov 21 19:52 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root 21 Dez 20 16:19 S01samba-ad-dc -> ../init.d/samba-ad-dc
lrwxrwxrwx 1 root root 22 Nov 21 21:32 S01triggerhappy -> ../init.d/triggerhappy
lrwxrwxrwx 1 root root 22 Dez 21 16:49 S01wd_keepalive -> ../init.d/wd_keepalive
lrwxrwxrwx 1 root root 14 Dez 21 17:39 S01xrdp -> ../init.d/xrdp
lrwxrwxrwx 1 root root 17 Dez 20 17:00 S02apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 14 Dez 20 17:00 S03cron -> ../init.d/cron
lrwxrwxrwx 1 root root 14 Dez 20 17:00 S03dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 13 Dez 20 17:00 S03ntp -> ../init.d/ntp
lrwxrwxrwx 1 root root 20 Dez 21 16:46 S03nut-server -> ../init.d/nut-server
lrwxrwxrwx 1 root root 15 Dez 20 17:00 S03rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root 14 Dez 20 17:00 S03smbd -> ../init.d/smbd
lrwxrwxrwx 1 root root 13 Dez 20 17:00 S03ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 22 Dez 20 17:00 S04avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 17 Dez 20 17:00 S04lightdm -> ../init.d/lightdm
lrwxrwxrwx 1 root root 20 Dez 21 18:23 S04nut-client -> ../init.d/nut-client
lrwxrwxrwx 1 root root 18 Dez 20 17:00 S05plymouth -> ../init.d/plymouth
lrwxrwxrwx 1 root root 18 Dez 20 17:00 S05rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root 19 Dez 20 17:00 S05rmnologin -> ../init.d/rmnologin
lrwxrwxrwx 1 root root 18 Dez 21 16:49 S05watchdog -> ../init.d/watchdog
pi@ccs-ht-rasp02:~ $
Und sudo /etc/init.d/fhem status
sudo /etc/init.d/fhem start liefert bei beiden das gleiche.
login as: pi
pi@192.168.17.182's password:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Apr 27 15:29:24 2016
pi@ccs-ht-rasp02:~ $ sudo /etc/init.d/fhem status
fhem is not running
pi@ccs-ht-rasp02:~ $ sudo /etc/init.d/fhem start
Starting fhem...
pi@ccs-ht-rasp02:~ $
Zitat:
PermitRootLogin yes
kann man sich selbstverständlich als root anmelden. Spart viel Zeit.
...Und am besten noch das voreingestellte Passwort nicht ändern und einen Zugriff aus dem Internet erlauben. Zero day lässt grüßen.
:-)
Mal im Ernst: Ich denke, dass diese Voreinstellung von denjenigen aus dem Entwicklungsteam schon mit Bedacht so gewählt wurde, um ein Mindestmaß an Sicherheit zu gewährleisten.... Bequem ist leider auch immer mal unsicher. Solche Tipps sind also mit Vorsicht zu genießen.
Jessy hat doch systemd?
sudo systemctl enable fhem
bzw. zum nachgucken:
sudo systemctl is-enabled fhem
Und noch einige Bemerkungen:
- Das unter Unix alle eine Datei, ist doch Absicht? Leider ist dieses bei Linux nicht mehr immer der Fall ...
- Direkte Einloggen als root ..... wer mal Logfileanalysen betrieb hat weiß, das in 80% der Fällen bei einem "Einbruch" eines Unix (Linux) Systems auch probiert wird, sich als root einzuloggen.
Ja wenn das auch funktionieren würde.
Seit dem Jessy Update auf die aktuelle Vorversion funktionieren die Autostarts nicht mehr.
pi@ccs-ht-rasp04:~ $ sudo systemctl is-enabled fhem
Failed to get unit file state for fhem.service: No such file or directory
pi@ccs-ht-rasp04:~ $ sudo systemctl enable fhem
Synchronizing state for fhem.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d fhem defaults
Executing /usr/sbin/update-rc.d fhem enable
pi@ccs-ht-rasp04:~ $
ZitatUnd am besten noch das voreingestellte Passwort nicht ändern und einen Zugriff aus dem Internet erlauben
Na, ich kann nur jedem raten, die Ratschläge dieses Könners nicht zu befolgen.
LG
pah
Ich hoffe Du hast sein
Zitat<- Achtung, Ironie !! :-)
gelesen?
Mitlerweile wird, aus gutem grunde, der ssh durch root im Standart deaktiviert ....
Und wie lässt sich ein Autostart trotzdem realisieren und die Sicherheit trotzdem beizubehalten?
Hast Du, nachdem Du "« Antwort #24 am: Heute um 15:20:55 »" den "sudo systemctl enable fhem" mal einen neustart probiert?
Hat jetzt nichts mit der "root" Diskussion zu tuhen
ZitatHast Du, nachdem Du "« Antwort #24 am: Heute um 15:20:55 »" den "sudo systemctl enable fhem" mal einen neustart probiert?
Einen Reboot hatte ich danach mehrfach ausgeführt, aber ohne Erfolg mit einem Autostart.
was sagt den ein "sudo systemctrl status"eines anderen "Dienstes"? bzw. ein "/etc/init.d/einandererdienst status"
Das ist leider die Antwort:
pi@ccs-ht-rasp04:~ $ sudo systemctrl /etc/init.d/fhem status
sudo: systemctrl: Kommando nicht gefunden
pi@ccs-ht-rasp04:~ $
Wo ist diese Programm zu finden, damit ich die Status Abfrage machen kann?
das sollte bei Jessy dabei sein ... hast Du ein Upgrade oder eine Neuinstallation gemacht?
Sicherheitshalber:
cat /etc/debian_version
Jessie wurde neu installiert.
Version vom 18.03.2016
pi@ccs-ht-rasp04:~ $ cat /etc/debian_version
8.0
pi@ccs-ht-rasp04:~ $
Ein weiters Problem welches nach einem Neustart auftritt ist der Zugriff auf die Schnittstellen.
Diese muss ich ebenfalls nach einem Neustart wieder freigeben.
pi@ccs-ht-rasp04:~ $ sudo chmod g+r /dev/ttyAMA0
pi@ccs-ht-rasp04:~ $ sudo chown :tty /dev/ttyUSB0
pi@ccs-ht-rasp04:~ $ sudo /etc/init.d/fhem start
Starting fhem...
pi@ccs-ht-rasp04:~ $
Hallo Chris,
mit den USB-Schnittstellen habe ich bei einem "shutdown restart" gelegentlich auch Probleme. Dann werden die CULs als "disconnected" angezeigt und lassen sich auch mit "set CUL_O0 reopen" nicht mehr ins Leben rufen.
Wenn der Cubie per reboot gestartet wird, tritt der Effekt nicht auf.
Zitat:
Code: [Auswählen]
pi@ccs-ht-rasp04:~ $ sudo chmod g+r /dev/ttyAMA0
pi@ccs-ht-rasp04:~ $ sudo chown :tty /dev/ttyUSB0
Eigentlich müssten diese oder gleichartige Befehle bei fhem in den shutdown - Prozess von fhem eingebaut werden.
Elektrolurch
@Elektrolurch: udev Regeln greifen nicht?
Zitat:
@Elektrolurch: udev Regeln greifen nicht?
Kannst Du mir erklären, um was für ein "Ding" es sich dabei handelt?
Wenn ich z.B. nach einem update "shutdown restart" mache, so ist ca. in 30 % der Fälle danach sowohl die USB-Schnittstellen, als auch telnet Port 7072 nicht zugreifbar. Letzteres steht im log, ersteres sieht man erst, wenn man den Status der CULs aufruft. Die sind dann "disconnected".
DA das ganze nur sporradisch auftritt, scheitn es ein timing - Problem zu sein, d.h. die Freigabe der USB-Schnittstellen ist noch nicht abgeschlossen, aber fhem startet schon neu.
Elektrolurch
Zitat von: Elektrolurch am 30 April 2016, 20:22:33
Kannst Du mir erklären, um was für ein "Ding" es sich dabei handelt?
udev ist ein daemon, der sich u.a. um die Berechtigungen der Geräte unterhalb von /dev kümmert. Im Ubuntu Wiki ist das recht gut erklärt:
https://wiki.ubuntuusers.de/udev/ (https://wiki.ubuntuusers.de/udev/)
Wenn sich Berechtigungen von USB Geräten aus unerfindlichen Gründen ändern, dann fällt mir zuerst dieser Mechnismus ein.