Pi automatisch neustarten lassen.

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Servus,
    dazu brauchst Du kein script ... Du fügst einfach einen shutdown -r in die crontab des Nutzers root ein ...
    -> siehe hier <- ...

    Macht allerdings unter Linux irgendwie keinen Sinn ... aber ... des Menschen Wille ... :angel:

    cu,
    -ds-

  • sudo nano neustart.sh

    Bash
    #!/bin/bash
    
    
    sudo reboot

    neustart.sh in crontab aufrufen und in /etc/sudoers Rechte vergeben damit der sudo Aufruf in neustart.sh erlaubt ist (nur für neustart.sh !)
    Automatisch zusammengefügt:
    das geht natürlich auch ...
    Aber warum wird das benötigt ???

    Einmal editiert, zuletzt von flyer99 (16. Februar 2017 um 21:52)


  • Macht allerdings unter Linux irgendwie keinen Sinn ... aber ... des Menschen Wille ... :angel:

    kannst du das auch begründen?

    Ich habe das Gefühl das der PI umso länger er läuft langsamer wird.
    Wird dort nie ein garbage collection gemacht?

    Es könnte ja sein das ein frisch gestarteter PI flotter läuft.
    Ausserdem gab es Linux Systeme bei denen wuchsen die LOG ins "unendliche" auch da kann ein kürzen mit tail auf die letzten 100-1000 Zeilen sinnvoll sein.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Code
    sudo su -
    crontab -e
    (jetzt eintragen)
    30 15 * * * /sbin/reboot
    (crontab speichern und verlassen)
    exit

    Warum ein Shellscript, wenn man das Programm in der Root-Crontab direkt aufrufen kann?

    Computer ..... grrrrrr


  • [code]
    sudo su -
    crontab -e
    (jetzt eintragen)
    3

    Warum ein Shellscript, wenn man das Programm in der Root-Crontab direkt aufrufen kann?

    Naja, weil ich über ein Shellscript andere Sachen über html aufrufe und dachte da funzt auch der reboot, schnelle Hilfe kann nicht schaden ;)
    funzt ja auch, dennoch ist deine Version natürlich "effektiver", kein Thema :thumbs1:

  • Servus jar,


    Ich habe das Gefühl das der PI umso länger er läuft langsamer wird.
    Wird dort nie ein garbage collection gemacht?

    ein "Gefühl" ist kein Grund ;) ...
    Wenn Du mal ein bisschen im Internet recherchierst wirst Du feststellen, dass es keinen wirklichen Grund - ausser speziellen Updates - gibt, den Linux Rechner periodisch neu zu starten ...

    http://askubuntu.com/questions/6157…ux-pc-can-be-up
    oder
    https://www.reddit.com/r/linux/commen…_linux_desktop/
    ...


    ...
    Es könnte ja sein das ein frisch gestarteter PI flotter läuft.


    Es könnte auch sein, dass Du Dich täuschst ;) ...



    Ausserdem gab es Linux Systeme bei denen wuchsen die LOG ins "unendliche" auch da kann ein kürzen mit tail auf die letzten 100-1000 Zeilen sinnvoll sein.

    Das wäre mir jetzt neu ... solange ich mit Linux/Unix zu tun habe ist mir so was im Normalbetrieb noch nicht untergekommen.

    Ok, wenn Du manuell eingreifen und Deine logs mit tail kürzen willst ... bitte ... dazu brauchst Du aber auch keinen reboot machen ...


    cu,
    -ds-


  • ..., dass es keinen wirklichen Grund - ausser speziellen Updates - gibt, den Linux Rechner periodisch neu zu starten ...

    Ja, das sehe ich auch so. ... und was ich bei Freunden auch schon gesehen habe, die ihren Linux-"Server" wegen fehlerhafter Konfiguration von Anwendungen/Diensten periodisch neu starten wollten/"mussten", ... das hat gerade wegen der nicht richtigen Konfiguration mit lediglich einem "reboot" gar nicht funktioniert. Da war dann schon ein:

    Code
    /bin/sync
    /sbin/reboot -f


    erforderlich (... wenn man sich auf das rebooten, zu 99,99% verlassen muss/soll).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hi Jar,

    unter Linux-Systemen ist üblicherweise ein sog. LOG-Rotate aktiv. Dies führt dazu, dass - je nach Konfiguration - z.B. eine LOG-Datei wöchentlich oder monatlich archiviert wird und eine neue LOG-Datei gestartet wird. Die Anzahl der Archiv-LOG-Dateien kann ebenso eingestellt werden. Und z.B. so, dass nur 4 Archiv-Dateien behalten werden.
    Das macht auch Sinn, denn etwas, was vor Wochen und Monaten geschehen ist, kann keine messbare Auswirkung auf das heutige (Fehl-)Verhalten eines Computersystems haben.

    Den einzigen Einfluss, den ich festmachen konnte, ist der verfügbare Speicher auf der Festplatte / SD-Karte und SWAP-Einstellungen. Wobei die für mich persönlich auf einem RPi wenig Sinn machen, wenn unkontrolliert ein kleiner Bereich auf der SD-Karte vollgeballert wird. Wenn der verfügbare Speicher unter einen bestimmten Grenzwert kommt, dann wird's messbar langsamer.

    In einem solchen Fall hilft es dann nur, die heruntergeladenen Dateien der bereits installierten Anwendungen zu löschen.

    Wenn sich allerdings Eigenentwicklungen nicht am LOG-Rotate orientieren, dann hilft nur noch regelmäßiges Aufräumen - manuell oder automatisiert.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.


  • Servus jar,

    Das wäre mir jetzt neu ... solange ich mit Linux/Unix zu tun habe ist mir so was im Normalbetrieb noch nicht untergekommen.

    mir schon in gekaufter Hardware!
    mit sowas wollte ich mich eigentlich nie beschäftigen!

    erinnere ich hiermit noch mal an:
    Lösung: Unable to resolve hostname

    und neu:
    Jessi - Speicherkarte läuft voll

    ach komm dirk, das soll dir nicht bekannt sein?
    auch mein seit 2012 laufender mediaPI mit raspbmc hatte mich plötzlich ohne Updates aus dem SSH ausgesperrt mit der Meldung openSSH Zertifikat abgelaufen!

    Ein Glück das der nicht 1000 km weit weg war, so konnte ich etwas später daheim das openSSH neu installieren.

    Ich will gerne glauben das mit rudimäntären Linuxfunktionen der 24/7 durchläuft aber niemals mit vorgefertigten Distributionen.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Einmal editiert, zuletzt von jar (18. Februar 2017 um 15:04)

  • Ach komm, jar ...


    wenn da was mit falsch konfiguriertem Linux für teuer Geld vertickt wird (Dein RaidSonic in diesem Fall), kannst Du doch das OS nicht dafür verantwortlich machen ...


    Das hat auch erst mit Jessie selbst nix zu tun sondern scheint ja eine (nachinstallierte) Anwendung zu sein ...
    Das ist dasselbe wie


    ... aus dem SSH ausgesperrt mit der Meldung openSSH Zertifikat abgelaufen!

    Wenn Du was auf einem Rechner, egal mit welchem OS drunter, installierst, dann musst Du Dich schon drum kümmern, dass die Voraussetzungen passen ...
    Und wenn so ein Zertifikat abläuft, das sicherheitsrelevant ist, dann ist das imho ein Pluspunkt, wenn Du das nicht irgendwie umgehen kannst. Du hast halt verpennt, das hin und wieder zu überprüfen ...


    ... rudimäntären Linuxfunktionen der 24/7 durchläuft aber niemals mit vorgefertigten Distributionen.


    Was sollen "rudimentäre" Linuxfunktionen sein?
    Streng genommen ist Linux nur der Kernel ...
    Und gerade (seriöse) vorgefertigte Distributionen laufen meiner Erfahrung nach sehr zuverlässig.
    Erst wenn der Nutzer eingreift, anfängt kreuz und quer und gegen alle Regeln des OS Applikationen zu installieren, sie falsch oder gar nicht zu konfigurieren, sinnfrei irgendwo irgendwas löscht, ändert oder reinkopiert fangen die Probleme an.

    Du wirst imho keine belastbare Quelle finden die belegt, dass periodisches Booten eines Linux-System empfehlenswert ist.
    Und das ist war ja die Frage, oder?

    cu,
    -ds-

  • Linux (auch Rasbian) muss nicht dauernd neu gebootet werden, das ist definitiv Unsinn..

    Beispiel:

    Code
    pi@raspberrypi:~$ uname -a
    Linux raspberrypi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux
    
    
    pi@raspberrypi:~$ uptime
     15:28:17 up 125 days, 14:38,  1 user,  load average: 0.08, 0.03, 0.05

    Raspi B+, darauf läuft eine MySQL DB, ein Wiki (+Apache), ein Nagios-Client und 2 chron-Jobs, die die DB und das Wiki alle 24h abziehen und per rsync auf ein NAS sichern...
    Distribution ist "from scratch ohne weiter "Frisuren"...

    Einzige Wartung: jede Woche Einspielen der ggf. angefallenen Sicherheitsupdates und 1x im Monat Update (bisher ohne Reboot gegangen).
    Logs rotieren per logrotate,

    Das letzte Reboot war notwendig, weil ich das Teil woanders angeschlossen habe (Stromtechnisch jetzt über eine USV)...

    Vielleicht kann sich der TO mal äußern, warum er seinem RP diesen cyclischen reboot-Stress antun will...


  • Ach komm, jar ...
    wenn da was mit falsch konfiguriertem Linux für teuer Geld vertickt wird (Dein RaidSonic in diesem Fall), kannst Du doch das OS nicht dafür verantwortlich machen ...


    nein da hast du Recht,
    aber als Nutzer muss ich darauf vertrauen das so etwas nicht verkauft wird und ich muss nicht die Entwicklerfehler beheben, aber Linux pauschal Fehlerfreiheit zu unterstellen halte ich auch für gewagt.


    Das ist dasselbe wie


    Wenn Du was auf einem Rechner, egal mit welchem OS drunter, installierst, dann musst Du Dich schon drum kümmern, dass die Voraussetzungen passen ...

    nein auch das war eine fertige Distri ohne Nachinstallation!
    Du willst bei fertigen Distris dem User die Schuld geben?
    Das klappt nicht.

    OK der User hat also immer Schuld der was kauft was nicht richtig funktioniert, er hätte ja vorher den Quellcode durchsuchen müssen und bei Geräten jedes Teil untersuchen müssen vor dem Kauf.


    Was sollen "rudimentäre" Linuxfunktionen sein?
    Streng genommen ist Linux nur der Kernel ...
    Und gerade (seriöse) vorgefertigte Distributionen laufen meiner Erfahrung nach sehr zuverlässig.


    was sind denn seriöse? woran erkennt man die?
    Der Linux Kernel soll also fehlerfrei sein? Auf das schmale Brett gehe ich nicht


    Du wirst imho keine belastbare Quelle finden die belegt, dass periodisches Booten eines Linux-System empfehlenswert ist.
    Und das ist war ja die Frage, oder?

    Ich finde auch keine belastbare Quelle wieviel Fussgänger bei rot über die Fussgängerampel überlebt haben, das soll ein Beweis sein?

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Ei jei jei ... mein Lieblings-Bälina :) ...


    nein auch das war eine fertige Distri ohne Nachinstallation!
    Du willst bei fertigen Distris dem User die Schuld geben?


    Nö, aber Du wirst ja das Zertifikat irgendwie nutzen ... und sei es zur Authorisierung per ssh.
    Und damit hast Du auch die Verantwortung dafür, dass es aktuell ist.
    Ehrlich ... ich hab' in meinem ganzen Leben noch kein einziges Zertifikat geändert, erneuert oder angelegt ... und ich hatte da bisher noch nie ein Problem.
    Und, wie gesagt, wenn bei Auslieferung Deines Neuwagens die Einspritzanlage falsch eingestellt ist, kann auch der Hersteller der Einspritzung nix dafür, oder?

    Ja ... es ist manchmal mühsam, sich durch Foren zu hangeln oder Dokus zu lesen und sich was Neues reinzuziehen, was man teilweise anfangs überhaupt nicht versteht, weil man Jahre mit einem anderen OS zugebracht hat.
    Und ja ... manchmal kommt man sich blöd oder hilflos vor ... aber wenn ich zurückdenke, dann war das anfangs immer so ... egal vor welcher "black box" ich gesessen bin ... ob HP/UX, Sinix, Unix, BS200, MS-DOS, WIN95 ...
    Und ja ... ich hab' oft geflucht und mir einen Wolf gelesen und Leute gefragt und zigmal neu installiert und, und, und ...

    Aber der Schwachpunkt war immer ich ... ich hab' was falsch gelesen, was nicht verstanden, ...

    Das ist mit einem Linux OS nicht anders ... es gibt kein OS, das es zulässt, dass Du eigenverantwortlich mit Deiner Hardware und Deinen Daten umgehst und zugleich ein "Rundum-Sorglos-Paket" anbietet.
    Da muss Du halt durch ...


    ...


    Der Linux Kernel soll also fehlerfrei sein? Auf das schmale Brett gehe ich nicht


    Das hab' ich nicht gesagt ... bitte nicht anfangen, was in meine Aussagen rein zu interpretieren. Ich weiss, vermutlich besser als viele andere hier, dass es keine fehlerfreie Software gibt.


    was sind denn seriöse? woran erkennt man die?


    Damit meine ich die "grossen" Distributionen wie RedHat, Debian, Ubuntu, SuSe, ...
    Also keine Zusammenstellung, die irgendjemand irgendwann mal aus irgendwas zusammengewürfelt hat und dann vielleicht noch für Kohle vertickt ...


    ...
    Ich finde auch keine belastbare Quelle wieviel Fussgänger bei rot über die Fussgängerampel überlebt haben, das soll ein Beweis sein?

    Ach jetzt aber ...
    Es gibt sicherlich genügend Quellen bei denen Du nachlesen kannst, dass Leute, die bei rot über die Strasse gehen, in Unfälle verwickelt wurden. Damit wäre schon mal der Beweis erbracht, dass es Sinn macht, auf grün zu warten ...
    Ausserdem ... nicht alles was hinkt ist ein Vergleich ... und das ist jetzt schon mehr als nur an den Haaren herbeigezogen und passt absolut nicht in den Kontext ... aber das weisst Du schon selbst, Du altes Schlitzohr ...

    cu,
    -ds-

  • Willi:
    Also meine Linuxe laufen zuhause solange durch bis zu einem Kernel-Update (das geht noch(?) nicht online) und in der Firma laufen die mehrere 1000 Linux-Server auch bis sie rebooted werden müssen. Aber das “müssen” ergibt sich durch harte Fakten wie z.B.:
    Kernel-Update
    Out-of-Memory-Situationen
    so viele Updates und Abhängigkeiten von Diensten untereinander, dass man das mit gezielten Restarts von Diensten nicht mehr in den Griff bekommt

    Also warum solltest Du Deinen Pi täglich rebooten wollen? Bei Windows würde ich sagen “klaro, geht ja nicht anders” ;) Aber ein Linux läuft auch unter Volllast ein Jahr durch, wenn man es lässt.

  • ....
    Aber warum willst das überhaupt machen ? Hängt sich dein Pi auf ?

    Hallo, erst einmal meinen aufrichtigen Dank an Euch, dass Ihr Euch die Mühen macht einem (anderen) Anfänger zu zeigen wie man Dinge mit dem Raspi anstellt, obwohl Ihr sie selbst für überflüssig haltet. Ist in anderen Foren oft anders. Da artet so ein Thema in Querverweisen und in Kommentaren "Lern erst einmal aufrecht gehen" aus.

    Da oben immer wieder die Frage kommt "wozu sowas?" hier mal mein Grund warum ich so dankbar für Eure Beiträge bin:

    Ich habe für mein fhem ein 433Mhz Thermometer, dass ich mit nem USB-Stick einlese.

    Den Treiber für den Stick habe ich bereits in den Autostart gebastelt bekommen:

    (startl.sh mit u.a. dem Inhalt´"rtl_433 -F mqtt" , dann bash start.sh, unter "usr/local/sbin/" abgelegt und in "/etc/rc.local" eingetragen) .

    Leider hängt sich der Stick so alle 2-3 Tage weg und rtl_433... wird beendet. Entweder rufe ich nun im Raspberry die "start.sh" bzw. "rtl_433 -F mqtt" manuell auf oder ich boote eben neu. Automatischer reboot finde ist daher voll toll (natürlich nicht um 15:30)

  • Leider hängt sich der Stick so alle 2-3 Tage weg und rtl_433... wird beendet. Entweder rufe ich nun im Raspberry die "start.sh" bzw. "rtl_433 -F mqtt" manuell auf ...

    Du könntest doch mit einem Script (oder gleichwertig) und einer timer-unit regelmäßig prüfen, ob rtl_433... beendet ist und wenn ja, "start.sh" bzw. "rtl_433 -F mqtt" aus dem Script aufrufen. D. h. eine Art watchdog oder monitor für deine Anwendung. BTW: Es gibt auf "fertige" monitor-Software. Evtl. wäre so etwas für deine Anwendung geeignet.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!