SSD Nodes Learn Hosting plans →
Guides Matt ConnorPar Matt Connor · Mis à jour le 2026-10-31

Pourquoi unattended-upgrades ne fait rien sur Debian

Sur Debian, l’installateur laisse unattended-upgrades désactivé. Activez-le, vérifiez Origins-Pattern et les timers apt-daily, puis confirmez son fonctionnement.

Pourquoi unattended-upgrades ne fait rien sur une nouvelle installation Debian

Sur Debian, unattended-upgrades peut être installé sans jamais exécuter une seule mise à niveau, car l’installation du paquet et son activation sont deux étapes distinctes. Le paquet pose une question debconf avant de se configurer, et sa réponse par défaut est oui. L’installateur Debian pose d’abord une question distincte concernant les mises à jour. Par défaut, les mises à jour automatiques sont désactivées, et ce choix enregistre la réponse false à la question du paquet au cas où celui-ci serait installé ultérieurement. Ubuntu répond à cette même question de l’autre manière, ce qui explique pourquoi le même paquet semble fonctionner sur Ubuntu et sembler défaillant ici.

Rien sur la machine ne l’indique. Aucun message d’erreur ne s’affiche au démarrage, aucun avertissement ne s’affiche à la connexion et aucun fichier journal n’est disponible, car le code qui écrirait ce journal n’est jamais appelé. L’activation se fait avec une seule commande. La suite de ce guide couvre les quatre éléments qui peuvent encore empêcher son fonctionnement : les dépôts à partir desquels il peut effectuer des mises à niveau, le moment où les timers systemd se déclenchent réellement, la façon de savoir si une exécution a échoué et la possibilité pour la machine de redémarrer automatiquement.

Afficher la configuration actuelle avant toute modification

dpkg -l unattended-upgrades | tail -n 1
sudo apt install -y debconf-utils
sudo debconf-show unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

debconf-show affiche la valeur enregistrée pour unattended-upgrades/enable_auto_updates. Un * au début de cette ligne indique qu’une valeur a été définie, au lieu de conserver la valeur par défaut du paquet. Sur une machine installée avec l’installateur Debian, cette valeur a été définie par l’installateur.

cat peut afficher cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory. Cela suffit à expliquer l’absence d’activité : sans fichier, aucune exécution périodique n’est définie et rien n’est donc jamais planifié.

apt-config dump est la commande importante. APT lit les fichiers de /etc/apt/apt.conf.d/ dans l’ordre des noms de fichiers, puis les fusionne. Ainsi, une valeur simple définie dans 99local remplace la même valeur définie dans 20auto-upgrades. Seuls les noms sans extension ou avec une extension .conf sont pris en compte. Un fichier tel que 99local.bak est donc ignoré. Lire un seul fichier vous indique ce qu’il contient. apt-config dump vous indique ce qu’APT exécutera réellement.

Deux clés déterminent si quoi que ce soit s’exécute :

  • APT::Periodic::Update-Package-Lists actualise les listes de paquets, ce que apt update exécute manuellement.
  • APT::Periodic::Unattended-Upgrade exécute la mise à niveau elle-même.

Leurs valeurs ne sont pas des valeurs booléennes. Ce sont des intervalles exprimés en jours. "1" signifie « exécuter cette opération si elle n’a pas été effectuée au cours du dernier jour », "7" signifie une fois par semaine et "0" signifie jamais. APT::Periodic::Unattended-Upgrade "0"; est une configuration valide qui n’exécute rien, indéfiniment, sans générer la moindre erreur. Si votre affichage indique 0 pour cette clé, ou n’affiche aucune clé de ce type, vous avez trouvé la cause.

L’activer : dpkg-reconfigure ou écrire vous-même les clés

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

La question est de priorité basse, c’est pourquoi une installation normale ne l’affiche jamais. dpkg-reconfigure affiche les questions de priorité basse quelle que soit votre priorité debconf configurée ; --priority=low ne fait donc qu’expliciter son comportement actuel. Le seul indicateur à éviter est --default-priority, qui désactive cette fonction et masque à nouveau la question. Répondez oui dans la boîte de dialogue. Le postinst du paquet écrit ensuite /etc/apt/apt.conf.d/20auto-upgrades à partir de votre réponse.

Sur une machine que vous configurez avec un script, aucune boîte de dialogue ne permet de répondre. Définissez donc la réponse au préalable :

echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean true' \
  | sudo debconf-set-selections
sudo dpkg-reconfigure -f noninteractive unattended-upgrades
apt-config dump APT::Periodic

Vous pouvez aussi écrire directement les deux clés :

printf 'APT::Periodic::Update-Package-Lists "1";\nAPT::Periodic::Unattended-Upgrade "1";\n' \
  | sudo tee /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

La modification est immédiatement prise en compte. Le script de configuration du paquet relit ce fichier dans debconf avant de poser sa question. Ainsi, un dpkg-reconfigure ultérieur ou une réinstallation du paquet retrouve votre "1" et le conserve. Il ne reconnaît toutefois que les lignes exactes APT::Periodic::Unattended-Upgrade "1"; et APT::Periodic::Unattended-Upgrade "0";. Si vous choisissez un autre intervalle, par exemple "7", le false enregistré par l’installateur reste actif, et le postinst tente de remplacer le fichier par sa version désactivée. Chaque fois que vous écrivez le fichier manuellement avec autre chose que "1", définissez également la réponse debconf.

C’est la seule différence réelle avec l’autre branche de la famille. Là-bas, l’installateur active le même paquet pour vous. Ainsi, la configuration Ubuntu d’unattended-upgrades part d’un système qui applique déjà ses mises à jour automatiquement et consacre son temps au réglage. Tout ce qui suit s’applique aux deux cas.

Quelles mises à jour Debian installe-t-il réellement pour vous ?

Activer le timer ne revient pas à accepter l’installation de tous les paquets. Chaque source de paquets contient des métadonnées de publication : une origine, un label, une suite, un codename et un site. unattended-upgrades examine la version candidate de chaque paquet pouvant être mis à jour, lit les métadonnées de la source correspondante et installe le paquet uniquement si cette source correspond à une entrée de Unattended-Upgrade::Origins-Pattern ou de l’ancienne liste Unattended-Upgrade::Allowed-Origins. En l’absence de correspondance, aucune mise à jour n’est effectuée. C’est le comportement prévu.

Affichez vos motifs, puis les métadonnées auxquelles ils sont comparés :

apt-config dump Unattended-Upgrade::Origins-Pattern
grep -H -E '^(Origin|Label|Suite|Codename|Components):' /var/lib/apt/lists/*Release
apt-cache policy

grep -H conserve le nom du fichier sur chaque ligne. Vous pouvez ainsi voir à quelle source appartient chaque bloc de métadonnées. Les valeurs de ces champs sont les parties droites de vos motifs. Dans un motif, ${distro_codename} est remplacé au moment de l’exécution par le codename de la release utilisée. Un même fichier reste ainsi valable après une mise à niveau de release.

Lisez vos propres motifs avec ces métadonnées à côté. La réponse à la question « est-ce que je reçois uniquement les correctifs de sécurité, ou aussi les mises à jour des point releases ? » se trouve dans ces deux listes, et nulle part ailleurs :

  • Un motif qui mentionne label=Debian-Security correspond à l’archive de sécurité. C’est là que sont publiés les avis de sécurité Debian.
  • Un motif qui mentionne la suite -updates correspond à stable-updates. Cette suite contient les mises à jour publiées par Debian entre les point releases, par exemple les données de fuseaux horaires.
  • Un motif qui mentionne la suite de la release sans suffixe récupère les changements des point releases dès leur publication. Cela entraîne davantage de changements et davantage de tests de votre côté.
  • Un dépôt que vous avez ajouté vous-même ne correspond à rien tant que vous n’avez pas écrit de motif pour ce dépôt.

Ce dernier point surprend souvent. Un dépôt tiers possède sa propre origine et son propre label. unattended-upgrades voit la version candidate, constate que la source ne correspond à aucun motif, puis passe à la suite. Ajouter un motif pour ce dépôt mérite une décision réfléchie, car un dépôt éditeur peut publier une nouvelle version majeure dans la même suite. Vous acceptez alors les mises à niveau majeures automatiques de ce logiciel pendant la nuit.

unattended-upgrades ne vous fait jamais passer automatiquement d’une version majeure de Debian à la suivante. Il met à jour les paquets de la version que vous utilisez. Le passage d’une version stable à la suivante reste une opération manuelle que vous devez planifier vous-même. Si vous utilisez encore Debian 11, cette opération est en retard : bullseye a perdu le support de sécurité LTS le 31 August 2026. unattended-upgrades peut donc continuer à s’exécuter correctement chaque nuit sans rien de nouveau à installer, tandis que la mise à niveau d’un serveur Debian 11 vers Debian 13 nécessite deux étapes soigneusement planifiées.

Lorsque vous modifiez la liste, souvenez-vous qu’APT ajoute les listes les unes aux autres. Un second bloc Origins-Pattern dans un autre fichier s’ajoute à la liste fournie au lieu de la remplacer. Si vous voulez la remplacer, videz-la d’abord :

#clear Unattended-Upgrade::Origins-Pattern;
Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=${distro_codename},label=Debian-Security";
  "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

Placez vos modifications locales dans un nouveau fichier classé après celui fourni, par exemple /etc/apt/apt.conf.d/52unattended-upgrades-local. 50unattended-upgrades est un fichier de configuration géré. Une fois que vous l’avez modifié, toute mise à niveau ultérieure d’un paquet qui fournit une nouvelle version de ce fichier s’interrompt et vous demande quoi faire de votre version. Un fichier séparé n’entre jamais en conflit.

Deux autres clés méritent d’être affichées pendant que vous y êtes. Unattended-Upgrade::Allowed-Origins est l’ancienne forme du même mécanisme, écrite sous la forme de paires origin:archive. Elle est toujours lue. Une configuration copiée depuis un tutoriel contient donc souvent les deux listes, sans indiquer clairement laquelle a produit la correspondance. Unattended-Upgrade::Package-Blacklist contient des expressions régulières comparées aux noms de paquets. Une expression trop large bloque bien plus de paquets que prévu. La simulation ci-dessous affiche les règles réellement appliquées.

Pourquoi rien ne s’est-il exécuté au moment prévu ?

Deux timers systemd pilotent ce fonctionnement, et ils ont des rôles différents. apt-daily.timer lance apt-daily.service, qui actualise les listes de paquets et télécharge les paquets. apt-daily-upgrade.timer lance apt-daily-upgrade.service, qui appelle unattended-upgrade. Les deux exécutent /usr/lib/apt/apt.systemd.daily avec des arguments différents. Si le second timer est désactivé ou masqué, les deux clés périodiques peuvent lire 1 sans que rien ne soit jamais installé.

systemctl list-timers 'apt-daily*' --all
systemctl is-enabled apt-daily.timer apt-daily-upgrade.timer
systemctl cat apt-daily-upgrade.timer

list-timers vous fournit NEXT, LEFT, LAST et PASSED pour chaque unité. Un timer sans NEXT ne s’exécutera pas. Si is-enabled affiche masked, quelqu’un l’a désactivé de force, et rien de ce que vous écrivez dans apt.conf.d ne changera cela.

Lisez maintenant la section [Timer] affichée par systemctl cat. OnCalendar indique le premier moment auquel le timer peut se déclencher. RandomizedDelaySec ajoute un délai aléatoire après ce moment, afin qu’un parc de machines Debian ne sollicite pas les mêmes miroirs à la même seconde. C’est pourquoi la colonne NEXT affiche une heure qui ne correspond pas à OnCalendar, et pourquoi l’exécution d’hier a eu lieu à une autre minute. Le comportement est conforme à la configuration. Persistent=true signifie qu’une machine éteinte à l’heure planifiée exécute la tâche peu après le prochain démarrage au lieu de sauter la journée.

Pour déplacer la plage horaire, surchargez l’unité au lieu de la modifier :

sudo systemctl edit apt-daily-upgrade.timer
[Timer]
OnCalendar=
OnCalendar=03:30
RandomizedDelaySec=30m

La ligne OnCalendar= vide est nécessaire, car les paramètres d’unité qui acceptent plusieurs valeurs s’accumulent : si vous l’omettez, vous conservez la planification fournie avec le paquet et en ajoutez une deuxième. systemctl edit recharge systemd pour vous. Vérifiez donc le résultat avec systemctl list-timers 'apt-daily*' et consultez le nouveau NEXT.

Vous n’avez jamais besoin d’attendre un timer pour tester tout cela :

sudo systemctl start apt-daily-upgrade.service
journalctl -u apt-daily-upgrade.service --since -1h

Un point déroute les personnes qui cherchent dans /etc/cron.daily : APT fournit toujours /etc/cron.daily/apt-compat pour les systèmes sans systemd. Lisez-le avec cat. Sur un système systemd, il se termine immédiatement. La tâche n’est donc pas exécutée deux fois.

Prouvez que la configuration fonctionne : unattended-upgrade --dry-run --debug

sudo unattended-upgrade --dry-run --debug

La commande est au singulier et le nom du paquet est au pluriel. Debian 12 et 13 fournissent également un /usr/bin/unattended-upgrades. Le pluriel ne se termine donc plus par command not found dans ces versions. Toutefois, la commande documentée, utilisée partout dans ce guide, reste unattended-upgrade.

Cette commande répond à presque toutes les questions du type « pourquoi ce paquet a-t-il été ignoré ? », car elle affiche elle-même les raisons. Vers le début de sa sortie, elle affiche les origines calculées à partir de vos patterns :

Allowed origins are: ...

Elle affiche ensuite une ligne par paquet candidat, avec l’enregistrement d’origine de la version qui serait installée :

Checking: curl ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian' site:'deb.debian.org' isTrusted:True>])

Elle affiche enfin la liste des paquets sur lesquels elle interviendrait ou, sur un serveur où aucune action n’est nécessaire :

No packages found that can be upgraded unattended and no pending auto-removals

En combinant les deux premières sorties, le diagnostic est direct. Recherchez la ligne Checking: correspondant au paquet que vous pensiez voir mettre à niveau. Comparez champ par champ son enregistrement d’origine avec les origines autorisées affichées précédemment. Un seul champ différent, le plus souvent label ou archive, suffit à expliquer pourquoi le paquet a été ignoré.

--dry-run simule les opérations en mémoire et n’installe rien. Vous pouvez donc l’exécuter aussi souvent que nécessaire. La commande ajoute tout de même des entrées à /var/log/unattended-upgrades/unattended-upgrades.log.

Si les origines correspondent mais qu’un paquet reste retenu, vérifiez les points suivants :

  • apt-mark showhold répertorie les paquets que vous ou un outil avez verrouillés. unattended-upgrades ne modifiera pas un paquet retenu.
  • La mise à niveau devrait supprimer ou ajouter un autre paquet. unattended-upgrades évite cette opération, sauf si les clés concernées l’autorisent. Comparez avec sudo apt-get -s upgrade, qui affiche la même décision sans ces règles de sécurité.
  • dpkg est partiellement configuré après une exécution interrompue. Corrigez la situation avec sudo dpkg --configure -a, puis vérifiez à nouveau.
  • /var n’a plus assez d’espace libre. Aucun paquet ne peut donc être téléchargé ou décompressé. Vérifiez avec df -h /var.
  • /boot est rempli d’anciens kernels, ce qui bloque la prochaine mise à niveau du kernel. Vérifiez avec df -h /boot, puis affichez apt-config dump Unattended-Upgrade::Remove-Unused-Kernel-Packages pour voir si le nettoyage est activé.

Si vous exécutez apt manuellement alors que le timer est actif, vous obtenez Could not get lock /var/lib/dpkg/lock-frontend. Ce message indique que unattended-upgrades fonctionne correctement. Attendez la fin de son exécution.

Comment savoir quand une exécution échoue ?

Commencez par les journaux, car ils existent que vous configuriez autre chose ou non :

sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
journalctl -u apt-daily-upgrade.service --since -7d

Le premier fichier est le journal des décisions : ce qui a été vérifié, ce qui a été choisi et ce qui a été installé. Le second contient la sortie brute de dpkg. C’est là qu’apparaît l’échec du script postinst d’un paquet. Un journal d’arrêt distinct apparaît si des mises à niveau s’exécutent pendant l’extinction de la machine.

Le courrier est le moyen de notification habituel :

Unattended-Upgrade::Mail "you@example.com";
Unattended-Upgrade::MailReport "on-change";

MailReport accepte always, on-change et only-on-error. only-on-error semble être le choix le plus rigoureux, mais c’est généralement le mauvais choix sur un serveur auquel personne ne se connecte. En effet, une machine qui a complètement cessé de se mettre à niveau n’envoie plus non plus d’erreurs. Le silence indique alors aussi bien un serveur sain qu’un serveur défaillant. on-change vous envoie un message chaque fois qu’un élément est installé. Le message sert donc aussi de preuve que le timer fonctionne toujours.

Le courrier ne quitte la machine que si celle-ci peut envoyer des messages. unattended-upgrades transmet le message au système de messagerie local. Vous avez donc besoin d’un MTA (mail transfer agent), tel que postfix, ou d’un client relais compatible sendmail, tel que msmtp. Vérifiez-le avec command -v sendmail et command -v mail. Si aucun des deux n’est présent, le rapport n’arrive nulle part, la mise à niveau réussit quand même et l’échec reste totalement invisible. N’oubliez pas non plus qu’une nouvelle adresse IP de VPS n’a aucune réputation d’envoi. Les messages envoyés directement vers une boîte aux lettres publique sont donc souvent classés comme spam. Il est plus fiable de relayer les messages via un fournisseur de messagerie que vous utilisez déjà que d’exécuter votre propre serveur pour cela.

Si vous préférez ne pas utiliser la messagerie, surveillez l’horodatage du journal avec votre outil de monitoring :

stat -c '%y %n' /var/log/unattended-upgrades/unattended-upgrades.log

Un horodatage qui n’a pas changé depuis une semaine signifie que le timer s’est arrêté, quelle que soit la configuration. Ce contrôle doit faire partie du reste de vos contrôles courants de maintenance d’un serveur Linux.

Le serveur doit-il redémarrer automatiquement ?

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Avec Automatic-Reboot réglé sur true, unattended-upgrades redémarre sans confirmation, et uniquement si le fichier /var/run/reboot-required existe une fois l'exécution terminée. Sur Debian 12 et 13, le paquet unattended-upgrades crée lui-même ce marqueur via un hook du noyau, /etc/kernel/postinst.d/unattended-upgrades, qui s'exécute lors de l'installation d'un paquet noyau. Une mise à jour de bibliothèque ne le déclenche pas. Ne partez pas du principe qu'il est présent. Vérifiez après votre prochaine mise à jour du noyau :

ls -l /var/run/reboot-required /var/run/reboot-required.pkgs
uname -r
dpkg -l 'linux-image-*' | grep '^ii'

Si ce fichier n'apparaît jamais sur votre machine, Automatic-Reboot "true" ne se déclenche jamais, et vous pouvez passer des mois à croire que vous redémarrez pour les mises à jour du noyau alors que vous utilisez toujours l'ancien noyau. uname -r par rapport au paquet linux-image le plus récent installé permet de trancher.

Automatic-Reboot-Time planifie le redémarrage à cette heure précise au lieu de l'effectuer immédiatement. Automatic-Reboot-WithUsers réglé sur false ignore le redémarrage si quelqu'un est connecté, ce qui, sur un serveur ayant toujours une session ouverte, signifie qu'il ne redémarre jamais.

La décision concerne ce qui se passe au retour du redémarrage, et non le redémarrage lui-même. Un service démarré manuellement ne revient pas. Un volume chiffré nécessitant une phrase de passe au démarrage ne se monte pas. Deux machines dépendant l'une de l'autre peuvent redémarrer dans le mauvais ordre. Activez le redémarrage automatique pour un serveur web sans état que vous pouvez perdre une minute à 02:00. Désactivez-le là où une intervention humaine est nécessaire, et configurez une alerte sur le fichier marqueur pour qu'une personne choisisse le moment opportun. Entre les deux se trouve needrestart, qui redémarre les services utilisant encore une bibliothèque mise à jour et couvre donc tout, sauf le noyau. Son mode par défaut demande une confirmation avant de redémarrer les services ; lisez donc /etc/needrestart/needrestart.conf avant de vous reposer dessus pour une exécution automatisée.

Cela fonctionne-t-il de la même manière avec testing et unstable ?

Tout ce qui précède concerne Debian stable, où les correctifs de sécurité arrivent depuis une archive distincte avec leur propre label. C’est cette structure qui permet d’exprimer un réglage « mises à jour de sécurité uniquement ». Les autres suites sont conçues différemment. Une configuration copiée depuis un serveur stable correspond donc moins aux attentes de son auteur. Les mises à niveau automatiques sur une suite évolutive entraînent aussi des changements de version majeure sans intervention. C’est un engagement différent. Si vous évaluez cette option, utiliser Debian stable, testing ou unstable sur un serveur présente ce que chacune garantit. Du côté de Red Hat, la même tâche utilise un autre outil et un autre vocabulaire. dnf-automatic sur Rocky Linux et AlmaLinux l’effectue avec son propre timer et son propre fichier de configuration.

Les mises à niveau automatiques réduisent le délai entre la publication d’un correctif et son installation. Elles ne vous indiquent pas ce qui reste exposé. Associez-les donc à une recherche des CVE connues sur votre serveur. CVE signifie common vulnerabilities and exposures. Il s’agit de l’identifiant public sous lequel un correctif est suivi.

Le contrôle en cinq minutes

  1. apt-config dump APT::Periodic affiche les deux clés avec une valeur différente de zéro.
  2. systemctl list-timers 'apt-daily*' affiche une heure NEXT pour les deux timers.
  3. sudo unattended-upgrade --dry-run --debug affiche les origines autorisées qui incluent l’archive de sécurité correspondant à votre nom de code.
  4. sudo systemctl start apt-daily-upgrade.service se termine et l’horodatage de /var/log/unattended-upgrades/unattended-upgrades.log est mis à jour.
  5. Une semaine plus tard, ce même journal indique les paquets qu’il a installés.

La réussite des quatre premiers contrôles signifie que la machine est configurée. La réussite du cinquième signifie que tout fonctionne.

FAQ

Pourquoi Debian installe-t-il unattended-upgrades mais le laisse-t-il désactivé ?

Le paquet pose une question debconf, unattended-upgrades/enable_auto_updates, et écrit /etc/apt/apt.conf.d/20auto-upgrades à partir de la réponse. La valeur par défaut du paquet pour cette question est true. Cependant, la question de l’installateur Debian concernant les mises à jour utilise par défaut l’absence de mises à jour automatiques, et ce choix enregistre false pour la question du paquet. Ainsi, lorsque le paquet est installé plus tard dans le cadre d’une tâche ou comme dépendance, il est configuré pour ne rien faire. Exécutez sudo debconf-show unattended-upgrades pour afficher la réponse enregistrée, puis sudo dpkg-reconfigure --priority=low unattended-upgrades pour la modifier. La question est de priorité basse, donc une installation normale ne l’affiche jamais, mais dpkg-reconfigure affiche par défaut les questions de priorité basse. Elle apparaît donc ici même sans l’option.

Comment tester unattended-upgrades sans attendre le timer ?

Exécutez sudo unattended-upgrade --dry-run --debug. La commande affiche les origines qu’elle acceptera, une ligne Checking: pour chaque paquet pouvant être mis à niveau, avec l’enregistrement de l’origine de ce paquet, ainsi que la liste des paquets qu’elle installerait, sans rien installer. Pour tester le fonctionnement réel, exécutez sudo systemctl start apt-daily-upgrade.service, puis consultez journalctl -u apt-daily-upgrade.service --since -1h avec /var/log/unattended-upgrades/unattended-upgrades.log.

unattended-upgrades installe-t-il aussi les mises à jour standard, en plus des correctifs de sécurité ?

Uniquement si un motif le prévoit. Une mise à niveau de paquet est installée lorsque la source dont elle provient correspond à une entrée de Unattended-Upgrade::Origins-Pattern ou de l’ancien Unattended-Upgrade::Allowed-Origins. L’archive de sécurité, la suite stable-updates et chaque dépôt que vous avez ajouté vous-même sont des entrées distinctes. Affichez apt-config dump Unattended-Upgrade::Origins-Pattern et apt-config dump Unattended-Upgrade::Allowed-Origins sur votre propre machine, puis comparez-les avec grep -H -E '^(Origin|Label|Suite|Codename):' /var/lib/apt/lists/*Release. Le paquet ne vous fait jamais passer d’une version de Debian à une autre.

Pourquoi la mise à niveau ne s’exécute-t-elle pas à l’heure définie dans le timer ?

apt-daily-upgrade.timer définit RandomizedDelaySec en plus de OnCalendar. systemd choisit donc un moment aléatoire dans cette fenêtre au lieu de s’exécuter à l’heure prévue. Cela répartit la charge entre toutes les machines Debian qui utilisent les mêmes miroirs. systemctl list-timers 'apt-daily*' affiche le moment effectivement choisi. Pour déplacer la fenêtre, exécutez sudo systemctl edit apt-daily-upgrade.timer et donnez-lui une ligne OnCalendar= vide, suivie de votre propre valeur.

Dois-je activer le redémarrage automatique pour les mises à jour de sécurité ?

Uniquement lorsqu’un redémarrage imprévu ne pose aucun problème. Unattended-Upgrade::Automatic-Reboot "true" redémarre sans confirmation lorsqu’un fichier /var/run/reboot-required existe après une exécution. Sous Debian 12 et 13, ce marqueur est créé par un hook du noyau fourni avec le paquet unattended-upgrades. Il apparaît donc après une mise à niveau du noyau, mais pas après une mise à niveau de bibliothèque. Vérifiez que le fichier apparaît bien sur votre machine après une mise à niveau du noyau avant de faire confiance à ce réglage. Sur une machine qui demande une phrase secrète au démarrage ou qui exécute des services lancés manuellement, laissez ce réglage à false et déclenchez une alerte sur le fichier marqueur afin qu’une personne choisisse le moment du redémarrage.

Cet article vous a-t-il été utile ?

#debian#unattended-upgrades#apt#systemd#security-updates