Proposition de feature : mise en veille planifiée

Bonjour
Je ne sais pas trop dans quelle rubrique mettre ce post. A défaut, dans #discuss

J’avais fait une proposition sur github, mais je pense que c’est peut-être tombé dans l’oubli du Néan :smile:

L’idée est de pouvoir planifier l’entrée et sortie de la mise en veille prolongée (hibernation) afin de faire des petites économies d’énergie lorsque le serveur est le moins susceptible d’être utilisé.

Je verrais bien ça dans «Outils > Gestion de l’energie» ou quelque chose du genre.

Avec les paramètres suivants :
Récurent []
→ si oui, deux champs : heure de mise en veille, heure de réveil
→ si non deux champs: date et heure de mise en veille, date et heure de réveil

Qu’en pensez vous ?

Je suis d’accord.

Sur mon NAS actuel, il est possible de définir des horaires d’extinction et d’allumage en fonctions de différents critères, ce qui évite un fonctionnement inutile.
Pourquoi pas stopper la rotation des disques en plus si inutilisés ? Un système de programmation de commandes sur critères ou heures intégrées dans l’interface administrateur ?

Je n’y connais pas grand chose niveau technique, mais même si l’idée est super (mon serveur pourrait être horsqligne 8h/jour sans que ça ne gène personne), j’ai peur que l’implémentation soit un cauchemard.
YunoHost fonctionne sur une ribambelle d’appareils différent, du raspberry avec des disques USB au gros ordinateurs avec un montage de RAID et SSD en passant par les VM gérées par des hébergeurs.
Gérer un système qui marche PARTOUT me parait utopique.

Par contre, si vous conaissez des outils fonctionnels potentiellement intégrables à YunoHost, pointez les :slightly_smiling_face:

2 Likes

Il y a déjà eu un topic à ce sujet peut être en anglais ( il faudrait le retrouver).

La conclusion était que l’extinction rallumage d’un ordinateur physique peux aussi poser des soucis d’usure prématurée de l’électronique. A noter qu’on avait pas de vrai étude sur ce sujet sous la main.

Le sujet a aussi été discuté sur le forum chatons, il parait même que le CIS (un genre de colloc de chercheur sur le numérique) en cause et que c’est un vrai sujet de recherche. Si j’ai bien compris on ne sait pas faire des grosses infras qui s’éteignent et se rallument.

Planifier l’extinction est assez facile (tache cron ou timer systemd), en revanche, gérer le redémarrage c’est plus complexe car ça dépend des options du BIOS. Certains BIOS ont un redémarrage à heure fixe programmable, d’autres un redémarrage quand l’électricité revient , d’autres ont le wake on lan, d’autres rien de tout ça.

Mais donc oui YunoHost pourrait proposer une feature de programmation de l’extinction. En revanche je doute très fortement qu’on puisse gérer le redémarrage depuis l’interface de YunoHost (comme l’explique @Mamie). Pour ce qui est de la rotation des disques, franchement c’est bas level, ça dépend du matos, des disques etc. Le jour où on y arrives il n’y aura plus que des SSD…

2 Likes

C’est en effet complexe de planifier un redémarrage c’est pour cela que je parle de mise en veille prolongée, d’hibernation.
Ca permet d’avoir le minimum d’énergie pour relancer la machine sans être un arrêt total.

Je me dis que «faute de grive on mange des merles»
→ on ne peut pas gérer facilement l’extinction/allumage de la machine et/ou la rotation des disques mais on sait peut être gérer la mise en veille (endormir/réveiller).

Ça permet d’avoir un compromis.

En vrai, je ne sais pas comment ça fonctionne (techniquement) mais je sais qu’il est possible d’ordonner un sleep ou hibernate sur Debian avec la commande sleep (justement)
ça peut, peut-être, valoir le coup d’essayer

J’ai trouvé cet article qui explique comment faire script qui permet de faire un sleep (veille), hibernate, ou freeze

il s’agit en réalité d’option de la commande sleep + freeze pour figer le système

hibernate

sudo sleep 0.1  # To get auth
xflock4
sleep 3
echo disk | sudo tee /sys/power/state  # Requires sufficient swap space

sleep

sudo sleep 0.1  # To get auth
xflock4
sleep 3
echo deep | sudo tee /sys/power/mem_sleep
echo mem | sudo tee /sys/power/state

freeze

sudo sleep 0.1  # To get auth
xflock4
sleep 3
echo freeze | sudo tee /sys/power/state
1 Like

Comme expliqué par ljf, à mon avis le problème est moins de mettre en hibernation/freeze/whatever le serveur que de pouvoir le rallumer automatiquement … ou alors j’ai pas bien compris et le système continue en fait de tourner un peu pendant ce temps et on peut rajouter un sleep 3600; wakeup à la suite des commandes que tu donnes mais ça parrait trop facile pour être vrai

1 Like

Apparemment RTCwake fait exactement ce que je propose

sudo rtcwake -m [type of suspend] -s [number of seconds]
sudo rtcwake -m [type of suspend] -t [specific datetime]

Cette commande permet de suspendre la machine et la réveiller au bout d’un certain temps:

  • standby par défaut si -m n’est pas renseigné, une mise en veille simple, peu d’économie d’énergie, mais restoration rapide

  • mem – Suspendre vers la RAM, économies d’énergie significatives - tout est mis dans un état de faible consommation, à l’exception de la RAM. Le contenu de la mémoire est préservé.

  • disque – Suspendre vers le disque. Le contenu de la mémoire est écrit sur le disque et l’ordinateur ordinateur est éteint. L’ordinateur s’allumera et son état sera restauré à la fin de la minuterie.

  • off – Éteindre totalement l’ordinateur. La page de manuel de rtcwake note que la restauration à partir de “off” n’est pas officiellement prise en charge par la spécification ACPI, mais cela fonctionne quand même avec de nombreux ordinateurs.

  • no - Ne pas mettre en veille immédiatement l’ordinateur. Permet de définir simplement l’heure de réveil. Par exemple, il est possible de dire à l’ordinateur de se réveiller à 6h du matin. Après cela, si on le met en veille manuellement, peu importe l’heure (avant 6h du matin) – dans tous les cas, il se réveillera à 6h du matin.

Du coup, j’imagine que théoriquement, en utilisant rtcwake il est possible de planifier un endormissement et un réveille de nos machines

J’imagine assez la chose comme ceci :
À partir de l’interface proposée

Récurent []
→ si oui, deux champs : heure de mise en veille, heure de réveil
→ si non deux champs: date et heure de mise en veille, date et heure de réveil
[Valider]

Tout est enregistré en base sous forme d’une commande cron qui appelerait rtcwake (en mode root) avec les informations temporelles de réveil (avec possibilité de supprimer/modifier la ligne)

exemple :

Récurent [X]
sommeil : [01:00] réveil : [06h30]
[Valider]

cron (je suis une quiche avec CRON, l’idée est de dire, chaque jour à 1h du matin)

0 1 * * * rtcwake -m mem -t $(date +%s -d ‘tomorrow 06:30’)
4 Likes

RTCWake marche très bien, ouais.

Attention tout de même si tu as des disques durs, pas sûr qu’ils aiment les arrêts/démarrages à répétition (365 cycles par an). En théorie c’est pas non plus trop violent, pas plus qu’éteindre et rallumer son PC tous les jours.

https://crontab.guru/ Enjoy :smiley:

Edit : Attention à ne pas avoir des services ou script qui se lancent (où n’ont pas fini de tourner) pendant les heures d’extinction. Imho si tu commences à jouer avec RTCWake il sera plus prudent de pisser un petit script shell qui check s’il y a une commande yunohost en cours et attend sa fin (ou force son arrêt proprement) avant de mettre la machine en veille.

3 Likes

C’est en effet à prendre en compte @Kit

Merci pour la référence CRON, j’irai compulser ça.