@reboot funktioniert nicht in CRON

Werfen Sie einen Blick auf die Manpage systemd.service. Es beschreibt, wie systemd konfiguriert wird, um einen Dienst zu verwalten. Beispiele für Ihr System finden Sie sicher in /usr/lib/systemd/system oder ähnliche Pfade.

In Ihrem Fall würde der Dienst etwa so aussehen:

[Unit]
Description=Unturned Game Server

[Install]
WantedBy=multi-user.target

[Service]
ExecStart=/bin/bash /home/steam/start.sh
Type=simple
User=steam
Group=steam
WorkingDirectory=/home/steam
Restart=on-failure

Legen Sie dies in eine Datei /etc/systemd/system/unturned.service . Führen Sie dann systemctl daemon-reload aus (einmalig und immer dann, wenn Sie unturned.service ändern um systemd anzuweisen, die Konfiguration erneut zu lesen) und systemctl start unturned.service um den Spielserver zu starten.

Wenn das wie erwartet funktioniert, können Sie systemctl enable unturned.service verwenden um sicherzustellen, dass es beim Booten startet.

Ein paar Anmerkungen zu den verwendeten Optionen:

• Wenn start.sh nicht als Benutzer/Gruppe steam laufen soll , entsprechend bearbeiten.
• WantedBy im Install Abschnitt teilt systemd mit, welches „Ziel“ (siehe man systemd.target) den Dienst hereinzieht, wenn Sie ihn mit systemctl enable aktivieren.
• Restart definiert, unter welchen Umständen systemd den Dienst automatisch neu startet. Es gibt weitere Optionen im Zusammenhang mit dem Neustart, die Sie möglicherweise ändern möchten oder nicht. siehe die Manpage systemd.service.

Versuchen Sie es mit man 5 crontab . Wenn Ihr Crontab unterstützt wird, sollten Sie @reboot, @yearly, @monthly,.,,,

sehen

dann versuchen Sie, etwas Schlaf für einen Moment hinzuzufügen, kann helfen.

@reboot sleep 60;/root/s3-mount.sh

Überprüfen Sie die kritische Kette für crond.service, wie in diesem StackExchange-Post gefragt und beantwortet

Verweisen Sie auch auf diesen FreeDesktop-Artikel, der sich mit diesem Problem befasst.

Im Allgemeinen ist systemd so konfiguriert, dass es sehr begrenzte Abhängigkeiten hat und viele Daemons parallel startet, um die Zeit für das Booten zu reduzieren. Dienste, die nicht unbedingt davon abhängig sind, dass das Netzwerk vollständig hochgefahren und funktionsfähig ist, schlagen fehl, wenn Komponenten vorhanden sind, die davon ausgehen, dass sich das Netzwerk in einem stabilen Zustand befindet. Fehler wie dieser können schwierig zu diagnostizieren sein, aber mit systemd-analyze critical-chain und journalctl -xel Ausgabe kann Sie zur eigentlichen Ursache Ihres Problems führen.