Raspberry & eibd (Jessie) via IP Zugriff installieren

[stan21k]

Guten Morgen,

ja das liegt sicher an Berechtigungen. Das Installer-Script versucht auch einen user "eibd" anzulegen um mit diesem dann den eibd automatisch zu starten. Schau mal nach ob es den gibt.
"cat /etc/passwd | cut -d: -f1" listet alle am System verfügbaren user auf.

Grüße

PS: der User "eibd" wird angelegt um Zugriff auf "/dev/ttyAMA0" (Serielle Schnittstelle) zu bekommen. Da du IP nutzen möchtest kannst du im init-Script auch den "EIBD_USER=eibd" durch "EIBD_USER=pi" ersetzen.

[EPIX]

der User eibd ist in der Auflistung vorhanden - ich habe aber im eibd script EIBD_USER=pi geändert...
neu gestartet, aber trotzdem

pi@raspberrypi:~ $ whoami
pi
pi@raspberrypi:~ $ /etc/init.d/eibd restart
[....] Restarting eibd (via systemctl): eibd.serviceFailed to restart eibd.service: Access denied
failed!

das startscript in init.d hat Gruppe/Eigentümer/Rechte root/root/755
eibd hat staff/root/755

mit $ sudo /etc/init.d/eibd restart kann man den eibd starten und er scheint auch mit ps ax in der Liste auf....

da muss man da die Rechte / owner der scripte / eibd ändern, oder? (obwohl ja 755 ausreichen sollte)

[stan21k]

Alle deine Versuche sind mit "restart" was passiert denn bei nem "start"?

Grundsätzlich ist 755 völlig ausreichend.
Das Init-Script sollte so bleiben da es durch root gestartet wird und intern den eibd als "anderen user" startet.
staff/root von eibd kann man in root/root ändern.

Vielleicht sind die runlevels noch nicht richtig getzt, führe folgenden Befehl als root noch aus: "update-rc.d eibd defaults"

Parallel würde ich dir mein Script schicken. In dem hier sind ein paar Dinge drin die ich persönlich nicht notwendig finde.

[EPIX]

gerne nehme ich dein script... ;-)

woher kennst du dich eigentlich so gut mit eibd aus?

update-rc.d eibd defaults
insserv: fopen(.depend.stop): Permission denied
Failed to execute operation: Access denied
pi@raspberrypi:~ $ sudo update-rc.d eibd defaults
pi@raspberrypi:~ $ /etc/init.d/eibd restart
[....] Restarting eibd (via systemctl): eibd.serviceFailed to restart eibd.service: Access denied
failed!
pi@raspberrypi:~ $ ^C
pi@raspberrypi:~ $ /etc/init.d/eibd start
[....] Starting eibd (via systemctl): eibd.serviceFailed to start eibd.service: Access denied
failed!
pi@raspberrypi:~ $

[stan21k]

Ich kenne mich mit eibd nicht gut aus. Ich arbeite täglich mit Linux und entwickle Software, daher die ganzen Tipps ...

update-rc war erfolgreich, was passiert nun nach einem reboot?

[EPIX]

ich verwende dein script - nach einem Reboot startet der eibd sich nicht selbst.... (eingeloggt bin ich als pi)

/var/run/eibd.pid ist vorhanden (mit dem Zeitstempel des reboots), aber:

root@raspberrypi:/home/pi# ps -ef | grep eibd
root 1098 1007 0 17:19 pts/0 00:00:00 grep eibd
root@raspberrypi:/home/pi#

es scheint als ob eibd gestartet wird, aber dann abschmiert

[Knaller]

Moin

Heute hab ich eine PI-2 mit dem neusten System hoch gefahren und eibd installiert.
Auch bei mir muss ich den EIBD händisch starten damit es funktioniert.

Hab Ihr eine Lösung gefunden ?

Gruß Herbert

[Talkredius]

Meinen Dank an stan21k

Mein System PI 3, Debian Jessie
Mein Problem : Segmentation fault

Meine Lösung : die von stan21K empfohlenen Optionen für ./configure
Anscheinend war es notwendig pthsem und bcusdk statisch zu compilieren

[Talkredius]

Moin

Heute hab ich eine PI-2 mit dem neusten System hoch gefahren und eibd installiert.
Auch bei mir muss ich den EIBD händisch starten damit es funktioniert.

Hab Ihr eine Lösung gefunden ?

Gruß Herbert

Habe heute einen workaround gefunden basieren auf dieser Lösung :

http://michlstechblog.info/blog/knxe...cript-for-eibd

habe ich in /etc/init.d/eibd ein sleep 15 eingefügt :

.....................
do_reload() {
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
return 0
}

sleep 15

case "$1" in
start)
do_start
;;
stop)
...............

dann als root

update-rc.d eibd remove && insserv eibd && update-rc.d eibd defaults

ausgeführt und nach dem Reboot ist eibd gelaufen.

Denkbar sind auch geringere Zeiten, das hängt vermutlich von dem jeweilgen Netzwerk ab.
Das ist keine saubere Lösung, da in anderen Netzwerk Konstellation eventuell andere sleep Zeiten erforderlich sind.