Empêcher la mise en veille sur un serveur Debian

Bonjour,

Un serveur doit être disponible 24 heures sur 24 et ne doit évidemment pas se mettre en veille, surtout si nous ne disposons pas d’outils pour le « réveiller ».

Par défaut ou suite à l’installation de certains paquets, une distribution Debian peut conserver des réglages d’économie d’énergie. Résultat : notre machine « s’endort » après une période d’inactivité et nous ne pouvons plus y accéder à distance. ¹

C’est le cas notamment pour des systèmes installés dans une version Desktop (= avec le gestionnaire de bureau, type GNOME ou autre).

C’est ballot quand il s’agit d’un serveur, n’est-ce pas ?

Voici comment empêcher la mise en veille au niveau système.

Nous ne nous servons que de la ligne de commande. ²

La configuration classique par l’interface graphique ne suffit pas (et peut être trompeuse)

#

Sur Debian, la gestion de l’énergie est multi-couche.

Désactiver la mise en veille dans une interface graphique ou via un simple script ne suffit pas toujours, car plusieurs services peuvent déclencher un événement suspend :

• Les cibles systemd qui orchestrent la transition vers les états de sommeil.
• systemd-logind qui réagit aux événements matériels (bouton power, bouton de réinitialisation, inactivité…).

Pour une machine de production, nous pouvons mettre en place le masking des outils de mise en veille pour les rendre inaccessibles même au système.

Masquer les services de mise en veille

#

Plutôt que de simplement désactiver (disable) les services associés à la mise en veille, nous les masquons (mask) pour empêcher l’accès.

Nous utilisons la commande mask (plutôt que disable). Elle crée un lien symbolique vers /dev/null, ce qui rend impossible l’activation du service, même si un autre processus le demande.

Pour ce faire, nous exécutons : ³

1

systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target systemd-suspend.service systemd-hibernate.service systemd-hybrid-sleep.service systemd-suspend-then-hibernate.service

Pour confirmer que les cibles sont bien verrouillées :

1

systemctl list-unit-files | grep -E 'sleep|suspend|hibernate'

Exemple de sortie :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

systemd-hibernate-clear.service          static   -
systemd-hibernate-resume.service         static   -
systemd-hibernate.service                masked   enabled
systemd-hybrid-sleep.service             masked   enabled
systemd-suspend-then-hibernate.service   masked   enabled
systemd-suspend.service                  masked   enabled
hibernate.target                         masked   enabled
hybrid-sleep.target                      masked   enabled
sleep.target                             masked   enabled
suspend-then-hibernate.target            masked   enabled
suspend.target                           masked   enabled

Configurer systemd-logind

#

Même si les cibles sont masquées et donc inaccessibles, nous pouvons configurer le gestionnaire de sessions (systemd-logind = login daemon) pour qu’il n’essaie pas d’interpréter les signaux d’inactivité ou les boutons physiques… Deux précautions valent mieux qu’une.

Nous éditons le fichier de configuration :

1

nano /etc/systemd/logind.conf

Nous modifions et / ou décommentons les lignes suivantes pour forcer l’état ignore :

1
2
3
4
5
6

[Login]
HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
LidSwitchIgnoreInhibited=no
IdleAction=ignore

Nous redémarrons le service pour appliquer les changements :

1

systemctl restart systemd-logind

Analyser les journaux

#

Deux commandes peuvent être utiles pour auditer les logs du serveur :

Pour consulter les événements de systemd-logind :

1

journalctl -u systemd-logind --since "1 hour ago"

Pour les changement d’états ACPI au niveau du noyau :

1

journalctl -k | grep -i "ACPI: PM"

Cette commande permet de voir si le noyau a effectivement préparé un passage en état S3 (veille en RAM) ou S4 (hibernation).

Conclusion

#

En combinant le masquage des cibles systemd et la neutralisation des actions dans logind.conf, nous éliminons tout risque de mise en veille accidentelle de notre serveur Debian. ⁴

C’est une étape de durcissement (hardening) à laquelle il vaut mieux veiller AVANT d’être dans la mouise.

Au plaisir,

Marc JESTIN
https://marcjestin.fr