Anfängerfrage - Edomi herunterfahren

[saegefisch]

Klasse André, das war schön einfach und funktioniert perfekt.
Ich wünschte ich würde den tieferen Unterschied zu Michaels Link verstehen (warum 2 Lösungen, die so unterschiedlich aussehen); aber das liegt mir wohl bereits für mich schon zu tief in den Linux-Abgründen. So geht es - das reicht mir.

Ich möchte für nachfolgenden Leser noch ergänzen: Danach noch ausführbar machen: chmod 777 /usr/local/edomi/main/stop.sh

[uzi10]

Edomi auf CentOS7 kommt doch schon mit einem systemd Startskript:

/etc/systemd/system/edomi.service

[Unit]
Description=EDOMI
Before=getty@tty1.service getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service
After=httpd.service mysqld.service network.target
Conflicts=getty@tty1.service getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service
[Service]
Type=simple
ExecStart=/bin/sh /usr/local/edomi/main/start.sh
[B][COLOR=#e74c3c]ExecStop=/bin/sh /usr/local/edomi/main/stop.sh[/COLOR][/B]
TimeoutStartSec=0
StandardInput=tty-force
StandardOutput=inherit
StandardError=inherit
[Install]
WantedBy=default.target

Ich habe darin die ExecStop Zeile (rot) ergänzt)

und das stop.sh Skript sieht dann gemäß der CentOS6.5 Lösung von Michael so aus:

#!/bin/sh

edomipid() {[INDENT]echo `ps -ef | grep "/usr/local/edomi/main/proc/[p]roc_main.php" | awk '{print $2}'`[/INDENT]
}

wait=10
echo -n $"Shutting down Edomi: "
/usr/bin/php /usr/local/edomi/main/control.php quit
rm -f /var/lock/subsys/edomi
sleep 1
PID=$(edomipid)
s=0

if [ "x$PID" != x ] ; then[INDENT]echo "Allowing Edomi to terminate within $wait seconds"[/INDENT]
fi

while [ "x$PID" != x ]; do[INDENT]s=$((s+1))
echo -n "."
if [ "$s" -ge $wait ]; then[/INDENT][INDENT=2]echo "Edomi did not terminate, hard killing"
kill -9 $PID
exit 0;[/INDENT][INDENT]fi
sleep 1
PID=$(edomipid)[/INDENT]
done
echo
exit 0;

Damit funktioniert es bei mir ganz wunderbar mit einem shutdown, poweroff oder reboot auf der Konsole.

Das heisst, wenn man jetzt die VM runterfährt oder den Server, dann fährt er als erstes Edomi runter?

[saegefisch]

ja, und es kommt keine rote Banderole "Unerwarteter Reboot" mehr in edomi danach.

[uzi10]

das sollte in die nächste Edomi Version gleich fix aufgenommen werden

[1mannlan]

Und das Risiko, dass Edomi danach garnicht mehr hochfährt ist auch minimiert.
Von daher, vielleicht wird es ja doch mal von gaert mit aufgenommen.

[saegefisch]

Naja... aus meiner persönlichen Sicht ist das eine gute Idee, wenn man edomi in einer VM verwendet; in diesem Kontext sollte ein Host die Clients sauber herunter fahren können. in meinem produktiven System auf "echtem Blech" habe ich es aber noch nie vermisst.

Denn: In der von Christian vorgesehenen Anwendung wird edomi stets auf dedizierter HW verwendet, ist die führende Instanz und hat die Kontrolle über das BS. In seinem Konzept stellt er die hohe Verfügbarkeit seiner Haussteuerung so sicher und dies ist da schlicht nicht nötig. Vermutlich tät's aber auch nicht weh - dennoch würde ich damit nicht rechnen...

[1mannlan]

... stets auf dedizierter HW verwendet... In seinem Konzept stellt er die hohe Verfügbarkeit seiner Haussteuerung so sicher. ..

Den Ansatz finde ich spannend. Und ich kenn es eher andersrum.
Alles was hochverfügbar sein soll, kommt ins VMware-Cluster .
Von den Vorteilen des einfacheren Backups einmal abgesehen.

Gut... für Privat vielleicht etwas overkill, aber schon seit Jahren im IT Umfeld Standard und das aus gutem Grund.
Ich würde heutzutage keinen einzigen Server mehr auf dedizierter Hardware laufen lassen.

[saegefisch]

es steht Dir sowas von frei, nicht edomi zu verwenden und z.B. den HS in einer VM zu installieren - ist ja ganz einfach. Oder was auch immer dort zu installieren oder selber zu entwicklen, was ebenso verlässlich ist...

edomi verfolgt andere Konzepte, man mag sie oder nicht und entscheidet sich dafür oder dagegen. Ich mag auch andere Konzepte für alle sonstigen Dienste, aber für diesen Zweck habe ich mich mittlerweile sehr mit dem Ansatz angefreundet - für mein Produktivsystem. Für nicht relevante edomi-Instanzen - da sehe ich auch eine VM-Lösung und jetzt sind wir wieder beim obigen Thema. Aber ja, natürlich...jeder wie er mag: edomi ist bei mir auch der einzige Server auf dedizierter HW. Für alles andere bin ich auch 100% bei Dir.

Ich gebe aber klar zu, dass ich die Diskussionen zum "...aber alle anderen machen das anderes als eodmi und der Schwarm kann nicht irren" ein wenig ermüdend finde - es liegt wohl daran, dass immer mehr "Neulinge" gefallen an der fabelhaften Lösung finden, sich hier tummeln, aber sich nicht auf das Grundkonzept einlassen oder sich damit beschäftigt haben und immer wieder damit um die Ecke kommen. Es ist wie immer im Leben: Jede Kröte hat auch Ihre guten Seiten, jedes Goldstück wirft auch Schatten. Einfach mal akzeptieren oder weiter ziehen und eines der vielen anderen und ebenso leistungsfähigen KNX-Lösungen wählen, die den Markt überschwemmen, aber dafür mit dem BS im Gegensatz zu edomi alles vieeel besser und überhaupt auch richtig machen...

edomi ist nicht irgend ein Linux-Dienst. edomi steuert Deine Bude. Deswegen kommt - just my 2 cents - auch möglichst wenig mit auf diese Kiste, sondern Zusatzkrams möglichst auf einen "echten" Server (mit der BS-Logik, die wir dafür alle für richtig halten). Je weniger/purer edomi, desto verlässlicher wirkt das Konzept.. Ich kann Christians Ansatz nachvollziehen und bin dankbar für seine Stringenz und seinen gesamten konzeptionellen Ansatz und vertraue ihm genau darum meine Bude an. Mit allen pros und cons vor dem Hintergrund meiner eigenen IT-Erfahrung.

Sorry, musste mal raus, weil es sich häuft. Hat nix mit Dir persönlich zu tun...

PS: edomi sorgt sich um Backups von Hause aus. Die kann man wunderbar noch auf ein NAS sichern und kann damit jederzeit ein neues edomi aufbauen.

[ChrisChros]

Edomi auf CentOS7 kommt doch schon mit einem systemd Startskript:

/etc/systemd/system/edomi.service

[Unit]
Description=EDOMI
Before=getty@tty1.service getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service
After=httpd.service mysqld.service network.target
Conflicts=getty@tty1.service getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service
[Service]
Type=simple
ExecStart=/bin/sh /usr/local/edomi/main/start.sh
[B][COLOR=#e74c3c]ExecStop=/bin/sh /usr/local/edomi/main/stop.sh[/COLOR][/B]
TimeoutStartSec=0
StandardInput=tty-force
StandardOutput=inherit
StandardError=inherit
[Install]
WantedBy=default.target

Ich habe darin die ExecStop Zeile (rot) ergänzt)

und das stop.sh Skript sieht dann gemäß der CentOS6.5 Lösung von Michael so aus:

#!/bin/sh

edomipid() {[INDENT]echo `ps -ef | grep "/usr/local/edomi/main/proc/[p]roc_main.php" | awk '{print $2}'`[/INDENT]
}

wait=10
echo -n $"Shutting down Edomi: "
/usr/bin/php /usr/local/edomi/main/control.php quit
rm -f /var/lock/subsys/edomi
sleep 1
PID=$(edomipid)
s=0

if [ "x$PID" != x ] ; then[INDENT]echo "Allowing Edomi to terminate within $wait seconds"[/INDENT]ch hard 
fi

while [ "x$PID" != x ]; do[INDENT]s=$((s+1))
echo -n "."
if [ "$s" -ge $wait ]; then[/INDENT][INDENT=2]echo "Edomi did not terminate, hard killing"
kill -9 $PID
exit 0;[/INDENT][INDENT]fi
sleep 1
PID=$(edomipid)[/INDENT]
done
echo
exit 0;

Damit funktioniert es bei mir ganz wunderbar mit einem shutdown, poweroff oder reboot auf der Konsole.

Hab das mal bei mir in meiner bhyve VM von FreeNAS eingefügt und es funktioniert zumindest bei einem stop über das UI. Reboot der VM über das UI scheint FreeNAS ziemlich hart zu machen ohne zu warten. Ein Reboot vom gesamten FreeNAS System klappt auch, somit eine deutliche Verbesserung.
Danke.

[oefchen]

Edomi auf CentOS7 kommt doch schon mit einem systemd Startskript:

/etc/systemd/system/edomi.service

Hallo Leute, ich zieh grad mit Edomi und Co auf einen HV-Cluster um und probier natürlich ob die Migration klappt.
Dabei kommt nun ganz oft die gehaßte rote Banderole.
Deshalb bin ich hier gelandet...vorher ist das iwie an mir vorbei gegangen....
Jetzt ist meine Inst. aber das neue Templete mit RockyLinux von starwarsfan (Danke an der Stelle nochmal)
Da komm ich mit SSH gar nicht in das Verzeichniss

Wie und wo könnt ich denn die Script-Lösung anwenden ?

[starwarsfan]

Hi

zieh grad mit Edomi und Co auf einen HV-Cluster um

Was ist ein HV-Cluster?

Da komm ich mit SSH gar nicht in das Verzeichniss

Heisst was genau? Fehlermeldung?

[oefchen]

Mahlzeit Yves, hoffe Du bist nicht eingeschneit
Hab die letzten Tage nen Rack-Server aufgebaut der mit 1,5 (ein zusätzl. Rechner + einer der nebenbei nur für Quorate sorgt) im 2-node-Proxmox-Cluster läuft.
Edomi und die InfluxDB sind dann HV...hochverfügbar installiert.

gestern wollt ich dann das script einbauen und kahm von /systemd nicht nach system. Die fehlermeldung wollt ich jetzt kopieren ....
und komm ganz normal in das Verzeichniss ähmm....ups....staun.

Gut....dann bau ich das Script mal genau wie beschrieben ein....das funzt unter RockyLinux genauso....denk ich ?
Sorry für den Falsch-Alarm.

edit: trotzdem komisch. Die "stop.sh" gibts nicht, muss also angelegt und befüllt werden. Aber exakt die steht schon in "edomi.service" drin ?

[starwarsfan]

Hallo miteinander

Mahlzeit Yves, hoffe Du bist nicht eingeschneit

Nee, da schaut noch überall "grün" durch...

Hab die letzten Tage nen Rack-Server aufgebaut der mit 1,5 (ein zusätzl. Rechner + einer der nebenbei nur für Quorate sorgt) im 2-node-Proxmox-Cluster läuft.
Edomi und die InfluxDB sind dann HV...hochverfügbar installiert.

Ah ok, Hardware-Upgrade...

edit: trotzdem komisch. Die "stop.sh" gibts nicht, muss also angelegt und befüllt werden. Aber exakt die steht schon in "edomi.service" drin ?

Diese Datei ist im LXC-Template enthalten resp. wird beim Bau des Templates nach der Installation von Edomi installiert. Das Problem tritt vermutlich dann auf, wenn ein Backup eines System importiert wird, in welchem es diese Datei nicht gibt. Dann fehlt sie hinterher auch im LXC-Container.