Re: Problème après mise à jour: la machine ne sort plus de veille.
Hello, Charles Plessy wrote on 15/05/2024 at 11:12:52+0200: > Bonjour à tous, > > désolé pour la rafale de messages mais c'est un peu la cata… > > Aujourd'hui j'ai redémarré mon portable et depuis il ne sort plus de > veille après qu'il y soit entré. Plus précisément, ni le clavier ni la > souris ne se réveillent, et je n'ai pas d'autre choix que de redémarrer > complètement la machine.. J'avais eu ce problème depuis le début et la > solution suivante trouvée par un autre utilisateur avait réglé le > problème: > > Mettre dans /usr/lib/systemd/system-sleep: > > case $1/$2 in > pre/*) > ;; > post/*) > echo -n reconnect > /sys/devices/platform/i8042/serio0/drvctl > echo -n reconnect > /sys/devices/platform/i8042/serio2/drvctl > ;; > esac > > Je suis sous Bookworm et je ne sais pas très bien commment attaquer le > problème. J'ai essayé de redémarrer sous linux-image-6.1.0-20-amd64 > mais ça ne résoud rien. Je n'avais pas redémarré depuis longtemps, et > j'ai perdu la trace de ce qui a pu être mis à jour récemment (à part > bien sûr la glib qui m'avait fait perdre le support du japonais et du > chinois dans Firefox…). > > La machine est un VAIO Pro 13 vieux de 9 ans environ… > > Si vous avez de idées, je suis preneur ! > > Bonne journée, Du bruit dans le dmesg? -- PEB signature.asc Description: PGP signature
Re: Est-il possible de passer de Debian 11 à Debian 12 avec Mailman3 ?
Pierre Malard wrote on 20/12/2023 at
09:42:29+0100:
> [[PGP Signed Part:No public key for FE94961EE69DFC18 created at
> 2023-12-20T09:42:29+0100 using RSA]]
> Salut,
>
> Est-il possible de passer de Debian 11 à Debian 12 avec Mailman3 installé sur
> Debian 11 ?
>
> Je précise que je souhaite rester dans les dépôts Debian, pas une
> installation "à la main" de MM3.
>
> J'ai testé sur un serveur spécifique. C'était long et fastidieux mais il me
> semblait que ça fonctionnait. En fait tout semble fonctionner sauf
> la gestion des archives :-(
>
> Voici la procédure suivie :
>
> 1 Arrêt des services MM3
> 2 Sauvegarde de la base de données (PostgreSQL) et du répertoire de base MM3
> 3 Basculez le serveur de Debian 11 vers Debian 12 et redémarrer
> 4 migrer la base de données du PG 13 vers le PG 15 (pg_upgradecluster 13 le
> fait très bien)
> 5 Modifier le fichier /etc/mailman3/mailman.cfg avec une référence URL
> "postgresql://" au lieu de "postgres://" (voir
> https://lists.mailman3.org/archives/list/ mailman-users@mailman3
> .org/thread/CU6YU44V4WLRJI3WJH2VBWO2HCUF4YEA/)
> 6 mettre à jour les bases de données MM3 avec "mailman-web migrate"
> 7 redémarrer MM3 et MM3-web
>
> Avec ça MM3 fonctionne mais pas la gestion de l'archivage !
> Notez qu’il n’y a pas de véritables messages d’erreur dans les journaux…
>
> En fait quand on va sur une archive de liste, on a de jolies roues
> d'attente... infinies :-(
> La seule référence dans mailman3-web.log :
> [pid : 1429|app : 0|req : 12/12] NNN.NNN.NNN.NNN () {68 vars dans 1445
> octets} [lundi 18 décembre 16:35:56 2023] GET
> /hyperkitty/list/admin@ teledetection.fr/ => généré 37443 octets en 37 msecs
> (HTTP/1.1 200) 7 en-têtes en 221 octets (1 switch sur core
> 1)
>
> Si vous avez une solution...
Pour une raison que j'ignore, l'appel à django-admin migrate dans le
script de maintenance post upgrade ne se passe pas toujours.
J'ai commencé à creuser, mais pour l'instant sans succès, faute
d'environnements où ça foire pour moi.
Si tu as des traces ou infos je suis preneur, vu que j'aimerais bugfixer
ça pour faire une release en Debian 12 qui ne rencontre plus ce souci.
--
PEB
Mainteneur du paquet.
signature.asc
Description: PGP signature
Re: Délai de 25 secondes
Seb wrote on 09/11/2023 at 11:34:11+0100:
> Bonjour !
>
>
> J'ai installé hier une Debian 12 en remplacement d'une Debian plus
> ancienne. C'est une installation à partir de zéro, pas une mise
> à jour.
>
> Mon gestionnaire de fenêtres est fvwm.
>
> Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule
> 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian
> précédente, j'avais remarqué le même délai avec firefox depuis
> quelques mois seulement. Je n'ai pas souvenir que pavucontrol ou
> xdaliclock ait posé le même problème dans la Debian que j'utilisais
> précédemment.
>
> Les autres programmes s'ouvrent sans délai (gimp, brave-browser,
> okular, etc.).
>
> Quand j'appelle "strace pavucontrol", les messages cessent de défiler
> en arrivant à la dernière des lignes copiées-collées ci-dessous :
>
> [...]
> eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 11
> futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN
> (Resource temporarily unavailable)
> futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0
> write(10, "\1\0\0\0\0\0\0\0", 8)= 8
> futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1
> poll([{fd=11, events=POLLIN}], 1, 25000
>
> Sitôt le délai (25000) passé, pavucontrol s'ouvre.
>
> Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins
> d'une direction dans laquelle chercher ?
Si tu as la flemme de débugger, j'imagine que tu as actuellement
pulseaudio d'installé. Tu pourrais le retirer au profit de
pipewire-pulse et voir si ça fonctionne mieux.
En tout état de cause, vu que tu as le fd et 25 secondes pour agir, un
ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle
socket/autre il poll.
--
PEB
signature.asc
Description: PGP signature
Re: Bookworm ou pas ?
Bureau LxVx wrote on 12/05/2023 at 11:42:24+0200: > Bonjour, > > Je dois changer mon ssd qui devient "trop étroit" au niveau / > > La Debian 12 arrive très prochainement. Habituellement, j'attends > quelques mois avant de migrer (install propre). > > Si j'installe cette testing avant sa sortie officielle, quels risques > "majeurs" ? > > Merci de vos avis. > > Bien librement, Hello, On est en "hard freeze", ce qui signifie que très peu de paquets vont bouger. Les risques encourus sont minimum par rapport à une stable. Bien à toi, -- PEB signature.asc Description: PGP signature
Re: n'arrive plus à git push vers github.com
Bonjour Basile, Il est important de lire les messages d'erreur qui sortent sur un terminal, parce que sinon on perd son temps et éventuellement on fait perdre le leur aux autres. Basile Starynkevitch wrote on 14/03/2023 at 11:22:49+0100: > Bonjour à tous, > > Je n'arrive plus à faire un git push vers github.com > > Sur mon ordinateur portable personnel (ACER Nitro 5, x86-64, Debian/Sid, ...) > > guiseppe.x86_64 ~/RefPerSys 10:43 .0 % git push > Username for 'https://github.com': bas...@starynkevitch.net > Password for 'https://bas...@starynkevitch.net@github.com': > guiseppe.x86_64 ~/RefPerSys 10:44 .130 % git push > Username for 'https://github.com': bstarynk > Password for 'https://bstar...@github.com': > remote: Support for password authentication was removed on August 13, 2021. > remote: Please see > https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls > for information on > currently recommended modes of authentication. > fatal: Authentication failed for 'https://github.com/RefPerSys/RefPerSysy/' C'est écrit ici : tu essaies de te connecter en https pour pousser, et donc de pousser avec un login/mot de passe, ce qui n'est plus supporté par GitHub depuis le 13 août 2021. > Mon profile sur github est https://github.com/bstarynk/ > > Mon email perso est bas...@starynkevitch.net > > Mon email pro est basile.starynkevi...@cea.fr (mais aujourd'hui je suis en > congé) > > (mon téléphone portable, en journée, en France, 06 85012359) > > guiseppe.x86_64 ~/RefPerSys 11:15 .130 % cat .git/config > [core] > repositoryformatversion = 0 > filemode = true > bare = false > logallrefupdates = true > [remote "origin"] > url = https://github.com/RefPerSys/RefPerSys/ > fetch = +refs/heads/*:refs/remotes/origin/* > [branch "master"] > remote = origin > merge = refs/heads/master > > > guiseppe.x86_64 ~ 11:17 .0 % ls -la .ssh > total 108 > drwx-- 2 basilest basilegr 4096 Mar 14 10:40 . > drwx-- 24 basilest basilegr 4096 Mar 14 10:42 .. > -rw--- 1 basilest basilegr 5877 Dec 23 11:03 authorized_keys > -rw--- 1 basilest basilegr 5465 Dec 23 11:03 authorized_keys~ > -rw--- 1 basilest basilegr 1349 Dec 23 11:03 authorized_keys2 > -rw--- 1 basilest basilegr 1650 Dec 23 11:03 config > -rw--- 1 basilest basilegr 1192 Dec 23 11:03 id_dsa > -rw--- 1 basilest basilegr 1716 Dec 23 11:03 id_dsa.keystore > -rw-r--r-- 1 basilest basilegr 1117 Mar 14 10:38 id_dsa.pub > -rw--- 1 basilest basilegr 365 Dec 23 11:03 id_ecdsa-old > -rw-r--r-- 1 basilest basilegr 269 Dec 23 11:03 id_ecdsa.pub-old > -rw--- 1 basilest basilegr 464 Dec 23 11:03 id_ed25519 > -rw-r--r-- 1 basilest basilegr 97 Dec 23 11:03 id_ed25519.pub > -rw--- 1 basilest basilegr 529 Dec 23 11:03 identity > -rw--- 1 basilest basilegr 333 Dec 23 11:03 identity.pub > -rw--- 1 basilest basilegr 2655 Dec 23 11:03 id_rsa > -rw--- 1 basilest basilegr 630 Dec 23 11:03 id_rsa.keystore > -rw--- 1 basilest basilegr 571 Mar 14 10:40 id_rsa.pub > -rw--- 1 basilest basilegr 1784 Dec 23 12:41 known_hosts > -rw--- 1 basilest basilegr 948 Dec 23 12:41 known_hosts.old > -rw--- 1 basilest basilegr 8053 Dec 23 11:03 known_hosts_old > -rw-r--r-- 1 basilest basilegr 576 Dec 23 11:03 piotr-id_rsa.pub > -rw--- 1 basilest basilegr 512 Dec 23 11:03 random_seed > -rw--- 1 basilest basilegr 399 Dec 23 11:03 ssh_config > > > et > > guiseppe.x86_64 ~ 11:17 .0 % id -a > uid=12752(basilest) gid=4200(basilegr) groups=4200(basilegr),27(sudo) > > et > > guiseppe.x86_64 ~ 11:18 .0 % cat .ssh/id_dsa.pub > ssh-dss > B3NzaC1kc3MAAAEBAJ4IYdy+Wrjft3/krEp1XaPrkqfqeuHs13iiGeEXwnMBlhd+ycc5D/8ajy74oN9t9rIt7ixz3XR+bs3llXMgJ+MeI5fVb0jBElkdw5epCTFasrIq866vo28i0W1CwKlx1thP8/LDMY/YIkwkj6Nqxz5cZLqBn9j1SUSsVRr+FiVgYaSxt5zm/bzbtaLGsjMeN0z+JxE/tSk1hL4KL4MpVsALT2dlh2CPpmbnpiK6dzKLozZdUF2/qD/u1+sicbBm+zgKAdhKUN541qOiww/joWS9biC1y9DVg4tQTcg88/pxbS8RL5Osehsl1bdLA3mw+yWKIo/a0OZdavaS67SRkisVAPt+uDThzgbET1FxiRi0lqeeL4u1AAABAFDhtURdWt6uaywGaak/ZMM9lg6az+B04j0ltvUdb0sZGs4DHpLy4nHgVMAKCYKpTBzQrG407SN25o+e1suo17pK3BskFPwzywEvrge9B4dcIKr3QN2xoCfCdnXe7g8ieFIbuGwvykjGspaQ+P9NXRZOkBSHAlvEm7ATx2qduSeIBUYn/prMy1kQUP7/Ikvm8NFrAdMm6E8qXgNdbZvThcnuCDkvWKG9rZtCsX6GLRMT1Gn0s6D7F28hH47BlgH/uFoIXbOxvA7f/OrscGrzj396m12HMtrTEhcrONsYySZ/vZLqbxRKpNjNPhfIzMuGwsls5u6FlUHO/otCGZFQCFsAAAEAXnF0z9Yhn5fQhGzg4aDk5tHmMCRv4b0yB288vk8K5gHrKNpovQCZPmx9SKiLweEGoXIoJ3Im7Df8R1fijmpqvLiKdsbX3S5XWgqJ5KoNKAEWkteTy1+T/2RhqvfINE9PB40D0VdhV7BCtZ/mHWFEF2HGRC7PInswRRpgssyD49GCAvqwDluonipOfDU66yNSoMBMP3QPgH6mn0txkjqMpjBfy2VRrFOj3l0DWtaAWT9Arh9JzkGSsbE5B+YnMB6uK85lncLYDNV9n+AvvpvDyFtbA2bbjMo6CqeFnHvzDjhjEFrGedrxGaYnELEo+zH5QhJv2IV35wkR7MF8Z9Vzow== > basile@guiseppe > > Qu'ai-je fait comme bêtise en ligne de commandes? > > Quelle commande utiliser pour réparer? Ajouter une clefs SSH publique sur github pour ton compte, par exemple celle
Re: Montage nfs en un clic
Salut,
benoit wrote on 02/12/2022 at 12:10:48+0100:
> Bonjour,
>
> Quelle serait la solution le plus conviviale pour monter un point de montage
> nfs au clic ?
> J'ai écrit une petite fct en attendant, mais c'est pas convivial et ça m'a
> obligé à ajouter une ligne dans le fstab.
>
> partagenfs(){
> DISK="$HOME/partagenfs/"
> if [ -z "$(grep 'partagenfs' /proc/mounts)" ]
> then
> mount /mnt/partagenfs
> fi
> cd $DISK
> }
>
> # dans /etc/fstab
> servnfs:/export/mnt/partagenfs nfs4rw,hard,intr,_netdev,user,noauto
> 0 0
>
> Je recherche une solution au clic et facultatif pour, par exemple, un
> ordi portable qui vient dans le réseau et se connecte à la demande au
> serveur nfs.
autofs et un "lien" dans nautilus vers le point de montage.
--
PEB
Re: net.ipv4.ip_forward=1
Hello, Olivier Back my spare wrote on 20/11/2022 at 11:26:43+0100: > Bonjour > > J'ai une question. Cela fait des années que je me pose la question sur > la pertinence de cette commande. > Énormément de howto sur le net disent qu'il faut décommenter la ligne > suivante : > net.ipv4.ip_forward=1 > > Ce que je ne comprends pas. Si la ligne est commenté par défaut sur > debian installation basique, pourquoi faut-il le faire. > Ma question peut paraître idiote. Mais la partie réseau (en général), > ce n'est pas mon café du matin. Désolé. > > Merci par avance. Cela autorise ta machine à router du trafic qui ne lui est pas destiné. Tu n'en as besoin que si tu héberges des VMs/conteneurs ou que tu utilises ta machine comme routeur/pare-feu. Bien à toi, -- PEB signature.asc Description: PGP signature
Re: pourquoi systemd démarre 4 fois le même service (mon sync-periodically)
Bonjour,
Basile Starynkevitch wrote on 17/11/2022 at
15:02:38+0100:
> Bonjour la liste
>
> A la maison comme au bureau (j'y suis actuellement au CEA LIST, et ssh
> vers mon PC fixe du bureau à la maison) j'ai la chance d'avoir un
> "gros" PC fixe sous Debian (au bureau) ou Ubuntu (chez moi).
>
> Au bureau: Intel(R) Xeon(R) Silver 4114 CPU, Dell WS Precision 7920
> avec 128Go de RAM. Aucun onduleur, et parfois des coupures de courant.
> Disque SSD + Disque rotatif. J'ai parfois perdu une journée de boulot
> par suite d'une coupure de courant.
>
> Chez moi: une configuration assemblée par Materiel.net avec AMD Ryzen
> Threadripper 2970WX et 64Go de RAM. Disque SSD + disque rotatif.
>
> J'ai codé en quelques heures (chez moi) l'utilitaire
> https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
> qui lance l'appel système sync(2) toutes les quelques secondes.
>
> L'idée étant qu'en cas de coupure de courant, je ne perds pas trop de
> fichiers (étant dévelopeur, ça m'embêterais).
Au jugé, je pense que tu as inventé une roue qui est inutile.
Je m'explique : sync est une API vers le syscall sous-jacent (du même
nom) qui instruit au noyau de committer le cache des filesystems vers
les disques. Sous ext4 par exemple, cela consiste à démarrer un nouveau
commit du journal.
Or, par défaut, un file system ext4 monté n'étant pas sur un plugdev est
paramétré pour que de tels commits aient lieu toutes les cinq secondes.
Par ailleurs, un commit est automatiquement initié dès que le buffer
(cache) du noyau pour un filesystem est plein, ce qui sur un make ou
autre arrive très vite.
Bref, à première vue, ton programme ne me semble servir à rien d'autre
que ralentir ta machine en faisant des commits toutes les trois secondes
de façon non-optimale. Mais je peux avoir loupé quelque chose.
Je pense que juste passer commit=3 dans ton fstab et dropper ton service
serait plus pertinent.
> Au bureau j'ai Debian/Sid (que je viens de [re]installer hier, par
> mise à jour de Debian/Testing en Debian/Instable)
>
> root@pcbasile:/# /lib/systemd/systemd --version
> systemd 252 (252.1-1)
> +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL
> +ACL +BLKID +CURL +ELFUTILS +FIDO2
> +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT
> +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD
> -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified
>
> -En italique violet, le prompt du shell-.
>
> et le fichier /etc/systemd/system/sync-periodically.service contient
>
> # on https:///github.com/bstarynk/misc-basile.git
> # for Linux Debian/Buster systemd, encoded in UTF-8
> # see https://wiki.debian.org/systemd/Services
> # it should be installed as /etc/systemd/system/sync-periodically.service
> # and then run systemctl enable sync-periodically.service
> #
> # © Copyright 2020 Basile Starynkevitch
> # (near Paris, France)
> #
> # This sync-periodically.service script is free software; you can
> # redistribute it and/or modify it under the terms of the GNU General
> # Public License as published by the Free Software Foundation; either
> # version 2, or (at your option) any later version.
> #
> # this sync-periodically.service script is distributed in the hope that
> # it will be useful, but WITHOUT ANY WARRANTY; without even the implied
> # warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
> # the GNU General Public License for more details.
> #
>
> [Unit]
> Description=a service to sync(2) periodially our disks on Debian
> Documentation=See https:///github.com/bstarynk/misc-basile.git files
> sync-periodically.{c,service}
> After=network.target sshd.service
> ConditionPathExists=!/etc/local/sync-periodically-dont-run
>
> [Service]
> ExecStartPre=/bin/bash -c "[ -x /usr/local/bin/sync-periodically ]"
> ExecStart=/usr/local/bin/sync-periodically --daemon
> --pid-file=/var/run/sync-periodically.pid --sync-period=3 --log-period=300
> ExecReload=/usr/bin/ldd /usr/local/bin/sync-periodically
> RestartSec= 500ms
> Restart=on-failure
> RestartPreventExitStatus=254
> Type=notify
> KillMode=process
> RuntimeDirectory=/var/run
> RuntimeDirectoryMode=0755
>
> [Install]
> WantedBy=multi-user.target
> Alias=sync-periodically.service
>
> et pour une raison incompréhensible de moi (je connais mal systemd) il y a
> quatre processus sync-periodically
>
> root@pcbasile:/# ps auxw|egrep 'USER|sync-'
> USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
> root3157 0.0 0.0 246092 ?Ss 12:43 0:01
> /usr/local/bin/sync-periodically --daemon
> --pid-file=/var/run/sync-periodically.pid
> --sync-period=3 --log-period=300
> root3160 0.0 0.0 246096 ?Ss 12:43 0:01
> /usr/local/bin/sync-periodically --daemon
> --pid-file=/var/run/sync-periodically.pid
> --sync-period=3 --log-period=300
> root3164 0.0 0.0 246096 ?Ss 12:43
Re: Est il possible de forcer Linux a écrire plus souvent dans le swap
Bonjour, Olivier backup my spare wrote on 07/11/2022 at 15:01:00+0100: > [[S/MIME Signed Part:Good signature from > 1AC3C31618D9C6DFA326BA0ECD5464CA1230DCB3 /CN=backup.my.sp...@gmail.com (trust > undefined)]] > Bonjour > > J'ai un serveur de calcul et j'ai des utilisateurs qui ouvrent des instances > à distance. > Pour beaucoup, il lancent un calcul et attendent le résultat mais ils > utilisent leur instance comme un bureau et y laissent des applis ouverte > mais non utilisées. > Y a t-il un moyen de forcer linux à mettre ces applis en stand by dans le > swap. > C'est un serveur Del avec une debian Bulleyes. Oui et non : sysctl vm.swappiness Plus la valeur (entre 0 et 100) est élevée, plus la mise en swap sera faite de façon agressive. Mais tu ne peux pas garantir le comportement du noyau pour autant. -- PEB
Re: [long/résolu] Re: Grosse fatigue
BERTRAND Joël wrote on 05/10/2022 at 10:58:12+0200: > Ne pouvant obtenir aucune résolution ni de la part de l'équipe de devs > de systemd ni de debian, j'ai pris le taureau par les cornes et j'ai > fait ce que j'aurais dû faire depuis très longtemps. J'ai viré debian > que j'ai remplacé par devuan _sans réinstallation_. Les versions des > paquets sont restées les mêmes, j'ai vérifié. Je me débrouillerai avec > Xilinx dans un second temps. > > La configuration était une debian/testing à jour. Sur cette machine, > remplacer le /etc/apt/sources.list par : > > deb http://deb.devuan.org/merged stable main contrib non-free > deb http://deb.devuan.org/merged stable-updates main contrib non-free > deb http://deb.devuan.org/merged stable-security main contrib non-free > deb http://deb.devuan.org/merged testing main contrib non-free > deb http://deb.devuan.org/merged unstable main contrib non-free > > Faire une première passe de téléchargement des fichiers de description > de dépôts : > > apt-get update --allow-insecure-repositories > > Installer les clefs : > > apt-get install devuan-keyring --allow-unauthenticated > > Mettre à jour les dépôts : > > apt-get update > > Installer les premiers paquets : > > apt-get upgrade > > On est toujours sous Debian avec systemd. À partir de là, c'est chaud. > On installe eudev et un gestionnaire d'init (finit, rc, sysv, ce que > vous voulez). J'ai installé sysvinit-core parce que finit râle sur une > absence de runlevel due à systemd. Sur le portable de test que j'ai > migré avant ma station de travail, j'ai forcé l'installation de finit en > installant à la main le contenu de data.tar.xz du paquet finit. Ça > fonctionne. > > apt-get install eudev > apt-get install sysvinit-core > > On réinstalle ce qui a été cassé au passage : > > apt-get -f install > > On redémarre (directement par reboot). Et là, miracle, plus de systemd. > On met le système à jour et on vire les scories : > > apt-get dist-upgrade > apt-get purge systemd libnss-systemd > apt-get autoremove --purge > apt-get autoclean > > Et hop... > > hilbert:[~] > cat /etc/issue > Devuan GNU/Linux daedalus/ceres \n \l > > Premières constatations : > - la station de travail qui mettait 4 minutes 50 secondes à démarrer > avec systemd (entre le chargement du noyau et l'apparition de wdm) ne > met plus que... 20 secondes ! Entendons-nous bien, plus de 4 minutes > _sans_ timeout parce que le système lançait tout en parallèle et mettait > le réseau par terre. On m'avait vendu systemd comme un truc qui > démarrait beaucoup plus vite. Même si je me contrefiche de cet argument > parce que je ne redémarre pas mes machines tous les jours, c'est assez > symptomatique de la lourdeur du truc ; > - en quasiment huit jours d'utilisation, je n'ai pas réussi avec l'init > SysV à dépasser une charge de 15 côté station (et 8 côté serveur NFS). > Avec systemd et la même utilisation, il n'était pas rare de monter à 60 > côté station et plus de 40 côté serveur ! J'ai même chargé la mule en > retirant deux barrettes mémoire. Le poste en question n'a plus que 32 Go > de RAM, ce qui le fait swapper comme un malade : > > KiB Mem : 32781360 total,4730928 libr,26204816 util,1845616 tamp/cache > KiB Éch : 10066329+total,70649632 libr,30013660 util.5955912 dispo Mem > > Malgré cela, c'est parfaitement stable ; > - je n'observe plus aucun problème bizarre (pour mémoire : des processus > zombies, des shells qui se font la malle en occupant 100% d'un coeur de > CPU, des daemons qui se baugent et qui ne sont pas relancés, X qui part > en vrille et j'en passe). > > La différence entre les deux ? On vire le goulot d'étranglement systemd > (qui doit faire des trucs pas nets vue la différence de charge système) > que l'on remplace par un init classique. Je ne vais pas passer plus de > temps à essayer de comprendre les merdes de systemd, j'ai déjà assez > perdu de temps sur le sujet. J'ai remonté le bug ici (à au moins deux > reprises) et upstream. Ici, ça n'existe pas, systemd est génial; > upstream, le constat est fait mais sans aucune solution. > > Sur le reste parce qu'il y a à dire... J'avais écrit que je ne > répondrai plus, mais devant tant de mauvaise foi... > > Pierre-Elliott Bécue a écrit : >> Il y en a qui y arrivent apparemment : >> https://wiki.debian.org/DebianEdu/Documentation/Bullseye/Architecture > 1/ Je suis en testing pas en stable. Je sais que testing, c'est testing > et pas stable, mais je n'ai pas le choix en raison d'un soft > propriétaire et de ses prérequis ; > > 2/ En testing, app-armor met le bordel rien que sur un truc aussi >
Re: Grosse fatigue
BERTRAND Joël wrote on 29/09/2022 at 08:32:47+0200: > Tu veux absolument avoir raison, je te laisse avoir raison. C'est > tellement plus facile que de devoir remettre en cause des choix hasardeux. > > Encore une fois, je ne t'ai pas attendu (d'autant qu'avant d'avoir > posté la première fois ici, il y a quelques mois, j'ai filé le bébé aux > développeurs de systemd, même avec un accès distant sur l'une des > machines en défaut. La réponse fut "on ne sait pas ce qu'il se passe".). > Au passage, avant de monter sur tes grands chevaux et de parler de fud, > relis-moi bien attentivement. Parce que même en filtrant à peu près > intelligemment la sortie d'auditd, c'est inapplicable sur des machines > _diskless_ (je pense que c'est le mot que tu as sauté), sauf à savoir > exactement ce que tu cherches. Mais là encore, tu as parfaitement > raison, tout est théoriquement applicable. J'aimerais bien habiter en > théorie, parce qu'en théorie, tout se passe bien. > > auditd _sature_ le serveur nfs, donc même si tu arrives à obtenir > quelque chose, rien ne te dit que ce que tu auras obtenu sera pertinent > parce que tu n'es plus dans les mêmes conditions de fonctionnement. Le > simple fait d'activer auditd en filtrant intelligemment balance des "nfs > server not responding" sur toutes les machines du réseau ! > > Tiens, sinon, histoire de rigoler et parce qu'on se dit tout, Debian > n'est plus depuis au moins la version 11 avec systemd capable de tourner > en diskless sur un serveur nfs (au moins V3/TCP conforme aux specs). Je > te laisse installer une machine dans ces conditions parce que tu ne me > croiras pas une fois de plus. Il y en a qui y arrivent apparemment : https://wiki.debian.org/DebianEdu/Documentation/Bullseye/Architecture Et j'ai des diskless bookworm au taff, donc bon. On a ptet pas l'air, mais il y a beaucoup de devs Debian qui sont ingé sys et réseaux - moi le premier et ont des besoins type scolaire avec des postes diskless de salle de TP ou autre. Les plâtres, on les essuie aussi, donc on essaie de les limiter. C'est juste qu'on est sans doute moins allergiques au changement. -- PEB signature.asc Description: PGP signature
Re: Grosse fatigue
BERTRAND Joël wrote on 29/09/2022 at 08:32:47+0200: > Tu veux absolument avoir raison, je te laisse avoir raison. C'est > tellement plus facile que de devoir remettre en cause des choix hasardeux. > > Encore une fois, je ne t'ai pas attendu (d'autant qu'avant d'avoir > posté la première fois ici, il y a quelques mois, j'ai filé le bébé aux > développeurs de systemd, même avec un accès distant sur l'une des > machines en défaut. La réponse fut "on ne sait pas ce qu'il se passe".). > Au passage, avant de monter sur tes grands chevaux et de parler de fud, > relis-moi bien attentivement. Parce que même en filtrant à peu près > intelligemment la sortie d'auditd, c'est inapplicable sur des machines > _diskless_ (je pense que c'est le mot que tu as sauté), sauf à savoir > exactement ce que tu cherches. Mais là encore, tu as parfaitement > raison, tout est théoriquement applicable. J'aimerais bien habiter en > théorie, parce qu'en théorie, tout se passe bien. > > auditd _sature_ le serveur nfs, donc même si tu arrives à obtenir > quelque chose, rien ne te dit que ce que tu auras obtenu sera pertinent > parce que tu n'es plus dans les mêmes conditions de fonctionnement. Le > simple fait d'activer auditd en filtrant intelligemment balance des "nfs > server not responding" sur toutes les machines du réseau ! Si un filtrage ne laissant *au pire* que quelques milliers de lignes par jour sature ton NFS, il est sans doute temps d'en changer (j'ose pas En effet, fin de la discussion, tu as décidé de te plaindre et que tu avais tout testé (trop dur d'admettre qu'on peut passer des mois sur un problème sans l'aborder par le bon bout de la lorgnette, alors que ça nous arrive à tous ?), reste-donc dans tes convictions plutôt que d'évoluer. Mais du coup ne te sens pas obligé de venir rant sur les listes à nouveau si c'est pour ignorer les réponses et repartir en monologue. Cordialement, -- PEB signature.asc Description: PGP signature
Re: Grosse fatigue
BERTRAND Joël wrote on 28/09/2022 at 11:25:59+0200: > Thomas Parmelan a écrit : >> Le mardi 27 septembre 2022 à 18:23, d'après >> BERTRAND Joël : >> >> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... >> Question naïve, mais qui me turlupine à vous lire tous les deux : si je comprends bien, la session graphique est lancée sous l'identité de root (ce qui est rarement une idée géniale, mais c'est un autre débat). >>> >>> Absolument pas. La session est ouverte en tant qu'utilisateur standard >>> authentifié par ypbind. >> >> Ah, très bien, alors dans ce cas cette ligne "systemd[1]: Stopping User >> Manager for UID 0..." concerne autre chose, peut-être un "su" dans un >> job cron par exemple. Cela devrait être identifiable en regardant les >> lignes précédant celles-ci dans les logs. >> >> Si la session n'est pas ouverte en UID 0, et que c'est bien systemd qui >> la termine, alors il doit y avoir des choses avec le bon UID dans les >> logs, mais je n'ai rien vu de tel dans les extraits précédemment >> fournis. > > Parce qu'en fait, il n'y a strictement rien d'autre (et en règle > générale, il n'y a aucun su). Pour être exact, la ligne précédente > concerne un cron plusieurs minutes avant (deux ou trois de mémoire). Alors vu le nombre de trucs qui ferment avant que systemd ne valide que la slice de l'user 0 est terminée, et considérant que toutes les lignes de logs sont horodatées à la même heure:min:sec, j'aurais tendance à dire que soit ton cron est louche, soit il y a bien une session interactive qui tourne pour root. > Par ailleurs, wdm et X tournent tous deux avec les droits root. -- PEB
Re: Grosse fatigue
BERTRAND Joël wrote on 27/09/2022 at 10:32:17+0200: > Pierre-Elliott Bécue a écrit : >> Salut, >> >> BERTRAND Joël wrote on 26/09/2022 at >> 09:44:54+0200: >> >>> Pierre-Elliott Bécue a écrit : >>>> >>>> BERTRAND Joël wrote on 23/09/2022 at >>>> 10:31:52+0200: >>>>> [snip] >>>> >>>> Ok, donc systemd ne tue pas X. systemd met un terme à la session de >>>> root. La raison est que systemd détermine au moment où il le fait que le >>>> dernier processus interactif (c'est-à-dire contrôlé par un utilisateur) >>>> a terminé, et par défaut dans ce cas, il clos la session, et termine >>>> donc tout programme lancé depuis cette session (logique, ça évite que >>>> des trucs traînent ad-vitam comme résidus d'une session interactive). >>>> >>>> Dans la mesure où tu as a priori une session graphique qui tourne, c'est >>>> effectivement surprenant, mais il est possible (vu que tu ne postes que >>>> les logs qui t'intéressent, qui ne sont pas forcément les logs >>>> pertinents) que ta session utilisateur meure pour une raison ou une >>>> autre et qu'en conséquence, systemd considère qu'il n'y a plus aucun >>>> programme interactif qui tourne. >>> >>> Il n'y a rien d'autre anormal avant cela, mais tu n'es pas contraint de >>> me croire. Ce matin, d'ailleurs, je réveille ma machine (écrans en >>> veille) pour constater une fois de plus que la session avait été tuée et >>> que wdm n'était même plus actif. J'ai la flemme d'aller rechercher dans >>> deux jours de logs pour trouver toujours le même message après des >>> lignes tout à fait normales. >>> >>> Au passage, ça m'a fait exactement la même chose sur la machine de ma >>> femme (dans la même configuration diskless) jusqu'au jour où j'en ai eu >>> tellement marre que je lui ai installé un FreeBSD. Sauf que moi, je ne >>> peux pas, j'ai un bout de soft propriétaire qui ne tourne que sous Linux. >> >> Très bien, mais as-tu, par exemple, unattended-upgrades ou équivalent >> qui tourne ? As-tu un needrestart d'installé qui redémarrerait des >> services agressivement en cas d'upgrade via un unattended-upgrades like? > > Non et non. J'ai déjà indiqué ça plus haut. Ce genre de chose merdoie > allègrement en nfs root (il faut plusieurs heures pour un paquet comme > TeXlive et ça engorge le réseau et le serveur nfs, c'est donc désactivé > par défaut). > > > >>> Il n'y a pas de cron foireux, j'ai naturellement vérifié. ypbind tourne >>> directement rattaché à init, donc ici à systemd et s'il y a un truc qui >>> est stable, c'est bien ypbind. Quand je le lance dans une console, il >>> récupère un signal 15 du père (ici systemd) >> >> Sauf si tu fais des trucs spécifique, en lançant ypbind dans une >> console, c'est elle qui est parent de ypbind. À moins que ypbind se >> détache mais dans ce cas tu ne devrais plus avoir de stdout/stderr. > > Je ne fais rien de spécifique (ypbind -dn). > >>> et c'est pour cela qu'il s'arrête. Ça peut mettre deux ou trois jours, >>> plus encore, mais ce signal 15 du père finit TOUJOURS par >>> arriver. Quand il est lancé en daemon, il n'y a strictement rien comme >>> information pertinente dans les logs. Mais vu qu'il s'arrête en >>> interactif sur un signal 15, je te file mon billet que c'est >>> exactement la même chose lorsqu'il est en tâche de fond. La question >>> est de savoir pourquoi systemd envoie un signal au processus en >>> question. Dernière chose, j'ai installé Devuan avec le même ypbind sur >>> un vieux portable dans la même configuration nis (mais avec un init >>> SysV qui fonctionne et qui fait juste ce qu'on lui demande). Aucun >>> problème. Ce n'est donc pas ypserv qui est en faute mais le père de >>> ypbind (sinon, ypbind se baugerait aussi sur le portable en >>> question). Je te l'accorde, c'est peut-être une interaction de systemd >>> avec tout autre chose qui fait que la conséquence est un arrêt de >>> ypbind. Mais ce quelque chose ne laisse dans ce cas aucune trace dans >>> les logs. >> >> Et systemd est plutôt verbeux, donc c'est peu probable que ça soit lui >> tout seul. >> >>> On est bien d'accord que ypbind n'a aucune raison de se prendre un >>> signal 15 si X se bauge lui-même vu que ypbind n'est pas lancé dans la >>> session X. On est bien d'accord que ce n'est pas ypbind qui s'envoie à >>> lui-même u
Re: Grosse fatigue
Salut, BERTRAND Joël wrote on 26/09/2022 at 09:44:54+0200: > Pierre-Elliott Bécue a écrit : >> >> BERTRAND Joël wrote on 23/09/2022 at >> 10:31:52+0200: >>> [snip] >> >> Ok, donc systemd ne tue pas X. systemd met un terme à la session de >> root. La raison est que systemd détermine au moment où il le fait que le >> dernier processus interactif (c'est-à-dire contrôlé par un utilisateur) >> a terminé, et par défaut dans ce cas, il clos la session, et termine >> donc tout programme lancé depuis cette session (logique, ça évite que >> des trucs traînent ad-vitam comme résidus d'une session interactive). >> >> Dans la mesure où tu as a priori une session graphique qui tourne, c'est >> effectivement surprenant, mais il est possible (vu que tu ne postes que >> les logs qui t'intéressent, qui ne sont pas forcément les logs >> pertinents) que ta session utilisateur meure pour une raison ou une >> autre et qu'en conséquence, systemd considère qu'il n'y a plus aucun >> programme interactif qui tourne. > > Il n'y a rien d'autre anormal avant cela, mais tu n'es pas contraint de > me croire. Ce matin, d'ailleurs, je réveille ma machine (écrans en > veille) pour constater une fois de plus que la session avait été tuée et > que wdm n'était même plus actif. J'ai la flemme d'aller rechercher dans > deux jours de logs pour trouver toujours le même message après des > lignes tout à fait normales. > > Au passage, ça m'a fait exactement la même chose sur la machine de ma > femme (dans la même configuration diskless) jusqu'au jour où j'en ai eu > tellement marre que je lui ai installé un FreeBSD. Sauf que moi, je ne > peux pas, j'ai un bout de soft propriétaire qui ne tourne que sous Linux. Très bien, mais as-tu, par exemple, unattended-upgrades ou équivalent qui tourne ? As-tu un needrestart d'installé qui redémarrerait des services agressivement en cas d'upgrade via un unattended-upgrades like? >> Il y a une façon d'éviter que systemd ferme une session en cas de fin de >> tous les programmes interactifs d'un utilisateur, via "loginctl >> enable-linger $username". Ici ça ressemble à du scotch sur une jambe de >> bois car cela ne t'aidera pas à comprendre ce qu'il se passe >> derrière. >> >> Creuser les logs (un cron qui se lance? ton wm qui meurt/crashe?) serait >> sans doute plus pertinent, voire activer certains debugs sur certains >> progs. Après l'enable-linger peut aider à voir ce qu'il se passe et >> trouver le nœud du problème si c'est effectivement un programme qui >> meurt (puisque dans ce cas il mourra toujours mais le reste ne sera pas >> buté). > > Figure-toi qu'avant de poster ici, j'ai un peu creusé, parce que ça > fait plusieurs mois que le problème dure. J'utilise Debian depuis Potato > et, avant, j'utilisais RedHat. Je sais où chercher et où creuser. > > J'ai tout d'abord cru que c'était wdm le fautif, mais avec xdm ou gdm, > le résultat est strictement identique. J'ai mis la chose sur le dos de > wmaker, j'ai essayé xfce. Idem. KDE, itou. Gnome, je ne peux pas, je > suis allergique. Quand je dis que le résultat est identique, c'est une > fermeture de la session comme si j'avais normalement quitté la session > (jamais de crash violent), mais avec les shells restant actifs, > rattachés à systemd et qui passent dans un état bizarre (utilisation CPU > maximale). J'ai mis ça sur le dos de la carte graphique. J'ai changé la > carte AMD par une NVidia avec le même résultat. > > J'ai même réinstallé le système en totalité (sans soft proprétaire, que > du Debian pour commencer) parce que mon installation datait un petit > peu. Même résultat. Et ce ne sont pas des programmes aléatoires qui sont > arrêtés, mais la session X ou ypbind (jamais autre chose, lorsque > d'autres daemons sont arrêtés, c'est parce que ypbind est stoppé au > préalable, n'est pas redémarré par systemd et que le daemon en question > crashe parce qu'il n'a plus accès aux tables NIS). Tu vois, j'ai un peu > creusé le sujet. > > Il n'y a pas de cron foireux, j'ai naturellement vérifié. ypbind tourne > directement rattaché à init, donc ici à systemd et s'il y a un truc qui > est stable, c'est bien ypbind. Quand je le lance dans une console, il > récupère un signal 15 du père (ici systemd) Sauf si tu fais des trucs spécifique, en lançant ypbind dans une console, c'est elle qui est parent de ypbind. À moins que ypbind se détache mais dans ce cas tu ne devrais plus avoir de stdout/stderr. > et c'est pour cela qu'il s'arrête. Ça peut mettre deux ou trois jours, > plus encore, mais ce signal 15 du père finit TOUJOURS par > arriver. Quand il est lancé en daemon, il n'y a strictement rien
Re: Grosse fatigue
BERTRAND Joël wrote on 23/09/2022 at 10:31:52+0200: > Pierre-Elliott Bécue a écrit : >> Une ligne de log, quelque chose qui montre que systemd a bien tué X >> et éventuellement pourquoi, ou bien on est juste sur yet another >> mail de baseless FUD? > > Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... > Sep 23 08:49:31 hilbert systemd[577146]: Activating special unit Exit > the Session... > Sep 23 08:49:31 hilbert systemd[577146]: Removed slice User Core > Session Slice. > Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Main User Target. > Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Basic System. > Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Paths. > Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Sockets. > Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Timers. > Sep 23 08:49:31 hilbert systemd[577146]: Closed D-Bus User Message Bus > Socket. > Sep 23 08:49:31 hilbert systemd[577146]: Closed GnuPG network > certificate management daemon. > Sep 23 08:49:31 hilbert systemd[577146]: Closed Socket to launch > DrKonqi for a systemd-coredump crash. > Sep 23 08:49:31 hilbert systemd[577146]: Closed GCR ssh-agent wrapper. > Sep 23 08:49:31 hilbert systemd[577146]: Closed GNOME Keyring daemon. > ... > Sep 23 08:49:31 hilbert systemd[577146]: Reached target Shutdown. > Sep 23 08:49:31 hilbert systemd[577146]: Finished Exit the Session. > Sep 23 08:49:31 hilbert systemd[577146]: Reached target Exit the Session. > Sep 23 08:49:31 hilbert systemd[1]: user@0.service: Deactivated > successfully. > Sep 23 08:49:31 hilbert systemd[1]: Stopped User Manager for UID 0. > Sep 23 08:49:31 hilbert systemd[1]: Stopping User Runtime Directory > /run/user/0... > Sep 23 08:49:31 hilbert systemd[1]: run-user-0.mount: Deactivated > successfully. > Sep 23 08:49:31 hilbert systemd[1]: user-runtime-dir@0.service: > Deactivated successfully. > Sep 23 08:49:31 hilbert systemd[1]: Stopped User Runtime Directory > /run/user/0. > Sep 23 08:49:31 hilbert systemd[1]: Removed slice User Slice of UID 0. > ... Ok, donc systemd ne tue pas X. systemd met un terme à la session de root. La raison est que systemd détermine au moment où il le fait que le dernier processus interactif (c'est-à-dire contrôlé par un utilisateur) a terminé, et par défaut dans ce cas, il clos la session, et termine donc tout programme lancé depuis cette session (logique, ça évite que des trucs traînent ad-vitam comme résidus d'une session interactive). Dans la mesure où tu as a priori une session graphique qui tourne, c'est effectivement surprenant, mais il est possible (vu que tu ne postes que les logs qui t'intéressent, qui ne sont pas forcément les logs pertinents) que ta session utilisateur meure pour une raison ou une autre et qu'en conséquence, systemd considère qu'il n'y a plus aucun programme interactif qui tourne. Il y a une façon d'éviter que systemd ferme une session en cas de fin de tous les programmes interactifs d'un utilisateur, via "loginctl enable-linger $username". Ici ça ressemble à du scotch sur une jambe de bois car cela ne t'aidera pas à comprendre ce qu'il se passe derrière. Creuser les logs (un cron qui se lance? ton wm qui meurt/crashe?) serait sans doute plus pertinent, voire activer certains debugs sur certains progs. Après l'enable-linger peut aider à voir ce qu'il se passe et trouver le nœud du problème si c'est effectivement un programme qui meurt (puisque dans ce cas il mourra toujours mais le reste ne sera pas buté). > Au passage, systemd va jusqu'à tuer ypbind : > > Sep 23 08:49:46 hilbert systemd[1]: ypbind.service: Main process > exited Non, systemd constate juste que ypbind a terminé, il ne le tue pas, et n'a rien à voir avec son arrêt. C'est bien de critiquer, c'est mieux de lire les lignes de logs que tu colles. > On se demande bien pourquoi. > > Et il relance le tout comme si rien ne s'était passé (enfin, là, > parce que par moment il tue ypbind sans le redémarrer, ce qui pose des > problèmes amusants sur une machine diskless en NIS/NFS). Il le relance parce qu'en cas d'arrêt inopiné, c'est ce que le service est supposé faire. > De toute façon, la question n'est pas là. systemd décide pour une > raison inconnue de clôturer la session. Naturellement, il n'y a AUCUNE > erreur avant la première ligne de log. Je veux donc me séparer à la > fois de cette saleté qui est une brique pour essuyer les plâtres et > d'usrmerge. Feel free to go elsewhere, mais ici le souci c'est avant tout que tu as décidé que c'était un bug ou un comportement inexplicable plutôt que d'essayer de comprendre ce qu'il se passe. Tu auras donc d'autres problèmes sur d'autres systèmes, et tu trouveras un autre outil à blâmer. > Je précise que ce genre de chose arrive tous les de
Re: Grosse fatigue
BERTRAND Joël wrote on 23/09/2022 at 09:41:24+0200: > Bonjour à tous, > > Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment, > toutes les applications en cours (me contraignant à repartir de la > sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de > travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au > milieu du chemin, tuant X mais surtout pas les terminaux de contrôles > dépendants de X : > > top - 09:03:05 up 3 days, 53 min, 19 users, load average: 48,54, 25,93, > 14,15 > ... > KiB Mem : 65562712 total, 5298100 libr, 24405232 util, 3078024 tamp/cache > KiB Éch : 10066329+total, 71624128 libr, 29039160 util. 7755600 dispo Mem > ... > 76791 bertrand 20 0 10108 2468 1660 R 76,2 0,0 13:08.04 > bash >2418 bertrand 20 09988 1792 1648 R 75,2 0,0 13:06.32 > bash > 79309 bertrand 20 09988 2432 1640 R 75,2 0,0 13:30.25 > bash > 307331 bertrand 20 09988 2604 1812 R 75,2 0,0 13:06.87 > bash > 422686 bertrand 20 0 10104 2564 1768 D 75,2 0,0 13:08.79 > bash > 475927 bertrand 20 0 10252 2508 1688 R 75,2 0,0 13:08.96 > bash > 477249 bertrand 20 0 10172 2460 1652 R 75,2 0,0 13:29.82 > bash >2114 bertrand 20 0 10108 2016 1680 R 74,3 0,0 13:09.14 > bash >2122 bertrand 20 0 10108 2056 1716 D 74,3 0,0 13:09.67 > bash >3684 bertrand 20 09988 1808 1672 R 74,3 0,0 13:02.70 > bash >4944 bertrand 20 09988 1892 1732 R 74,3 0,0 13:02.49 > bash > 77325 bertrand 20 09988 2580 1780 R 74,3 0,0 13:10.73 > bash > 103189 bertrand 20 0 10808 3064 1712 R 74,3 0,0 13:02.45 > bash > 309027 bertrand 20 09988 2496 1708 R 74,3 0,0 12:59.61 > bash > 429272 bertrand 20 0 10104 2532 1736 R 74,3 0,0 13:08.76 > bash > > en laissant des zombies partout, des fichiers à moitié ouverts et > corrompus ! Je ne vous ai pas mis toute la liste, la charge est > uniquement due aux bash qui tournent la poignée dans le coin sans rien > faire puisqu'ils ne sont plus associés à un terminal. Le swap de s'est > rempli qu'_après_ que X a été tué par systemd. > > Cette machine n'a aucun problème matériel. Je l'ai testée en long, en > large et en travers. > > J'avoue que ça commence sérieusement à me fatiguer. systemd se permet > de tuer la session X sans aucune raison (rien dans les logs sinon un > truc du style systemd: kill X). Je tourne en testing à jour pour tout un > tas de raisons que je n'expliciterai pas ici. > > Sur ces entrefaites, je passe ne console texte et je m'aperçois que > trois paquets ne peuvent s'installer. Comment ça ? Pour mémoire, > "unattented-upgrade" _N_'est _PAS_ configuré parce que j'ai une version > de KiCAD et une autre de FreeCAD en rolling releases (et > qu'accessoirement lorsque le truc décide de mettre à jour LaTeX, le > réseau rame durant plusieurs heures parce que la station de travail est > diskless). La seule chose qui est faite, c'est un apt update la nuit. > Les mises à jour automatique mettent un bazar là-dedans et je préfère > toujours les passer à la main quand je sais que je ne dérangerai personne. > > Je tente donc un apt dist-upgrade et là, je vois que le truc veut > m'installer usrmerge. Mais pour tout un tas de raisons, JE NE VEUX PAS > DE CETTE SALETÉ. Pourquoi ? Toute mon installation est diskless et/ou > embarqué et usrmerge met un bazar incommensurable là-dedans. Pour une > installation diskless, ça multiplie les latences (regardez un peu le > trafic sur un NFS/TCP, c'est effarant) et dans l'embarqué où / et /usr > ne sont pas sur les mêmes partitions, ça oblige à des contorsions pour > espérer démarrer correctement jusqu'au bout. > > Est-il possible de refuser usrmerge ? Ou faut-il que j'envisage de > réinstaller cette machine sous autre chose, autre chose qui n'utilise ni > systemd vus les dysfonctionnements du truc ni usrmerge ? D'ailleurs > existe-t-il encore une distribution Linux sans usrmerge ? > > À titre personnel, je ne comprends toujours pas que Debian cherche à > imposer systemd vue la fiabilité de la chose dès lors qu'on n'est plus > sur un poste de travail avec un disque en local (la gestion des timeouts > réseau ou des accès réseau concurrents au sens large est... rigologène > pour rester poli et surtout non reproductible d'une version à l'autre). > Quant à ursmerge, dans l'embarqué, on préférerais avoir un répertoire > /rescue à la NetBSD et un /usr séparé pour toujours pouvoir démarrer un > système minimal même lorsque la partition /usr est plantée (/ pouvant > rester en lecture seule). Là, si /usr est corrompue pour une raison ou > pour une autre, on n'est même pas sûr de réussir à démarrer le système > (sauf à se retrouver dans un shell embarqué dans le fumeux initramfs). > > Merci pour toutes vos suggestions, > > JKB Une ligne de log,
Re: qui y va ?
ptilou wrote on 02/02/2022 at 17:32:57+0100: > Le mercredi 2 février 2022 à 15:30:02 UTC+1, Marc Chantreux a écrit : >> salut, >> >> idée tordue du jour: tu aurais pu mettre "Fosdem" *dans* le titre. >> > https://fosdem.org/2022/about/ >> > on fait du co stand, voiturage, hôtel ? >> AFAIK: >> >> Online component >> >> The format for FOSDEM 2022 will be online only. How does this work? >> Visit this page for more details. >> >> https://fosdem.org/2022/practical/ >> > > Oui online, mais on peut venir aussi […] Ma compréhension du "online only" c'est que l'ULB ne sera pas ouverte au public du FOSDEM. -- PEB signature.asc Description: PGP signature
Re: Effacer plusieurs millions de fichiers d'un répertoire !
Le dimanche 04 avril 2021 à 09:30:45+0200, JUPIN Alain a écrit : > Bonjour > > Petit casse tête du dimanche matin ! > > Sur un serveur LAMP à base de Debian10 (à jour en version 10.9), j'ai noté des > lenteurs et le syslog est sans équivoque : > [4958833.739887] EXT4-fs warning (device sda3): ext4_dx_add_entry:2258: > Directory (ino: 18612230) index full, reach max htree level :2 > [4958833.739889] EXT4-fs warning (device sda3): ext4_dx_add_entry:2262: Large > directory feature is not enabled on this filesystem > > Après analyse, je ne dépasse pas le nombre max d'inodes du système de fichier > (j'en suis à 9% d'utilisé), par contre, le répertoire /var/lib/php/sessions/ > contient 56 781 542 fichiers > J'ai lancé hier soir un : find . -cmin +30 | xargs rm; > Mais après plusieurs heures la commande échoue avec "trop d'arguments" > > Bref ce matin, il y a deux heures, je tente une nouvelle approche : rsync -a > --delete /tmp/empty/ /var/lib/php/sessions/ > avec bien sur /tmp/empty qui est vide > Mais après deux heures de fonctionnement, je n'ai aucun retour de la commande > ! > > Du coup connaissez vous une méthode "rapide" pour effacer plusieurs millions > de > fichiers d'un répertoire ! > > PS : Par contre, je ne comprend pas la présence de ses fichiers, car j'ai bien > un cron qui se lance toutes les demi-heures pour supprimer les sessions. Va > falloir que j'élucide ce mystère ! Le rsync est la méthode la plus rapide en matière de performances. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Re: Réponse positive d'un cobaye
On lun. 27 avril 2015 à 15:34:07, andre_deb...@numericable.fr wrote: On Monday 27 April 2015 10:41:19 Alain Rpnpif wrote: Le 26 avril 2015, maderios a écrit : Idem, d'ailleurs Testing marchait bien depuis un petit moment. Par ailleurs, il faut essayer et utiliser Sid, cela en vaut la peine. Sid est plus stable/fiable qu'Ubuntu, mais c'est un débat trollesque... Mouais. Par erreur, il y a 2 semaines, mon fils a mis à jour, sur une machine de bureau, Wheezy avec sid et son systemd. Malheur lui en a pris, car plus moyen de de connecter en Xorg. Après tentative de remettre sysvinit, systemd a mis un de ces bazars tel que seul la console de maintenance fonctionnait. Il semble que systemd avec Xorg n'aime pas du tout le changement de libc6. Après 2 ou 3 heures de travail, tout est revenu dans l'ordre. Donc je resterai sous Wheezy et ses backports qui fonctionne très bien et est rapide. Je sais que sysvinit est utilisable dans Jessie, mais savez-vous s'il est possible de migrer vers Jessie en évitant toute trace de Systemd et donc de ses effets pervers, en interdisant **dès le départ** l'installation de systemd et ou de ses fichiers de configuration inutiles dans ce cas ? Alain Rpnpif Désinstaller systemd pour sysvinit : http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation Je me suis donc mis cobaye (ou testeur) par une mise à jour de Wheezy vers Jessie :-) (l'autre était une nouvelle installation de Jessie, pas une mise à jour) Sous Wheezy = apt-get-update | apt-get upgrade | apt-get dist-upgrade, apt-get autoclean | apt-get autoremove, afin d'avoir Wheezy propre. Puis : wheezy = jessie dans sources.list , et : apt-get-update | apt-get upgrade | apt-get dist-upgrade Ce fut laborieux, très long, pas mal de messages d'erreur, (impossible de les noter tant ils sont nombreux), boot, reboot bloqués, réinstallation de grub... enfin je peux booter en mode console. Impossible de lancer le mode graphique que ce soit avec lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite (quid ?) Problème de PAM ? Et miracle, enfin tdm-trinity se lance avec mot de passe accepté... Aurais-je le même parcours du combattant lors du prochain boot ? Ces difficultés viennent-elles de systemd et faut-il le désinstaller ? (je n'ose le faire sans quelques avis...) Sans message d'erreur (trouvables dans /var/log/gdm, /var/log/lightdm, /var/log/Xorg*, ...), ça va être dur de te répondre. De même, plein de messages d'erreur sans plus de précision, ce n'est pas un symptôme. -- PEB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150427134638.gt13...@crans.org
Re: HS_Re: Hal y en a marre!!!
On mer. 14 mai 2014 à 18:12:31, Georges wrote: Donc moi, en tant qu'utilisateur final, pas ingénieur du tout, je fais quoi sur ma Wheezy ? Hal, je le supprime ? Et comme j'ai aussi une Jessie et une Sid sur le même disque je supprime Hal sur les trois ? Enfin, les end user comme moi, vont avoir une réponse claire, non ? ;-) ;-) ;-) Coucou, En tant qu'end user tu as le choix : * Te contrefoutre de la présence de hal, parce qu'il ne te sert pas ; * Le virer, et voir si ça pète un truc ; * Taper hal debian sur ton navigateur préféré, prendre quelques minutes pour lire, puis décider ce que tu fais ; * Whatever que j'oublie. Bref, ça change pas grand chose par exemple si je dis que j'ai Asus AppCenter sur mon PC sous Windows 7, et que je sais pas quoi en faire. C'est juste le genre de problématique qu'on retrouve d'un système à l'autre sur les logiciels installés qu'on connaît pas. Debian est juste un système où les utilisateurs, quel que soit leur niveau, peuvent trouver leur compte. :) -- PEB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140515122756.gh...@crans.org
Re: Hal y en a marre!!!
On lun. 12 mai 2014 à 19:53:11, Gaël wrote: Debian n'est pas faite pour les end users. ?? J'ai beaucoup de personnes (bon, des militant-e-s) autour de moi qui utilisent debian sur leur ordi, et ça ne pose pas de soucis ! Je suis assez d'accord, dire que Debian n'est pas faite pour les end users me semble inapproprié. -- PEB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140514120206.gu10...@crans.org
Re: /etc/fstab et partitions imbriquées : bug ou fonctionnalité ?
On mer. 14 mai 2014 à 09:35:52, Joël BERTRAND wrote: Le 13/05/2014 18:34, Bzzz a écrit : On Tue, 13 May 2014 17:50:32 +0200 Francois Lafont mathsatta...@free.fr wrote: fstab. Sur le principe, je ne vois vraiment pas en quoi cela est illégitime. Ça n'a pas lieu d'être, parce que la logique veut que l'on monte l'étage 1 avant le 2, et comme l'a dit Bernard, s'il y a inversion dans fstab c'est de la faute de l'hébergeur. Je ne peux pas être d'accord. Qu'il soit possible de monter des partitions en les masquant mutuellement lorsque le système est fonctionnel est une chose. Que ce soit permis dans /etc/fstab est un peu casse gueule d'autant qu'il serait assez simple de rajouter une option à mount pour lui demander de trier la liste (un simple qsort suffirait) pour éviter _au boot_ de masquer des partitions. Lorsqu'on masque /var, ce n'est pas trop gênant. En revanche, masquer /usr est un peu plus rigolo. Et c'est là qu'on se dit que le système d'arborescences multiples et de définitions de VMS est largement supérieur à ce qui se fait dans le monde Unix, mais nous ne sommes pas encore trolldi. Je suis d'accord avec ce point de vue, un warning sert typiquement à ce genre de chose, et si le terme warning choque, il suffit d'écrire Info à la place. En tout état de cause, aucune personne sur cette liste ne peut empêcher quelqu'un de soumettre une wishlist pour le package mount, et je suggère donc à celui qui veut faire une demande de la faire, en vérifiant si elle n'a pas déjà été faite sur https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mount;dist=unstable#_0_6_2 . Bonne journée, -- Pierre-Elliott Bécue Et sinon, arrêtez de donner à manger aux trolls locaux. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140514122129.gv10...@crans.org
Re: /etc/fstab et partitions imbriquées : bug ou fonctionnalité ?
On lun. 12 mai 2014 à 14:22:14, David Guyot wrote: Bonjour, la liste. Je viens de remarquer ce qui me semble être un bug dans la gestion des partitions de /etc/fstab dans le cas de partitions imbriquées et aurait aimé savoir que faire de cette information. Je m'explique : j'ai récemment configuré un serveur dédié sous Wheezy, lequel contient, entre autres, deux partitions montées sous /var/www et /var/www/cache ; pour des raisons de limitations techniques de mon hébergeur, la grande firme roubaisienne, j'ai dû configurer d'abord la partition montée sous /var/www/cache, large d'environ 124 Gio, puis la partition /var/www, large d'environ 1,7 Tio, ce qui fait que /var/www était située après /var/www/cache dans /etc/fstab. À ce stade, les plus aguerris d'entre vous devraient entrevoir mon problème : cela a donné lieu à un fonctionnement très erratique de la partition /var/www/cache, comme les commandes ci-dessous, exécutées juste après un redémarrage du serveur, attestent : david@Curunir:~$ df -h Sys. fich.Taille Util. Dispo Uti% Monté sur rootfs 54G 3,1G 49G 6% / udev 10M 0 10M 0% /dev tmpfs13G 328K 13G 1% /run /dev/md1 54G 3,1G 49G 6% / tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs35G 0 35G 0% /dev/shm /dev/md3 20G 233M 19G 2% /var/log /dev/md41,7T 852M 1,6T 1% /var/www/cache /dev/md6 99G 188M 94G 1% /home /dev/md71,7T 852M 1,6T 1% /var/www tmpfs32G 0 32G 0% /tmp david@Curunir:~$ sudo su [sudo] password for david: root@Curunir:/home/david# umount /dev/md4 umount: /var/www/cache: not mounted root@Curunir:/home/david# mount /dev/md4 root@Curunir:/home/david# df -h Sys. fich. Taille Util. Dispo Uti% Monté sur rootfs 54G 3,1G 49G 6% / udev 10M 0 10M 0% /dev tmpfs 13G 328K 13G 1% /run /dev/md1 54G 3,1G 49G 6% / tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 35G 0 35G 0% /dev/shm /dev/md3 20G 233M 19G 2% /var/log /dev/md4 124G 188M 118G 1% /var/www/cache /dev/md6 99G 188M 94G 1% /home /dev/md7 1,7T 852M 1,6T 1% /var/www tmpfs 32G 4,0K 32G 1% /tmp /dev/md4 124G 188M 118G 1% /var/www/cache root@Curunir:/home/david# uname -a Linux Curunir 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux root@Curunir:/home/david# aptitude show linux-image-3.2.0-4-amd64 Paquet : linux-image-3.2.0-4-amd64 Nouveau: oui État: installé Automatiquement installé: oui Version : 3.2.57-3 Priorité : optionnel Section : kernel Responsable : Debian Kernel Team debian-ker...@lists.debian.org Architecture : amd64 Taille décompressée : 106 M Dépend: kmod | module-init-tools, linux-base (= 3~), initramfs-tools (= 0.99~) | linux-initramfs-tool Pré-dépend: debconf | debconf-2.0 Recommande: firmware-linux-free (= 3~) Suggère: linux-doc-3.2, debian-kernel-handbook, grub-pc | extlinux | lilo Casse: at ( 3.1.12-1+squeeze1), initramfs-tools ( 0.99~) Fournit: linux-image, linux-modules-3.2.0-4-amd64 Description : Linux 3.2 for 64-bit PCs The Linux kernel 3.2 and modules for use on PCs with AMD64, Intel 64 or VIA Nano processors. This kernel also runs on a Xen hypervisor. It supports both privileged (dom0) and unprivileged (domU) operation. Ce comportement ne s'accompagnait d'aucun message d'erreur dans quelque journal que ce soit ; après de nombreux essais, je me suis souvenu de l'ordre de ces partitions dans /etc/fstab et les ai inversées pour placer /var/www avant /var/www/cache, et la partition /var/www/cache a, de ce fait, retrouvé un comportement normal. Je sais que l'ordre dans /etc/fstab des systèmes de fichiers à monter est important, mais je n'aurais jamais pensé que des problèmes liés pourraient se montrer de la sorte, sans aucun avertissement ni gestion correcte par le noyau. À mon sens, le noyau devrait gérer ce genre de cas de façon transparente, par exemple en chargeant /etc/fstab d'un bloc et en en vérifiant le contenu pour remettre dans l'ordre le montage des partitions afin d'éviter les problèmes ; sinon, il devrait au moins être capable d'avertir de ce genre de situation par un message dans les journaux afin d'éviter de perdre des heures d'analyse de symptômes sibyllins pour un problème aussi trivial. J'en arrive maintenant au moment fatidique : que dois-je faire de ce problème ? Tout d'abord, est-ce bien un bug ou est-ce une fonctionnalité ? Si c'est bien un bug, à qui le signaler ? Dois-je le signaler d'abord à l'équipe Debian qui le remontra aux développeurs du noyau si nécessaire, ou dois-je le signaler directement aux développeurs du noyau puisque cela concerne la fonction bas niveau de gestion du montage des disques ? Si vous êtes arrivés jusqu'à cette phrase, merci de m'avoir lu et merci
