@reboot ne fonctionne pas dans CRON

Jetez un œil à la page de manuel systemd.service. Il décrit comment configurer systemd pour gérer un service. Je suis sûr que vous trouverez des exemples pour votre système dans /usr/lib/systemd/system ou des chemins similaires.

Dans votre cas, le service ressemblerait un peu à ceci :

[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

Mettez ceci dans un fichier /etc/systemd/system/unturned.service . Ensuite, exécutez systemctl daemon-reload (une fois, et chaque fois que vous modifiez unturned.service pour indiquer à systemd de relire la configuration) et systemctl start unturned.service pour démarrer le serveur de jeu.

Si cela fonctionne comme prévu, vous pouvez utiliser systemctl enable unturned.service pour s'assurer qu'il démarre au démarrage.

Quelques notes sur les options utilisées :

• Si start.sh n'est pas censé s'exécuter en tant qu'utilisateur/groupe steam , modifiez-le de manière appropriée.
• WantedBy dans le Install section indique à systemd quelle "cible" (voir man systemd.target) attire le service lorsque vous l'activez à l'aide de systemctl enable.
• Restart définit dans quelles circonstances systemd redémarrera automatiquement le service. Il existe d'autres options liées au redémarrage, que vous pouvez ou non vouloir modifier. consultez la page de manuel systemd.service.

Essayez man 5 crontab . Si votre crontab est pris en charge, vous devriez voir @reboot, @yearly, @monthly,.,,,

puis essayez d'ajouter un peu de sommeil pour un moment peut aider.

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

Vérifiez la chaîne critique pour crond.service, comme demandé et répondu dans ce post StackExchange

Consultez également cet article FreeDesktop traitant de ce problème.

En général, systemd est configuré pour avoir des dépendances très limitées, démarrant de nombreux démons en parallèle pour réduire le temps passé à démarrer. Les services qui ne dépendent pas nécessairement du fait que le réseau est entièrement opérationnel et fonctionnel échoueront s'il existe des composants qui supposent que le réseau est dans un état stable. Des pannes comme celle-ci peuvent être difficiles à diagnostiquer, mais en utilisant systemd-analyze critical-chain et journalctl -xel la sortie peut vous conduire à la cause première de votre problème.