logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 11-02-2024 11:19:49

dezix
Membre
Distrib. : Debian stable
Noyau : Linux amd64 (stable)
(G)UI : XFCE4
Inscription : 19-02-2018

SYSTEMD : Preset surchargé par systemd-sysv-install

Bonjour.

Le but recherché est qu'un service fraîchement installé ne soit pas lancé dès la fin de l'installation,
pour (p.ex.) laisser le temps à l'admin du site de configurer le nouveau service avant sa 1ère exécution.

Suivant les indications de :



avant l'installation du paquet unattended-upgrades :


# mkdir -p /etc/systemd/system-preset/

# vim /etc/systemd/system-preset/20-admin.preset

# cat /etc/systemd/system-preset/20-admin.preset
disable unattended-upgrades.service

 



Puis, j'installe (--no-install-recommends est dans les préférences globales)


# apt install --install-recommends unattended-upgrades

The following additional packages will be installed:
  gir1.2-glib-2.0 libgirepository-1.0-1 libglib2.0-0 libglib2.0-data python3-dbus
  python3-distro-info python3-gi shared-mime-info xdg-user-dirs
Suggested packages:
  low-memory-monitor python-dbus-doc bsd-mailx default-mta | mail-transport-agent
  needrestart powermgmt-base
The following NEW packages will be installed:
  gir1.2-glib-2.0 libgirepository-1.0-1 libglib2.0-0 libglib2.0-data python3-dbus
  python3-distro-info python3-gi shared-mime-info unattended-upgrades xdg-user-dirs
0 upgraded, 10 newly installed, 0 to remove and 20 not upgraded.
Need to get 4033 kB of archives.
After this operation, 21.9 MB of additional disk space will be used.
Do you want to continue? [Y/n]

...

Setting up unattended-upgrades (2.9.1+nmu3) ...

Creating config file /etc/apt/apt.conf.d/20auto-upgrades with new version

Creating config file /etc/apt/apt.conf.d/50unattended-upgrades with new version
Synchronizing state of unattended-upgrades.service with SysV service script with /lib/systemd/
systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable unattended-upgrades
Created symlink /etc/systemd/system/multi-user.target.wants/unattended-upgrades.service → /lib
/systemd/system/unattended-upgrades.service.

...

 





Mais après cela voici l'état du service :


# systemctl status unattended-upgrades
● unattended-upgrades.service - Unattended Upgrades Shutdown
     Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; preset: disabled)
     Active: active (running) since Sun 2024-02-11 09:51:07 UTC; 8min ago
       Docs: man:unattended-upgrade(8)
   Main PID: 1383 (unattended-upgr)
      Tasks: 2 (limit: 2255)
     Memory: 13.1M
        CPU: 288ms
     CGroup: /system.slice/unattended-upgrades.service
             └─1383 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal

Feb 11 09:51:07 vps1a.virt systemd[1]: Started unattended-upgrades.service - Unattended Upgrades Shutdown.

 


=> Il est actif !

Apparemment c'est à cause de :


Executing: /lib/systemd/systemd-sysv-install enable unattended-upgrades
Created symlink /etc/systemd/system/multi-user.target.wants/unattended-upgrades.service → /lib
/systemd/system/unattended-upgrades.service.
 


en fin d'installation qui doit intervenir après preset



Comment peut-on prévenir cela ?


Merci pour vos réponses.

Hors ligne

#2 11-02-2024 12:24:19

dezix
Membre
Distrib. : Debian stable
Noyau : Linux amd64 (stable)
(G)UI : XFCE4
Inscription : 19-02-2018

Re : SYSTEMD : Preset surchargé par systemd-sysv-install

Après quelques recherches supplémentaires (et sans certitude),

la cause pourrait provenir de l'exécution de :


/var/lib/dpkg/info/unattended-upgrades.postinst
 



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 :


# systemctl --now disable <service>
 

Hors ligne

#3 11-02-2024 13:44:27

dezix
Membre
Distrib. : Debian stable
Noyau : Linux amd64 (stable)
(G)UI : XFCE4
Inscription : 19-02-2018

Re : SYSTEMD : Preset surchargé par systemd-sysv-install

Pas encore certain d'être sur la bonne piste,
mais :

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

#4 11-02-2024 15:59:23

vv222
Administrateur
Lieu : Bretagne
Distrib. : Debian Sid
(G)UI : sway
Inscription : 18-11-2013
Site Web

Re : SYSTEMD : Preset surchargé par systemd-sysv-install

Tout ce qui tourne autour de dh_* concerne les mainteneurs de paquets Debian, pas les administrateurs de machines sous Debian.

Jouer sous Debian ? Facile !

Ceterum censeo Barum esse delendam

Hors ligne

#5 11-02-2024 16:03:26

dezix
Membre
Distrib. : Debian stable
Noyau : Linux amd64 (stable)
(G)UI : XFCE4
Inscription : 19-02-2018

Re : SYSTEMD : Preset surchargé par systemd-sysv-install

Salut!

vv222 a écrit :

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

#6 11-02-2024 17:36:53

dezix
Membre
Distrib. : Debian stable
Noyau : Linux amd64 (stable)
(G)UI : XFCE4
Inscription : 19-02-2018

Re : SYSTEMD : Preset surchargé par systemd-sysv-install

Je crois que je vais me résigner et revenir à mon ancienne approche :

Supprimer (ou commenter) le "preset"


# rm /etc/systemd/system-preset/20-admin.preset
 



et
replacer ce script qui bloque le démarrage de tout nouveau service fraîchement installé :


# cat > /usr/sbin/policy-rc.d <<EOF
#!/bin/sh
exit 101
EOF

# chmod +x /usr/sbin/policy-rc.d
 




Du coup lors de l'installation, on a :


Setting up unattended-upgrades (2.9.1+nmu3) ...

Creating config file /etc/apt/apt.conf.d/20auto-upgrades with new version

Creating config file /etc/apt/apt.conf.d/50unattended-upgrades with new version
Synchronizing state of unattended-upgrades.service with SysV service script with /lib/systemd/
systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable unattended-upgrades
Created symlink /etc/systemd/system/multi-user.target.wants/unattended-upgrades.service → /lib
/systemd/system/unattended-upgrades.service.
/usr/sbin/policy-rc.d returned 101, not running 'start unattended-upgrades.service'
 


=> la dernière ligne montre bien le blocage du démarrage du service.

et l'état le confirme


# systemctl status unattended-upgrades.service
○ unattended-upgrades.service - Unattended Upgrades Shutdown
     Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; preset: enable>
     Active: inactive (dead)
       Docs: man:unattended-upgrade(8)
 


le service est bien inactif.

Hors ligne

#7 11-02-2024 17:42:48

dezix
Membre
Distrib. : Debian stable
Noyau : Linux amd64 (stable)
(G)UI : XFCE4
Inscription : 19-02-2018

Re : SYSTEMD : Preset surchargé par systemd-sysv-install

C'est tout de même une situation que j'accepte mal :

Systemd est le système d'initialisation et le gestionnaire de services par défaut depuis déjà assez longtemps,
et on se retrouve encore avec ce genre de problème !

La logique voudrait que les logiciels et les admins qui n'ont pas évolués (peu importe leurs bonnes raisons)
pour fonctionner directement avec systemd doivent en assumer les conséquences par un surplus de configuration,
mais pas l'inverse.


Je trouve ça bien frustrant, même exaspérant...
car dans le cas précis de unattended-upgrades
on n'a pas trace de sysv dans le contenu du paquet :


$ apt-file show unattended-upgrades
unattended-upgrades: /etc/init.d/unattended-upgrades
unattended-upgrades: /etc/kernel/postinst.d/unattended-upgrades
unattended-upgrades: /etc/logrotate.d/unattended-upgrades
unattended-upgrades: /etc/pm/sleep.d/10_unattended-upgrades-hibernate
unattended-upgrades: /etc/update-motd.d/92-unattended-upgrades
unattended-upgrades: /lib/systemd/system-sleep/unattended-upgrades
unattended-upgrades: /lib/systemd/system/unattended-upgrades.service
unattended-upgrades: /usr/bin/unattended-upgrade
unattended-upgrades: /usr/bin/unattended-upgrades
unattended-upgrades: /usr/lib/python3/dist-packages/unattended_upgrades-0.1.egg-info/PKG-INFO
unattended-upgrades: /usr/lib/python3/dist-packages/unattended_upgrades-0.1.egg-info/dependency_links.txt
unattended-upgrades: /usr/lib/python3/dist-packages/unattended_upgrades-0.1.egg-info/top_level.txt
unattended-upgrades: /usr/lib/systemd/logind.conf.d/unattended-upgrades-logind-maxdelay.conf
unattended-upgrades: /usr/lib/systemd/system/unattended-upgrades.service
unattended-upgrades: /usr/share/apport/package-hooks/source_unattended-upgrades.py
unattended-upgrades: /usr/share/doc/unattended-upgrades/NEWS.Debian.gz
unattended-upgrades: /usr/share/doc/unattended-upgrades/README.md.gz
unattended-upgrades: /usr/share/doc/unattended-upgrades/changelog.gz
unattended-upgrades: /usr/share/doc/unattended-upgrades/copyright
unattended-upgrades: /usr/share/lintian/overrides/unattended-upgrades
unattended-upgrades: /usr/share/locale/da/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/de/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/es/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/eu/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/fr/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/gl/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/ja/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/nl/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/pt/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/pt_BR/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/ru/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/locale/sk/LC_MESSAGES/unattended-upgrades.mo
unattended-upgrades: /usr/share/man/man8/unattended-upgrade.8.gz
unattended-upgrades: /usr/share/man/man8/unattended-upgrades.8.gz
unattended-upgrades: /usr/share/unattended-upgrades/20auto-upgrades
unattended-upgrades: /usr/share/unattended-upgrades/20auto-upgrades-disabled
unattended-upgrades: /usr/share/unattended-upgrades/50unattended-upgrades
unattended-upgrades: /usr/share/unattended-upgrades/50unattended-upgrades.md5sum
unattended-upgrades: /usr/share/unattended-upgrades/unattended-upgrade-shutdown
unattended-upgrades: /usr/share/unattended-upgrades/update-motd-unattended-upgrades
 



/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 :


$ apt-file search /lib/systemd/systemd-sysv-install
systemd: /lib/systemd/systemd-sysv-install
systemd: /usr/lib/systemd/systemd-sysv-install
 



Je jette l'éponge sad

Dernière modification par dezix (11-02-2024 18:10:58)

Hors ligne

Pied de page des forums