Code: Alles auswählen
./install >> $LOGFILE 2>>$ERRFILE
Moderator: Co-Administratoren
Code: Alles auswählen
./install >> $LOGFILE 2>>$ERRFILE
Genauso der HB-UNI-Sensor1
Code: Alles auswählen
case "$1" in
""|start)
echo "Installing $ADDON_NAME $ADDON_VERSION" >> $LOGFILE 2>>$ERRFILE
if [ ! -f ${ADDON_DIR}/installed ] || [ ! -f ${FIRMWARE_FILE} ]; then
# check firmware version, generate PATCHVERSION
check_ccu_fw_version
# Check if monit process exists
check_monit
echo "Status Monit: $MONIT" >> $LOGFILE 2>>$ERRFILE
# ! to stop ReGaHss/RFD services below, we need to stop the new service watchdog Monit with firmwares >= 3.45 !
if [ $MONIT -ge 1 ]; then
echo "Stopping monitoring service for ReGaHss and RFD" >> $LOGFILE 2>>$ERRFILE
/usr/bin/monit unmonitor ReGaHss
/usr/bin/monit unmonitor rfd
fi
...
Code: Alles auswählen
Installing hb-uni-sensor1 1.69
Found 3.45.5 - using patchversion 2
Status Monit: 0
Hmm... jetzt bin ich verwirrt... der monit-Prozess läuft bei mir auch zum Installationszeitpunkt noch gar nicht - und wird erst nach Beenden der Addon-Installation gestartet?
Code: Alles auswählen
# Startup the system
...
# now run any rc scripts
::sysinit:/etc/init.d/rcS
# run monit to monitor our important services
null::respawn:/usr/bin/monit -Ic /etc/monitrc
...
Genau so ist es. Die Dinge die man in der /etc/inittab definiert werden in der Tat sequentiell abgearbeitet und somit wird Monit eben erst nach /etc/init.d/rcS gestartet welches wiederum für den Start der init skripte verantwortlich ist. Und durch die Angabe "respawn" wird auch sichergestellt das Monit immer wieder neugestartet wird wenn es plötzlich beendet wird. Somit kann man es eben ausversehen oder mit Absicht nicht mehr "killen", was wiederum im Sinne des Erfinders sein sollte. Und natürlich ist es dadurch so, das Monit erst NACH allen init Skripten gestartet wird und folglich dann auch erst auf irgendwelche "unmonitor" oder "monitor" Befehle hören/reagieren kann.jp112sdl hat geschrieben: ↑01.04.2019, 06:41Wenn die /etc/inittab sequentiell abgearbeitet wird, dann ist eigentlich alles in Ordnung:Es werden erst alle rc-Skripte ausgeführt, also auch S98StartAddons.Code: Alles auswählen
# Startup the system ... # now run any rc scripts ::sysinit:/etc/init.d/rcS # run monit to monitor our important services null::respawn:/usr/bin/monit -Ic /etc/monitrc ...
Erst wenn alle abgearbeitet sind, wird monit gestartet.
So würde ich es interpretieren!?
Du solltest auch noch folgende Dinge bzgl. Addon Installation berücksichtigen:
Code: Alles auswählen
monit stop ReGaHss
Können wir diesen Fall verhindern bzw. in welcher user Konstellation/Aktion kann der auftreten?Führt man das Skript jedoch zur Laufzeit aus, muss monit berücksichtigt werden.
Das stimmt momentan. Aber wie bei vielen Dingen die RaspberryMatic von einer CCU3 unterscheiden ist es auch hier so, das es zumindest geplant ist diese Änderung in einer der nächsten CCU3 Firmwares zu übernehmen. Damit sollten dann die Unterschiede der Addon Installationsroutinen zwischen RM und CCU3 sich wieder erledigt haben.TomMajor hat geschrieben: ↑01.04.2019, 11:15Vielen Dank an @jmaus für die Erläuterungen, dass schafft definitiv weitere Klarheit.
Das Problem mit der RM "init" Zweig Lösung ist dass man trotzdem weiteren code für CCU3 braucht, wenn ich das richtig sehe. Das verkompliziert leider die AddOn Pflege und Testfälle weiter.
Ich wollte diesbzgl. übrigens schon länger einmal vorschlagen das ihr mir einmal versucht detailliert darzulegen was genau ihr da denn bitte genau patcht. Denn dann kann ich sehen bzw. mit eQ3 ggf. darüber diskutieren ob man da nicht eine API schaffen kann mit dem man auf einfacherem Wege andere Komponenten einbinden lassen kann als durch dieses DEVDB/webui.js gepatche. Vielleicht gibt es dann irgendwie ein Verzeichnis oder ähnliches wo ihr eure Anpassungen hinterlegt und dann werden diese automatisch übernommen oder die Gerätedefinitionen die ihr da hinzufügt werden dann via "include" oder ähnlichem hinzugefügt. Dann könnt ihr euch das aufwendige Pflegen von Patchen ja eigentlich sparen. So zumindest die Theorie.
Warum trennt ihr nicht einfach das auspacken+verteilen auf das Verzeichnis des Addons von dem eigentlich Installieren/Patchen der DEVDB, etc.? Bei einer CCU3 könnt ihr einfach beides während der addon installation machen weil addons ja beim runterfahren als letzter schritt installiert wird. Und bei RaspberryMatic dann einfach im "init" Zweig die DEVCB/webui.js patches durchführen und im "start" Zweig des rc Skriptes nur das Addon/Daemon starten (wenn es sowas gibt).