Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Umstieg Truenas Core -> Scale manageacpi funktioniert nicht mehr
existiert denn das Script unter Scale?
Und hat es die selbe Syntax?
Schließlich bist Du von FreeBSD auf Linux gewechselt.
Bzw. wenn es ein eigenes Script ist, was der o.g. Pfad impliziert,
hast Du es von FreeBSD auf Linux umgeschrieben?
Manche nativen Befehle unterscheiden sich halt zwischen den beiden Derivaten.
Natürlich gibt es da etwas "ähnliches" für Linux. Als Startpunkt deiner Reise würde ich dies empfehlen: https://wiki.ubuntuusers.de/Shell/
Das von dir verwendete Script wurde für FreeBSD entwickelt, musst es jetzt ggf. anpassen oder dir entsprechende Alternativen suchen.
Ich hatte mir vor Jahren mal etwas ähnliches zusammen gehackt. Da habe ich einfach geprüft ob irgendein Client noch aktiv auf Daten der SMB Shares zugreift und wenn nicht, dann hab ich eine 0 in eine Datei geschrieben. Beim nächsten Aufruf hab ich geprüft ob es diese Datei gibt und was drin steht. Wenn eine 15 drin stand, wurde die Datei gelöscht und dann das System herunter gefahren. Wenn keine 15 drin stand, wurde wieder auf Zugriff geprüft und wenn weiterhin nix los ist, wurde der Counter erhöht. Wenn Zugriff war dann wurde der Counter zurück gesetzt. Das Script lief abends minütlich per cronjob. Wenn es also 15 Minuten am Stück keine Aktivität gab, dann fuhr das System herunter.
Mit viel Glück hab ich noch ein Backup davon, erinnere mich ggf. in paar Tagen (ab Sonntag frühestens) mal dran wenn ich hier nix mehr posten sollte, dann suche ich nochmal.
if [ $RETRY != 0 ]; then
log "===== Nächsten Versuch abwarten... ====="
fi
sleep $waittime
done
if [ $RETRY == $MAXRETRYS ]; then
log "===== Truenas wird heruntergefahren ====="
poweroff
exit
fi
Und zwar habe ich bei Truenas einen Cronjob angelegt der mir dieses Skipt von 20-2Uhr im 15 Minutentakt ausführt.
Es kommt jedoch immer wieder vor, dass der Cronjob nicht beendet wurde und die NAS kein SMB Zugriff mehr zulässt. Ist meistens so, wenn eben nicht alle Teilnehmer heruntergefahren wurde.
Ein Neustart der NAS macht dann den Zugriff wieder möglich.
SMB Dienst deaktivieren und aktivieren reicht nicht.
Es wäre übersichtlicher wenn du im Spoiler den CODE Block nutzen würdest um Zeilenzahlen zu haben. Lässt sich dann einfacher drüber sprechen wenn man direkt Zeilen ansagen kann anstatt es jedes Mal beschreiben zu müssen. Du möchtest ja etwas von uns, daher bitte auf Leserlichkeit achten und ggf. Kommentare im Code setzen damit man deine Gedanken und Ideen schneller/einfacher nachvollziehen kann.
yamaharacer schrieb:
Es kommt jedoch immer wieder vor, dass der Cronjob nicht beendet wurde
Korrekt denn dein gesamtes Script hat eine längere Laufzeit als das Intervall der Wiederausführung. Erst machst du ein sleep von 10 Minuten und dann wartest du nach jedem Lauf der for-Schleife jeweils 5 Minuten. Sobald also Hosts noch erreichbar sind, läuft dein Script 15 Minuten und länger.
Bin mir gerade gar nicht sicher ob er das dann ein zweites Mal startet oder den Cronjob nicht ausführt.
Ich würde das Script dahingehend abwandeln, dass du deinen RETRY Wert in eine Datei schreibst, am Anfang des Scripts den Wert ausliest, deine Checks machst, wenn Clients erreichbar sind dann erhöhe den Wert in der Datei und fertig. Dann hast du eine deutlich reduzierte Laufzeit.
Beim "ping" Test gehst du also davon aus, dass alle Clients stets korrekt per ping erreichbar sind und die Antwortzeit unter 1 Sekunde garantiert ist und alle Hosts/Clients auch abends sauber herunter gefahren werden?
Im ersten if-Statement: Hier prüfst du ja die Ausgabe der ping-Checks nach dem Exit Code. Für den Fall, dass mindestens ein Client erreichbar ist, setzt du den Wert in $RETRY auf 0 und sobald das passiert ist, ist RETRY ja kleiner als der Startwert in der for-Schleife. Die Schleife würde also mindestens einen Durchlauf extra machen bis du bei MAXRETRYS angekommen bist.
Solange also mindestens 1 Host/Client erreichbar ist, wird dein $RETRY immer zurück gesetzt und dein Script läuft endlos. Theoretisch müsstest du es also per Cronjob abends nur ein einziges Mal starten lassen. Ist aber unschön, besser wäre es das Script nicht endlos laufen zu lassen und dann regelmäßig per Cronjob aufrufen.
In dem Moment wo alle Hosts aus sind und aus bleiben, willst du ja die for-Schleife verlassen. Das if-Statement mit dem break brauchst du nicht denn du hast ja bereits in der for-Schleife eine entsprechende Bedingung. Solange RETRY <= MAXRETRYS ist, läuft die Schleife. Mit der Zeit wird Retry dann ja automatisch größer als MAXRETRYS und die Schleife endet.
In dem Moment brauchst du dann auch keine weitere erneute Abfrage im vierten if-Statement denn vorher wird die Schleife ja nie enden
Ich bin mir auch gerade nicht wirklich sicher ob das exit am Ende noch ausgeführt wird denn poweroff ohne weiteren Angaben fährt afaik das System sofort herunter.
Noch etwas: Du möchtest dir ggf. angucken wie Arrays funktionieren. Denn wenn jetzt ein System dazu kommt so musst du es doppelt eintragen. Einmal am Anfang und dann erneut bei den Ping-Befehlen. Wenn du alle Hosts oben in ein Array packst dann kannst du in der For-Schleife eine zweite For-Schleife verwenden, die durch das Array geht.
Ich frage mich weiterhin warum du die Ping-Checks mit einem ODER verbindest. Du willst ja nicht zufällig einen aus der Liste testen sondern alle Hosts durch gehen ob auch alle nicht erreichbar sind, korrekt? In dem Fall müsstest du die || durch && ersetzen oder eben mit einem Array arbeiten.
Das Array hat übrigens noch einen weiteren Vorteil: In deiner Variante geht er immer alle Hosts durch und prüft dann am Ende. Theoretisch könntest du ja schon aufhören wenn mindestens ein Host noch erreichbar ist, oder? Wäre also beim Array der erste Host noch online dann könntest du da ja aufhören und bräuchtest den Rest nicht mehr prüfen.
Zu guter Letzt würde dein Logfile auch ewig anwachsen. Ist zwar nur Text aber brauchst du es ewig? Falls nicht könntest du noch vor dem poweroff entsprechend ein löschen des Logfiles rein packen.
Ich hab übrigens mein oben erwähntes Script noch gefunden. Ich prüfe hierbei jedoch nicht ob irgendwelche Clients erreichbar sind sondern ich prüfe ob gerade Dateien auf dem System geöffnet sind. Zusätzlich lief auf dem Server unter anderem manchmal Steam im Big Picture Mode daher prüfe ich auch ob gerade jemand aktiv etwas spielt. Nur wenn niemand spielt und keiner drauf zugreift, geht der Zähler hoch bis zum Shutdown.
Das Script habe ich dann alle 10 Minuten per Cronjob aufrufen lassen. Das wird auch garantiert nicht perfekt sein und das habe ich vor Jahren mal zusammen geklöppelt und keine Ahnung ob ich das heute noch genauso lösen würde oder ob es elegantere Varianten gibt aber für mich hat es damals zuverlässig funktioniert.
Bash:
#!/bin/bash
#
SLEEPCOUNTER=/tmp/sleepcounter
SAMBA=$(smbstatus -L | grep "Locked files" ; echo $?) # Test ob Zugriff auf Daten auf irgendeinem Samba-Share (0 = ja)
STEAM=$(ps aux | grep "steam -bigpicture"| grep -v grep ; echo $?) # Test ob Steam im BigPictureMode laeuft (0 = ja)
# Erzeuge Sleepcounter-Datei falls nicht existent
if [ ! -e $SLEEPCOUNTER ] ; then
echo "0" > $SLEEPCOUNTER
fi
COUNTER=$(cat $SLEEPCOUNTER)
# wenn KEIN Zugriff auf Samba und kein Steam läuft, erhöhe Counter um 1
if [ ! "$SAMBA" == "0" ] && [ ! "$STEAM" == "0" ] ; then
COUNTER=$((COUNTER+1))
echo $COUNTER > $SLEEPCOUNTER # alter Wert wird überschrieben in der Datei
if [ $COUNTER == "3" ] ; then # Wenn Counter = 3 dann Shutdown
rm $SLEEPCOUNTER
shutdown -P now
fi
else # Wenn Dateizugriff oder Steam aktiv dann Counter zurück auf 0
echo "0" > $SLEEPCOUNTER
fi
exit 0
dafür fehlt mir einfach die Übersicht aller möglichen Befehle und Möglichkeiten ein script zu erstellen. Ich suche eine möglichst einfache Lösung.
Werde mich nochmal einarbeiten.
Es gibt keine einfachen Lösungen für komplexe Probleme. Also gibt es schon indem man Geld auf das Problem wirft und jemand anderes sich dann um die Probleme kümmert.^^
Alternativ hoffen, dass jemand anderes ein identisches Problem hat und eine Lösung veröffentlicht hat und du diese findest.
Problem wird sich bald von selbst lösen. Erhalte nach einem Jahr wartezeit endlich eine PV Anlage. Dann bleibt sie einfach die ganze Zeit eingeschaltet
Ohne eine lokale Speichermöglichkeit, sprich Akku/Pufferbatterie, löst sich da nix von selbst oder scheint bei dir die Sonne 24x7?
Anlage u.v.a. Puffer groß genug ausgelegt um andere Dauerverbraucher wie Kühlschrank & Co vollständig zu versorgen?^^
