Je suis à 99% sûr que c'est parce que vous n'avez pas appelé l'interpréteur dans le script.

/etc/rc.local:

#!/bin/bash

IP=$(/sbin/ip route get 1 | awk '{print $NF;exit}')
echo "IP: $IP" > /etc/issue

exit 0

Cela devrait probablement fonctionner. Beaucoup de gens mentionnent également explicitement bash dans leur fichier système; j'ai modifié votre fichier de service. Je mentionne ceci ci-dessous, mais 4 des paramètres ne sont pas nécessaires (à ma connaissance) et je les ai également supprimés ici :

/etc/systemd/system/rc-local.service:

[Unit]
Description=Compatibilité avec /etc/rc.local

[Service]
Type=oneshot
ExecStart=/bin/bash /etc/rc.local

[Install]
WantedBy=multi-user.target

Vous devriez également utiliser le chemin complet de awk, mais cela générerait une erreur différente - vous n'êtes pas encore allé si loin dans le script.

Si cela n'a pas corrigé le problème, vous devrez procéder étape par étape et voir ce qui fonctionne individuellement. L'environnement systemd est très limité (similaire aux choses lancées depuis cron, mais avec moins d'environnement). Des choses qui fonctionnent toujours cessent de fonctionner en raison d'un paramètre environnemental qui est toujours défini, donc nous oublions que cela doit même être défini. Essayez d'isoler un problème lié à cela. Voici quelques étapes d'isolation :

1. Exécutez directement (avec sudo ou dans un shell root pour chaque étape) /etc/rc.local depuis un terminal.

2. Si cela fonctionne, essayez de l'exécuter comme env -i /etc/rc.local. Si cela ne fonctionne pas, vous pouvez essayer de passer des valeurs environnementales une par une, ou avoir votre script qui les force à être définies (fortement déconseillé, mais si vous en avez envie, vous pourriez mettre la sortie de env dans un shell 'normal', env | sed 's/^/export /g' | sed 's/=/='/g' | sed -e 's/$/'/g' > env_values.sh et définir explicitement ces valeurs dans le script.. Vous devez nettoyer un peu la liste - elle aura des valeurs de connexion ssh et d'autres entrées déclenchées par des événements qui ne casseraient probablement rien mais n'aideront certainement pas).

3. Si ce n'est pas ça car peu importe comment vous exécutez rc.local, cela fonctionne simplement, je simplifierais votre fichier de service systemd. Essayez sans eux.

   • La configuration reste après la définition de sortie n'est pas pertinente ici - cela concerne l'utilisation de ceci pour appeler un script unique qui lance des démons.
   • Le paramètre tty est un cas très spécial, et n'est pas nécessaire.
   • Le paramètre de délai d'attente de 0 peut entraîner des systèmes bloqués lors des cycles de mise sous tension.
   • La priorité de démarrage de SysV est obsolète sur systemd ver > 218+; arch est sur au moins la ver 229.

4. Essayez d'utiliser un @reboot cronjob. Environnement très similaire, mais je le trouve moins 'capricieux'. @reboot remplace la méthode normale des 5 astérisques pour le timing (par exemple au lieu de 0 0 0 * * vous mettez simplement @reboot), et votre script sera appelé à chaque démarrage. Si vous avez besoin d'aide supplémentaire pour configurer un cronjob je peux certainement fournir plus de détails.

Je ne vois aucun problème avec votre méthode pour obtenir votre IP lan. Voici une méthode différente à essayer si cela pose des problèmes. Le vôtre est probablement meilleur. il a moins de dépendances et certainement plus propre, mais j'utilise cette approche depuis des années sans problème :

iprgx='(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)'
cat /etc/hostname | /usr/bin/host -4r | grep -Eo "$iprgx"

Si tout cela échoue, vous devrez lire la documentation de systemd... ce qui, comme vous l'avez probablement découvert, est très long en termes de mots et incroyablement pauvre en informations spécifiques. Faites-moi savoir ce que vous découvrez même si ces idées ne fonctionnent pas - il pourrait y avoir un indice dans les résultats malgré tout.

Mise à jour

Conformément à votre mise à jour, les modifications apportées au service permettent au script de s'exécuter correctement. L'état que vous obtenez est normal pour un événement unique - les services systemd sont vraiment axés sur les processus de démon qui sont lancés, et vous ne faites pas cela - donc (en simplifiant beaucoup), il dit essentiellement qu'il est inactif, ce qui signifie que le script ne fonctionne pas encore, n'est pas prévu pour s'exécuter, et n'a pas lancé de processus que systemd suit - ce qui est correct et acceptable. Le fait qu'il montre qu'il s'est exécuté récemment et qu'il s'est terminé en SUCCESS signifie que cela fonctionne.

Le deuxième problème est le timing relatif. La réponse concise est que vous devrez modifier votre fichier de service en ajoutant les deux entrées suivantes sous [Unit]. Cela pourrait simplement fonctionner. Sinon, lisez la suite.

[Unit]
Wants=network-online.target
After=network-online.target

Il existe un excellent article sur ce problème spécifique sur stackexchange Ils semblent avoir couvert toutes les manières dont cela peut mal tourner et comment cela peut bien se passer de la mauvaise manière... Je ne vais pas essayer de le relayer - obtenez simplement des informations d'un gourou apparent.

Approche alternative qui a l'avantage de rendre les fans de systemd furieux

Si cette approche devient difficile ou impossible pour quelque raison que ce soit, voici une méthode beaucoup moins élégante et brutale à laquelle je me tourne souvent quand ma patience avec systemd est épuisée :

Vous pouvez modifier votre script pour attendre que l'adresse IP devienne disponible elle-même au lieu de vous enliser dans les problèmes de synchronisation précédents / suivants. C'est un hack car il réimplémente délibérément une fonctionnalité qui est intégrée à systemd, mais c'est ce que je ferais probablement.

J'ai mis à jour ce script (essayé de l'exécuter et trouvé quelques problèmes). Celui-ci fonctionne bien sur mon système. J'avais utilisé la syntaxe de la fonction C sur l'appel de sommeil, et oublié en fait de retourner quoi que ce soit de getIP; les deux ont été corrigés.

/etc/rc.local

#!/bin/bash   

iprgx='(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)'

# J'ai mis cela dans une fonction car vous allez boucler dessus.
# l'erreur que vous voyez est due à l'appel ip - je redirige l'erreur vers
# /dev/null pour me débarrasser de cette nuisance.
getIP() {
  echo "IP=$(/sbin/ip route get 1 2>/dev/null | awk '{print $NF;exit}' | grep -Eo "$iprgx")"
}

# chronomètre du watchdog - arrêt s'il ne se résout pas après un certain delta-T
wdTimer=1
IP=$(getIP)
#echo "($wdTimer) IP: $IP"
while [ "$IP" == "" ]; do
  # Il n'y a rien de spécial à propos de 0.5 seconde - cela semblait simplement raisonnable
  sleep 0.5
  IP=$(getIP)
  #echo "($wdTimer) IP: $IP"
  ((wdTimer++))
  # Délai arbitraire de 20 * 0,5 = 10 secondes
  # Vous pouvez le faire attendre aussi longtemps que vous le souhaitez. Je suggère de ne pas
  # régler le temps d'attente trop bas car vous allez fortement solliciter le
  # l'utilitaire ip dans ce cas; pas énorme, peu importe
  # Je l'ai également incité à enregistrer quelque chose dans le syslog - à modifier selon votre convenance
  # avec logger - il existe d'autres façons de le faire.
  if [ "$wdTimer" -gt "20" ]; then
    # temporisé
    logger -s "Temps écoulé en essayant d'acquérir une IP LAN dans rc.local"
    exit 1
  fi
done
#echo "IP: $IP" #> /etc/issue
exit 0

Et oui, j'utilise ce regex $iprgx tout le temps - super utile.