@reboot no funciona en CRON

Eche un vistazo a la página de manual de systemd.service. Describe cómo configurar systemd para administrar un servicio. Estoy seguro de que encontrará ejemplos para su sistema en /usr/lib/systemd/system o caminos similares.

En su caso, el servicio se vería algo así:

[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

Pon esto en un archivo /etc/systemd/system/unturned.service . Luego ejecuta systemctl daemon-reload (una vez y siempre que cambie unturned.service para decirle a systemd que vuelva a leer la configuración) y systemctl start unturned.service para iniciar el servidor del juego.

Si eso funciona como se esperaba, puede usar systemctl enable unturned.service para asegurarse de que se inicia en el arranque.

Algunas notas sobre las opciones utilizadas:

• Si no se supone que start.sh se ejecute como usuario/grupo steam , edite apropiadamente.
• WantedBy en el Install La sección le dice a systemd qué "objetivo" (ver man systemd.target) atrae el servicio cuando lo habilita usando systemctl enable.
• Restart define bajo qué circunstancias systemd reiniciará automáticamente el servicio. Hay más opciones relacionadas con el reinicio, que puede o no desear cambiar; consulte la página man de systemd.service.

Prueba man 5 crontab . Si su crontab es compatible, debería ver @reboot, @yearly, @monthly,.,,,

entonces intente agregar algo de sueño por un momento puede ayudar.

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

Verifique la cadena crítica para crond.service, como se preguntó y respondió en esta publicación de StackExchange

Además, consulte este artículo de FreeDesktop que aborda este problema.

En general, systemd está configurado para tener dependencias muy limitadas, iniciando muchos demonios en paralelo para reducir el tiempo de arranque. Los servicios que no dependen necesariamente de que la red esté completamente activa y funcional fallarán si hay componentes que asumen que la red se encuentra en un estado estable. Las fallas como esta pueden ser difíciles de diagnosticar, pero usando systemd-analyze critical-chain y journalctl -xel la salida puede llevarlo a la causa raíz de su problema.