Vous n'êtes pas identifié(e).
Pages : 1
avant l'installation du paquet unattended-upgrades :
Puis, j'installe (--no-install-recommends est dans les préférences globales)
Mais après cela voici l'état du service :
=> Il est actif !
Apparemment c'est à cause de :
en fin d'installation qui doit intervenir après preset
Comment peut-on prévenir cela ?
Merci pour vos réponses.
Hors ligne
et plus précisément de : deb-systemd-helper(1p) — init-system-helpers — Debian Manpages
Pour l'instant, même si c'est la bonne piste,
je ne vois toujours pas comment empêcher l'activation du service...
... à part de le faire manuellement avec :
Hors ligne
Extrait de : dh_systemd_start(1) — debhelper — Debian Manpages
--no-start
Ne démarre pas le fichier unit après les mises à niveau ni après l'installation initiale
(le dernier cas n'est valable que pour les services n'ayant pas de script init correspondant).
REMARQUES
Nota :
Ce programme n'est pas idempotent. Un dh_prep(1) doit être réalisé entre chaque exécution de ce programme (avec les mêmes arguments).
Sinon, il risque d'y avoir plusieurs occurrences des mêmes lignes de code dans les scripts de maintenance du paquet.
Nota :
dh_systemd_start devrait être exécuté après dh_installinit pour pouvoir détecter les scripts init SysV correspondants.
La séquence par défaut de dh les exécute dans le bon ordre et cette remarque n'est valable que lorsque dh_systemd_start est appelé manuellement.
...ça m'a l'air compliqué ce truc en cascade ???
Hors ligne
Hors ligne
Tout ce qui tourne autour de dh_* concerne les mainteneurs de paquets Debian, pas les administrateurs de machines sous Debian.
Je m'en suis rendu compte après coup,
merci.
Hors ligne
et
replacer ce script qui bloque le démarrage de tout nouveau service fraîchement installé :
Du coup lors de l'installation, on a :
=> la dernière ligne montre bien le blocage du démarrage du service.
et l'état le confirme
le service est bien inactif.
Hors ligne
/etc/init.d/unattended-upgrades assure que l'arrêt du système intervient après les MàJ
[Edit]
J'en conclus que c'est probablement le paquet systemd-sysv
qui est responsable du problème.
En fait ça doit être systemd lui même :
Je jette l'éponge
Dernière modification par dezix (11-02-2024 18:10:58)
Hors ligne
Pages : 1