Tägliches Reboot des Servers

This topic contains 9 replies, has 2 voices, and was last updated by  MarioM Moderator 7 months, 2 weeks ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • 1. März 2021 at 15:33 #50857

    Hallo,
    aus verschiedenen Gründen möchte ich Server jeden Tag um 05:00 Uhr selbstständig rebooten.
    Dazu könnte man den Befehl „shutdown -r 05:00“ anwenden. Als Linux-Laie kann ich zwar die installierte Konsole nutzen, bin aber leider nicht fähig, diesen Befehl in den Boot- oder anderen Vorgang einzutragen. Wenn ich in der Konsole „sudo shutdown -r 05:00“ funktioniert es zwar, aber eben nur einmalig.
    Kann mir jemand helfen?
    MfG otti

    1. März 2021 at 17:06 #50860

    Hallo Otti,

    dazu nutzt du am besten crontab. Gib in der Konsole crontab -e ein. Daraufhin sollte sich ein Editor öffnen. Nun gibst du in einer Zeile 0 5 * * * /sbin/shutdown -r ein. Speichere die Datei dann mit STRG + X (anschließend Y, dann Enter). Es kann sein, dass du den crontab mit sudo crontab -e öffnen und dort den entsprechenden Befehl eintragen musst. Probiere das am besten mal selbst einmal aus.

    3. März 2021 at 9:53 #50866

    Hallo MarioM,
    ich habe Deinen Tipp vollzogen und mit „crontab -l“ auch kontrolliert, dass der Befehl „0 5 * * * /sbin/shutdown -r 05:00“ eingetragen ist.
    Vielleicht zum Hintergrund: ich hatte öfters am Morgen Probleme mit der Verbindung von Radio o.ä. zum Server. Erst nach Trennung des Servers vom der Stromversorgung und somit dann ein Hardware-Reset war wieder alles in Ordnung. Und es scheint (bis jetzt) mit dem Crontab-Job zu funktionieren. Kann man die Ausführung im Nachhinnein kontrollieren (oder natürlich um 5:00 Uhr am LMS zu sitzen und beobachten 🙂 ).
    Allerdings ist da noch das zweite Problem. Mein NAS-Server mit den Musikdateien startet täglich automatisch von 8:00 bis 23:00 Uhr. Die Verbindung ist auch öfters weg. Im Player steht dann unter Musikplayer „Leer“. Auch hier hilft nur der Neustart des LMS. Das war vor einiger Zeit nicht so. Natürlich ist es schwierig zu rekonstruieren, ab wann und in welchem Zusammenhang das passierte. Ich habe auf dem LMS die Version 2.53 auf einem Raspberry 3.
    Vielleicht hast Du einen neuen Hinweis 🙂

    MfG otti

    3. März 2021 at 15:30 #50871

    Hallo Otti,

    Du könntest mal einen Blick in den Server Log unter Einstellungen/Informationen werfen. Die ein oder andere Fehlermeldung könnte Aufschluss darüber geben, warum der Server (/Playe?) nicht mehr erreichbar ist. Was genau meinst du mit „Im Player steht dann unter Musikplayer „Leer“? Ist damit die Weboberfläche des Servers gemeint?

    6. März 2021 at 14:26 #50886

    Hallo MarioM,

    nach einigen Tagen des Abwartens ist der Zustand wie vorher: an einigen (zufälligen) Tagen ist am Morgen ein Ab-/Anschalten des LMS notwendig.
    In der Server-Log-Fatei steht auch nichts zu passendes:

    [21-03-06 10:52:26.4297] main::init (388) Starting Logitech Media Server (v8.1.1, 1610364019, Thu Jan 14 06:24:07 CET 2021) perl 5.028001 – arm-linux-gnueabihf-thread-multi-64int
    [21-03-06 10:52:33.4553] Slim::Player::Song::open (415) Error: Couldn’t create command line for unk playback for [http://opml.radiotime.com/Tune.ashx?id=s138091&formats=aac,ogg,mp3,wmpro,wma,wmvoice&partnerId=16&serial=e769d6e5a7b2d861a97c52858e57ce42]
    [21-03-06 10:53:06.4405] Slim::Utils::Scanner::Local::rescan (179) Discovering audio files in /mnt/media
    [21-03-06 10:53:06.4690] Slim::Utils::Scanner::Local::__ANON__ (191) Start processing found tracks
    [21-03-06 10:53:06.4700] Slim::Utils::Scanner::Local::__ANON__ (199) Connect do DB
    [21-03-06 10:53:06.4712] Slim::Utils::Scanner::Local::__ANON__ (202) Get latest ID
    [21-03-06 10:53:06.4730] Slim::Utils::Scanner::Local::__ANON__ (224) Delete temporary table if exists
    [21-03-06 10:53:06.4743] Slim::Utils::Scanner::Local::__ANON__ (227) Re-build temporary table
    [21-03-06 10:53:08.7946] Slim::Utils::Scanner::Local::__ANON__ (276) Get deleted tracks count
    [21-03-06 10:53:08.8020] Slim::Utils::Scanner::Local::__ANON__ (283) Get new tracks count
    [21-03-06 10:53:08.8037] Slim::Utils::Scanner::Local::__ANON__ (288) Get changed tracks count
    [21-03-06 10:53:09.5697] Slim::Utils::Scanner::Local::deleteTracks (519) Removing deleted audio files (0)
    [21-03-06 10:53:09.5708] Slim::Utils::Scanner::Local::__ANON__ (301) Scanning new audio files (1)
    [21-03-06 10:53:09.5945] Slim::Utils::Scanner::Local::__ANON__ (381) Rescanning changed audio files (0)

    Wie zu sehen ist, habe ich die Server-Vers. 8.1.1 eingespielt – half auch nichts.
    Dann habe ich das WLAN an der Fritz-Box 24-stündig durchlaufen lassen (sonst war zwischen 23 Uhr und 5 Uhr Funkstille) – auch nicht geholfen.
    Als Vermutung bleibt noch das nächtliche, automatische Trennen zur Neuvergabe der Router-IP-Adresse (bei mir so gegen 04:10 Uhr)
    oder aber der RasperryPi hat einen Macke? Vielleicht müßte ich mal einen auf anderen Raspi den LMS neu aufsetzen.

    MfG otti

    8. März 2021 at 9:26 #50889

    Hallo,
    ich bin weiter am Problem. Ich habe den LMS komplett neu auf einem Raspi4 aufgesetzt. Das Erbenis ist dasselbe wie mit dem Raspi3.
    Im Log-File sind die letzten Zeilen ab 07.03. (nun mit Raspi 4)
    [21-03-07 16:43:29.1178] main::init (388) Starting Logitech Media Server (v8.1.1, 1610364019, Thu Jan 14 06:24:07 CET 2021) perl 5.028001 – arm-linux-gnueabihf-thread-multi-64int
    [21-03-07 16:43:31.3745] Slim::Web::Cometd::handler (421) errorNeedsClient: b8:27:eb:10:3e:af, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
    [21-03-07 16:43:31.5591] Slim::Web::Cometd::handler (421) errorNeedsClient: 7c:dd:90:90:ac:3d, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
    [21-03-07 16:43:32.0756] Slim::Web::Cometd::handler (421) errorNeedsClient: 00:04:20:28:ac:bf, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
    2021-03-07 17:44:22 squeezeboxserver_safe stopped.
    2021-03-07 17:44:22 squeezeboxserver_safe started.
    [21-03-07 17:44:24.7944] main::init (388) Starting Logitech Media Server (v8.1.1, 1610364019, Thu Jan 14 06:24:07 CET 2021) perl 5.028001 – arm-linux-gnueabihf-thread-multi-64int
    [21-03-07 17:44:27.4344] Slim::Web::Cometd::handler (421) errorNeedsClient: b8:27:eb:3d:84:6d, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
    [21-03-07 17:44:27.5335] Slim::Web::Cometd::handler (421) errorNeedsClient: 7c:dd:90:90:ac:3d, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
    [21-03-07 17:44:27.6654] Slim::Web::Cometd::handler (421) errorNeedsClient: b8:27:eb:10:3e:af, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
    [21-03-08 05:00:49.3842] Slim::Web::Cometd::handler (421) errorNeedsClient: 7c:dd:90:90:ac:3d, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
    [21-03-08 05:01:18.9898] Slim::Web::Cometd::handler (421) errorNeedsClient: 00:04:20:28:ac:bf, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
    2021-03-08 06:38:27 squeezeboxserver_safe started.
    [21-03-08 06:38:30.3924] main::init (388) Starting Logitech Media Server (v8.1.1, 1610364019, Thu Jan 14 06:24:07 CET 2021) perl 5.028001 – arm-linux-gnueabihf-thread-multi-64int
    [21-03-08 06:38:30.7828] Slim::Utils::IPDetect::_init (138) Warning: Couldn’t call connect() – falling back to 127.0.0.1

    Es half nur wieder (ab 07:01 Uhr) ein Trennen von der Stromversorgung und wieder einschalten.
    Ich habe keine Ahnung, wie weiter.
    MfG otti

    9. März 2021 at 15:44 #50895

    Hallo Otti,

    ich vermute, dass deine Netzwerkeinstellungen die Probleme verursachen könnten. Bitte versuche wenn möglich, den Server per LAN Kabel mit dem Router zu verbinden. Kannst du die tägliche IP-Neuvergabe in deinen Routereinstellungen umgehen? Falls ja, wäre das auch einen Test wert.

    9. März 2021 at 16:00 #50897

    Hallo,
    danke für die Antwort.
    Der Server ist schon immer per LAN an der Fritzbox.
    Ich habe (wie schon geschrieben) den LMS nun auf einem Raspi4 laufen. Der Wechsel(wie auch schon geschrieben) brachte erst einmal keine Verbesserung. Da man immer erst einmal nur eine Änderung vornehmen soll, habe ich seit gestern wieder einmal das nächtliche WLAN-Aus abgeschaltet. Es dürfte eigentlich kein Zusammenhang sein, aber man weiß nie …
    Heute war erst mal alles in Ordnung, der Server war mit allen Playern ordentlich verbunden, der eine hat sogar richtig geweckt.
    Hier noch ein kleiner Ausschnitt aus dem Logfile von gestern abend bis heute früh:
    21-03-08 20:15:38.0388] Slim::Utils::Scanner::Local::__ANON__ (301) Scanning new audio files (0)
    [21-03-08 20:15:38.0391] Slim::Utils::Scanner::Local::__ANON__ (381) Rescanning changed audio files (0)
    [21-03-09 09:39:43.9815] Slim::Utils::Scanner::Local::rescan (179) Discovering audio files in /mnt/media/Musik_Archiv_Bittner
    [21-03-09 09:39:44.0987] Slim::Utils::Scanner::Local::__ANON__ (191) Start processing found tracks
    Also keine entscheidenden Sachen einschließlich der Zwangstrennung des Routers gegen 04:00 Uhr (wird ja vom LMS als solcher gar nicht erkannt).
    Ich teste weiter und werde dann wieder berichten.
    Vielleicht lag es am vorher verwendeten Raspi3 – auch MiniPC sind nur Menschen 🙂
    MfG otti

    15. März 2021 at 10:27 #50940

    Hallo,
    letztendlich habe ich keine Ursache gefunden, warum der LMS auf einem RaspberryPi 3 oder 4 immer mal die Verbindung verliert und nur durch Trennen/Wiedereinschalten (also ein Hardware-Reset) zum Laufen gebracht werden konnte. Das System lief eigentlich Jahre ohne Probleme. Warum nun nicht mehr – wer weiß!
    Ich bin jetzt wieder zurück mit dem LMS auf dem NAS (Synology DS 216 mit LMS 8.1.1). Da ich das NAS nächtlich automatisch abschalte (und damit auch den LMS) , läuft es jetzt wieder. Während der nächtlichen Ruhe kann man nun nicht mehr Internetradio hören, aber das kann ich verschmerzen.
    Ansonsten laufen alle auf Raspi-Basis laufenden Max2Play-Player klaglos.
    Da ich auch einen Player auf picoreplayer-Basis habe (man probiert doch alles aus :-), ist mir aufgefallen, dass dort in den Einstellungen ein zeitlich definiertes Ab- und Anschalten des LMS möglich ist. Ich werde mal diese Variante auch ausprobieren.
    MfG
    otti

    15. März 2021 at 16:54 #50942

    Hallo Otti,

    schön, dass du erstmal einen Workaround für das Problem gefunden hast. Nichtsdestotrotz ist dieses Verhalten des Servers eher unschön. Ich werde unseren Entwickler über die Ganze Angelegenheit mal in Kenntnis setzen. Vielleicht weiß er ja noch Rat oder wird vielleicht sogar ein ähnliches Feature in Max2Play in Zukunft einbauen.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

Register here