Recevoir un email après le redémarrage d’un serveur Linux avec systemd

Un serveur qui redémarre sans prévenir, c’est rarement anodin. Cela peut venir d’une maintenance planifiée, d’un kernel fraîchement installé, d’un crash, d’une coupure électrique, d’un watchdog un peu nerveux ou d’un humain qui a tapé reboot avec la sérénité d’un moine tibétain.

Dans tous les cas, recevoir un email après le redémarrage d’un serveur Linux permet de réagir rapidement. C’est simple, fiable, et cela donne un premier signal avant même d’ouvrir les graphes de monitoring.

Dans ce guide, nous allons créer une notification email automatique au boot avec systemd, mailutils et un script Bash propre. L’objectif : recevoir un message après chaque reboot avec le nom du serveur, la date, l’uptime, les adresses IP et quelques informations utiles.

Pourquoi envoyer un email après un redémarrage serveur ?

Une alerte de reboot sert à confirmer qu’un serveur est revenu en ligne. Cependant, elle sert aussi à repérer des redémarrages non prévus.

C’est utile pour :

• surveiller un serveur dédié ou un VPS ;
• valider une maintenance après mise à jour du noyau ;
• détecter un redémarrage imprévu ;
• suivre plusieurs serveurs sans se connecter partout ;
• garder une trace simple dans une boîte mail d’administration ;
• compléter un monitoring plus sérieux comme Uptime Kuma, Netdata ou Zabbix.

Ce n’est pas un remplacement du monitoring. C’est une alerte légère, immédiate et facile à auditer. Bref, le petit voyant rouge qui évite parfois une grosse matinée café noir.

Pourquoi utiliser systemd plutôt que cron ou rc.local ?

Historiquement, on utilisait souvent @reboot dans cron ou un script dans rc.local. Cela peut encore fonctionner. Pourtant, sur un serveur Linux moderne, systemd est plus propre.

Avec systemd, vous pouvez :

• définir clairement quand le script doit se lancer ;
• attendre que le réseau soit disponible ;
• attendre que Postfix soit démarré ;
• consulter les logs avec journalctl ;
• relancer le service manuellement pour tester ;
• activer ou désactiver le mécanisme proprement.

Un service systemd oneshot est donc parfait pour cette tâche : il s’exécute une fois au démarrage, envoie l’email, puis s’arrête.

Pré-requis

Avant de commencer, vérifiez que vous avez :

• un serveur Debian ou Ubuntu ;
• un accès SSH avec sudo ou root ;
• systemd comme gestionnaire de services ;
• un outil d’envoi email en ligne de commande ;
• un MTA local, par exemple Postfix, ou un relais SMTP configuré ;
• une adresse email de destination.

Si votre serveur envoie déjà correctement des emails système, vous êtes presque arrivé. Sinon, commencez par vérifier votre configuration mail, SPF, DKIM et DMARC. J’ai détaillé ce sujet ici : configurer SPF, DKIM et DMARC avec Postfix et OpenDKIM.

Installer mailutils

Sur Debian ou Ubuntu, installez mailutils :

sudo apt update
sudo apt install mailutils

Si Postfix n’est pas encore installé, l’assistant peut vous proposer une configuration. Pour un serveur qui envoie des emails via son propre MTA, choisissez généralement “Internet Site”, puis renseignez le nom de domaine du serveur.

Ensuite, testez l’envoi d’un email simple :

printf 'Test email depuis %s\n' "$(hostname -f)" | mail -s "Test email serveur" admin@example.comCode language: JavaScript (javascript)

Remplacez admin@example.com par votre vraie adresse. Si cet email n’arrive pas, ne continuez pas tout de suite. Corrigez d’abord l’envoi mail, sinon le service systemd fonctionnera parfaitement… pour envoyer dans le vide. Une grande tradition de l’informatique.

Créer le script d’envoi d’email

Nous allons placer le script dans /usr/local/sbin, qui convient bien aux scripts d’administration locaux.

sudo nano /usr/local/sbin/send-reboot-email

Ajoutez ce contenu :

#!/usr/bin/env bash

set -euo pipefail

readonly TO="admin@example.com"
readonly HOSTNAME_FQDN="$(hostname -f 2>/dev/null || hostname)"
readonly HOSTNAME_SHORT="$(hostname -s 2>/dev/null || hostname)"
readonly SUBJECT="[${HOSTNAME_SHORT}] Serveur redémarré"
readonly BOOT_TIME="$(uptime -s 2>/dev/null || who -b | awk '{print $3, $4}')"
readonly CURRENT_DATE="$(date --iso-8601=seconds)"
readonly KERNEL="$(uname -r)"

get_ip_addresses() {
  hostname -I 2>/dev/null | tr ' ' '\n' | sed '/^$/d' || true
}

get_last_boots() {
  last -x reboot -n 5 2>/dev/null || true
}

get_failed_units() {
  systemctl --failed --no-pager 2>/dev/null || true
}

BODY="$(cat <<EOF
Le serveur ${HOSTNAME_FQDN} vient de redémarrer.

Date de l'alerte : ${CURRENT_DATE}
Dernier boot    : ${BOOT_TIME}
Kernel          : ${KERNEL}

Adresses IP :
$(get_ip_addresses)

Derniers redémarrages :
$(get_last_boots)

Unités systemd en échec :
$(get_failed_units)

---
Message envoyé automatiquement par systemd depuis ${HOSTNAME_FQDN}.
EOF
)"

printf '%s\n' "${BODY}" | /usr/bin/mail -s "${SUBJECT}" "${TO}"Code language: PHP (php)

Modifiez la ligne suivante avec votre adresse :

readonly TO="admin@example.com"Code language: JavaScript (javascript)

Rendez le script exécutable et limitez ses permissions :

sudo chown root:root /usr/local/sbin/send-reboot-email
sudo chmod 750 /usr/local/sbin/send-reboot-email

Ce script inclut volontairement des informations utiles, mais pas sensibles. Évitez d’envoyer des secrets, des tokens, des variables d’environnement complètes ou des journaux verbeux par email. Une alerte doit informer, pas fuiter votre serveur sur un plateau.

Tester le script manuellement

Avant de créer le service systemd, testez le script directement :

sudo /usr/local/sbin/send-reboot-email

Si l’email arrive, parfait. Sinon, consultez les logs mail :

sudo tail -n 100 /var/log/mail.logCode language: JavaScript (javascript)

Sur certaines distributions ou configurations, les logs passent surtout par journald :

sudo journalctl -u postfix -n 100 --no-pager

Vérifiez aussi que la commande mail existe bien :

command -v mail

Créer le service systemd

Créez maintenant un service systemd dédié :

sudo nano /etc/systemd/system/reboot-email.service

Ajoutez ce contenu :

[Unit]
Description=Envoyer un email après le redémarrage du serveur
Documentation=https://www.skyminds.net/
Wants=network-online.target
After=network-online.target postfix.service
Requires=postfix.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/send-reboot-email

[Install]
WantedBy=multi-user.targetCode language: JavaScript (javascript)

Cette unité attend network-online.target et Postfix. C’est pertinent si l’email doit partir vers l’extérieur après le boot. Le service postfix.service est aussi déclaré comme dépendance stricte avec Requires=postfix.service.

Si vous utilisez un autre MTA, adaptez la ligne postfix.service. Par exemple, selon votre configuration, vous pourriez dépendre de exim4.service, msmtp via une configuration utilisateur, ou d’un service SMTP local différent.

Si vous n’avez pas de MTA local et utilisez seulement un outil SMTP externe, retirez la dépendance Requires=postfix.service et gardez surtout l’attente réseau.

Activer le service au démarrage

Rechargez systemd :

sudo systemctl daemon-reload

Activez le service au boot :

sudo systemctl enable reboot-email.serviceCode language: CSS (css)

Puis lancez-le une fois manuellement pour vérifier son comportement sous systemd :

sudo systemctl start reboot-email.serviceCode language: CSS (css)

Contrôlez son état :

sudo systemctl status reboot-email.service --no-pagerCode language: CSS (css)

Et consultez les logs :

sudo journalctl -u reboot-email.service -n 100 --no-pagerCode language: CSS (css)

Tester après un vrai redémarrage

Quand le test manuel fonctionne, vous pouvez redémarrer le serveur :

sudo reboot

Après reconnexion SSH, vérifiez que le service a bien tourné :

sudo systemctl status reboot-email.service --no-pager
sudo journalctl -u reboot-email.service -b --no-pagerCode language: CSS (css)

L’option -b limite les logs au boot courant. C’est très pratique pour éviter de relire l’histoire complète du serveur depuis l’âge du bronze.

Comprendre network.target et network-online.target

La différence est importante.

• network.target indique surtout que la pile réseau a été démarrée.
• network-online.target sert à attendre que le réseau soit considéré comme disponible.

Pour envoyer un email vers l’extérieur au boot, network-online.target est généralement plus adapté. Cependant, il peut ralentir légèrement le démarrage si le réseau tarde à se configurer.

Vérifiez quel service d’attente réseau est actif :

systemctl is-enabled NetworkManager-wait-online.service systemd-networkd-wait-online.serviceCode language: CSS (css)

Sur un serveur Debian avec systemd-networkd, vous verrez souvent systemd-networkd-wait-online.service. Sur une machine avec NetworkManager, ce sera plutôt NetworkManager-wait-online.service.

Si votre email part via un Postfix local qui met simplement le message en queue, vous pouvez parfois vous contenter d’attendre Postfix. Toutefois, pour une alerte utile immédiatement après reboot, attendre le réseau évite bien des faux départs.

Variante : envoyer via msmtp plutôt que Postfix

Sur un petit VPS, vous ne voulez pas toujours maintenir un Postfix complet. Vous pouvez utiliser msmtp comme client SMTP léger, avec un relais externe.

Installez les paquets :

sudo apt update
sudo apt install msmtp msmtp-mta mailutils

Ensuite, configurez /etc/msmtprc selon votre fournisseur SMTP. Protégez ce fichier, car il peut contenir des identifiants :

sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc

Dans ce cas, adaptez le service systemd pour retirer la dépendance Postfix :

[Unit]
Description=Envoyer un email après le redémarrage du serveur
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/send-reboot-email

[Install]
WantedBy=multi-user.targetCode language: JavaScript (javascript)

Cette variante est intéressante si le port 25 sortant est bloqué par votre hébergeur, ce qui arrive souvent sur les VPS récents.

Ajouter un expéditeur personnalisé

Selon votre configuration mail, vous pouvez définir une adresse d’expédition avec l’option -r de mail.

Dans le script, remplacez la dernière ligne par :

printf '%s\n' "${BODY}" | /usr/bin/mail -r "server@example.com" -s "${SUBJECT}" "${TO}"Code language: JavaScript (javascript)

Utilisez une adresse appartenant à un domaine que vous contrôlez. Ensuite, assurez-vous que SPF, DKIM et DMARC autorisent bien cet envoi. Sinon, votre email d’alerte risque de finir dans le dossier spam, ce qui est légèrement contre-productif pour une alerte.

Ajouter une ligne de log dédiée

systemd conserve déjà les logs du service. Toutefois, vous pouvez aussi écrire une trace simple dans syslog avec logger.

Ajoutez cette ligne avant l’envoi dans le script :

logger -t reboot-email "Envoi de l'alerte reboot vers ${TO} depuis ${HOSTNAME_FQDN}"Code language: JavaScript (javascript)

Vous pourrez ensuite filtrer les logs :

journalctl -t reboot-email --no-pager

Diagnostic : l’email n’arrive pas

Si vous ne recevez rien après reboot, procédez dans cet ordre.

1. Tester le script seul

sudo /usr/local/sbin/send-reboot-email

Si cette commande échoue, le problème vient du script ou de l’envoi email, pas de systemd.

2. Tester le service systemd

sudo systemctl start reboot-email.service
sudo systemctl status reboot-email.service --no-pagerCode language: CSS (css)

Si le script fonctionne seul mais pas via systemd, vérifiez le chemin complet des commandes et les permissions. systemd n’exécute pas vos scripts avec le même environnement qu’un shell interactif.

3. Lire les logs du service

sudo journalctl -u reboot-email.service -b --no-pagerCode language: CSS (css)

4. Lire les logs mail

sudo tail -n 100 /var/log/mail.log
sudo journalctl -u postfix -n 100 --no-pagerCode language: JavaScript (javascript)

5. Vérifier la queue Postfix

mailq

Si les messages restent en queue, Postfix accepte l’email localement mais n’arrive pas à le livrer. Dans ce cas, cherchez les erreurs DNS, TLS, authentification SMTP, reverse DNS ou blocage du port 25.

Erreurs fréquentes

Utiliser un chemin relatif dans le service

Dans un service systemd, utilisez des chemins absolus. Préférez /usr/local/sbin/send-reboot-email à ./send-reboot-email.sh.

Oublier systemctl enable

systemctl start lance le service maintenant. systemctl enable l’active au démarrage. Les deux commandes ne font pas le même travail.

Attendre network.target au lieu de network-online.target

network.target ne garantit pas que votre serveur a une connectivité utilisable. Pour un envoi email externe au boot, network-online.target est généralement plus sûr.

Tester uniquement après reboot

Testez d’abord le script, puis le service, puis seulement le reboot complet. Cela évite de transformer chaque essai en mini-maintenance.

Envoyer trop d’informations sensibles

Un email peut être transféré, indexé, mal filtré ou compromis. Gardez le contenu utile, mais sobre. Pas de mots de passe, pas de tokens, pas de dump complet de configuration.

Variante : recevoir aussi une alerte avant arrêt

Recevoir un email avant arrêt est possible, mais moins fiable qu’une alerte après reboot. Lors d’un shutdown, le réseau, le DNS ou Postfix peuvent déjà être en cours d’arrêt.

Si vous voulez suivre les arrêts propres, utilisez plutôt les logs systemd, l’historique last -x, ou un vrai monitoring externe. Une alerte envoyée après retour en ligne est plus fiable, car le serveur a déjà récupéré ses services essentiels.

last -x shutdown reboot -n 10

Cette commande donne déjà un historique utile des redémarrages et arrêts.

Aller plus loin : compléter avec un monitoring externe

L’email après reboot confirme que le serveur est revenu. En revanche, il ne vous dit pas si le site répond correctement, si MySQL tourne, si PHP-FPM sature ou si le disque est presque plein.

Pour une supervision plus complète, combinez cette alerte avec :

• un monitoring HTTP externe ;
• une alerte disque ;
• une alerte charge CPU et mémoire ;
• une surveillance des services critiques ;
• des sauvegardes testées ;
• des logs centralisés.

Si votre serveur héberge WordPress, WooCommerce, des emails ou plusieurs sites clients, cette notification doit devenir une petite brique dans une stratégie plus large de maintenance serveur.

Pour aller plus loin sur l’administration serveur

Si vous automatisez les alertes système, ces guides complètent bien la maintenance d’un serveur Linux qui héberge des sites WordPress ou des services mail.

• Configurer SPF, DKIM et DMARC avec Postfix et OpenDKIM
• Mettre à jour WordPress en SSH avec WP-CLI
• Installer Nginx, PHP et MariaDB sur Debian
• Configurer un serveur mail avec Postfix et des domaines virtuels
• WordPress : bonnes permissions fichiers avec chown et chmod

FAQ

Puis-je utiliser cron avec @reboot à la place de systemd ?

Oui, mais systemd est plus propre pour gérer les dépendances, les logs, l’ordre de démarrage et les tests manuels. Pour un serveur moderne, préférez un service oneshot.

Pourquoi mon email n’est-il pas envoyé après reboot ?

Le plus souvent, le script se lance trop tôt, Postfix n’est pas prêt, le réseau n’est pas encore disponible, ou l’envoi mail local n’est pas correctement configuré. Testez d’abord le script, puis le service systemd.

Faut-il attendre network-online.target ?

Oui, si l’email doit partir vers un serveur externe dès le démarrage. Si vous utilisez Postfix localement et acceptez que l’email parte plus tard depuis la queue, attendre Postfix peut suffire.

Puis-je envoyer une alerte avant l’arrêt du serveur ?

C’est possible, mais moins fiable. Au shutdown, le réseau et le service mail peuvent déjà être en cours d’arrêt. Une notification après reboot est généralement plus robuste.

Le script fonctionne en SSH, mais pas avec systemd. Pourquoi ?

systemd utilise un environnement plus minimal qu’un shell interactif. Utilisez des chemins absolus, vérifiez les permissions et consultez journalctl -u reboot-email.service.

Cette méthode remplace-t-elle un monitoring serveur ?

Non. Elle complète le monitoring. Elle confirme qu’un serveur a redémarré, mais elle ne surveille pas toute la disponibilité applicative, les performances ou l’état des services métier.

Conclusion

Recevoir un email après le redémarrage d’un serveur Linux est simple à mettre en place avec systemd. Un script Bash propre, un service oneshot, une dépendance réseau claire et quelques tests suffisent.

Cette alerte ne remplace pas une vraie supervision, mais elle donne un signal immédiat et utile. Elle vous dit : “le serveur est revenu, voici son état de base”. Pour une maintenance serveur, c’est une petite automatisation qui rend de grands services.

Et franchement, entre découvrir un reboot par email et le découvrir parce qu’un client vous demande pourquoi son site tousse, le choix est assez vite fait.

Sources

• systemd : Running Services After the Network Is Up
• Debian Wiki : systemd services
• systemd.service manual
• systemd.unit manual
• Debian manpage : mailutils mail
• Postfix : Basic Configuration

Report a typo