#!/bin/sh
# ☠️☠️ POURQUOI CETTE GARDE EXISTE — mesure du 19/08, au demarrage de l'appareil.
#
#   clatd cherche son lien par « ip -6 route get 64:ff9b:: ». Quand la route du
#   prefixe n'est pas encore posee, la question retombe sur la route par defaut,
#   c'est-a-dire le Wi-Fi. Le journal le dit mot pour mot :
#
#     22:06:20  clatd: Device facing the PLAT: wlan0
#     22:06:20  clatd: Using CLAT IPv6 address: 2a01:e0a:ebb:a8c0:...  <- la Freebox
#
#   Le CLAT etait alors MONTE ET MUET : tun cree, route « default dev clat »
#   posee, TAYGA demarre — et rien a traduire, la Freebox n'ayant aucun NAT64.
#   Aucune erreur, aucun service en rouge. C'est le mode d'echec que ce depot
#   traque partout : un code de retour vert sur un systeme qui ne fait rien.
#
# 🔑 « 40-joyeuse-nat64-route » repare la cause (la route existe avant que
#   « 50-clatd » ne relance clatd). Cette garde-ci repare le RESTE : tout ce qui
#   relance clatd sans passer par un evenement reseau — le demarrage de Waydroid,
#   une relance a la main, un lien mobile qui revient apres le choix.
#
# ⛔ ELLE NE DEMARRE JAMAIS clatd, et c'est la decision du 19/08 : le CLAT ne
#   sert qu'au conteneur Android, donc il ne s'allume qu'avec Waydroid. La garde
#   sort tout de suite si clatd ne tourne pas, et n'emploie que « try-restart »,
#   qui ne touche que ce qui tourne deja.
#
# ⚠️ ELLE DETACHE SON TRAVAIL. NetworkManager tue un script de dispatcher qui
#   depasse son delai, et il faut attendre que le « restart --no-block » de
#   50-clatd ait fini avant de pouvoir juger de son resultat.

[ "$2" = "up" ] || [ "$2" = "down" ] || exit 0

# Le tun du CLAT est lui-meme une interface : sans ce garde, chaque relance de
# clatd rappellerait cette garde, qui relancerait clatd. Meme protection que le
# dispatcher amont 50-clatd.
[ "${DEVICE_IFACE:-}" = "clat" ] && exit 0

systemd-run --no-block --collect \
	--unit=joyeuse-clat-garde-"$(date +%s)" \
	/usr/libexec/joyeuse-clat-garde

exit 0
