@reboot nefunguje v CRON

Podívejte se na manuálovou stránku systemd.service. Popisuje, jak nakonfigurovat systemd pro správu služby. Jsem si jistý, že v /usr/lib/systemd/system najdete příklady pro váš systém nebo podobné cesty.

Ve vašem případě by služba vypadala nějak takto:

[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

Vložte to do souboru /etc/systemd/system/unturned.service . Poté spusťte systemctl daemon-reload (jednou a kdykoli změníte unturned.service říct systemd, aby znovu přečetl konfiguraci) a systemctl start unturned.service ke spuštění herního serveru.

Pokud to funguje podle očekávání, můžete použít systemctl enable unturned.service abyste se ujistili, že se spustí při spouštění.

Několik poznámek k použitým možnostem:

• Pokud start.sh nemá běžet jako uživatel/skupina steam , odpovídajícím způsobem upravte.
• WantedBy v Install sekce říká systemd, který "cíl" (viz man systemd.target) stáhne službu, když ji povolíte pomocí systemctl enable.
• Restart definuje, za jakých okolností systemd automaticky restartuje službu. Existuje více možností souvisejících s restartováním, které můžete nebo nemusíte chtít změnit; viz manuálová stránka systemd.service.

Zkuste man 5 crontab . Pokud váš crontab podporuje, měli byste vidět @reboot, @yearly, @monthly,.,,,

pak zkuste na chvíli přidat spánek, může to pomoci.

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

Zkontrolujte kritický řetězec pro crond.service, jak je požadováno a zodpovězeno v tomto příspěvku StackExchange

Podívejte se také na tento článek FreeDesktop zabývající se tímto problémem.

Obecně je systemd nakonfigurován tak, aby měl velmi omezené závislosti a spouštěl mnoho démonů paralelně, aby se zkrátil čas strávený zaváděním. Služby, které nejsou nutně závislé na tom, že síť je plně funkční a funkční, selžou, pokud existují součásti, které předpokládají, že síť je ve stabilním stavu. Poruchy, jako je tato, může být obtížné diagnostikovat, ale pomocí systemd-analyze critical-chain a journalctl -xel výstup vás může přivést ke kořenové příčině vašeho problému.