@reboot non funziona in CRON

Dai un'occhiata alla manpage di systemd.service. Descrive come configurare systemd per gestire un servizio. Sono sicuro che troverai esempi per il tuo sistema in /usr/lib/systemd/system o percorsi simili.

Nel tuo caso, il servizio sarebbe simile a questo:

[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

Inseriscilo in un file /etc/systemd/system/unturned.service . Quindi esegui systemctl daemon-reload (una volta e ogni volta che cambi unturned.service per dire a systemd di rileggere la configurazione) e systemctl start unturned.service per avviare il server di gioco.

Se funziona come previsto, puoi utilizzare systemctl enable unturned.service per assicurarti che si avvii all'avvio.

Alcune note sulle opzioni utilizzate:

• Se start.sh non deve essere eseguito come utente/gruppo steam , modifica in modo appropriato.
• WantedBy nell'Install section dice a systemd quale "target" (vedi man systemd.target) richiama il servizio quando lo abiliti usando systemctl enable.
• Restart definisce in quali circostanze systemd riavvierà automaticamente il servizio. Ci sono più opzioni relative al riavvio, che potresti voler cambiare o meno; vedere la pagina man di systemd.service.

Prova man 5 crontab . Se il tuo crontab è supportato, dovresti vedere @reboot, @yearly, @monthly,.,,,

allora prova ad aggiungere un po' di sonno per un momento può aiutarti.

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

Controlla la catena critica per crond.service, come richiesto e risposto in questo post di StackExchange

Inoltre, fai riferimento a questo articolo di FreeDesktop che affronta questo problema.

In generale, systemd è configurato per avere dipendenze molto limitate, avviando molti demoni in parallelo per ridurre il tempo impiegato per l'avvio. I servizi che non dipendono necessariamente dal fatto che la rete sia completamente attiva e funzionante avranno esito negativo se sono presenti componenti che presuppongono che la rete sia in uno stato stabile. Errori come questo possono essere difficili da diagnosticare, ma usando systemd-analyze critical-chain e journalctl -xel l'output può portarti alla causa principale del tuo problema.