Ubuntu 25.10 : une impression sur deux disparaît sans prévenir

Depuis quelque temps, mon imprimante a un comportement de « mauvais élève » : elle rend un travail sur deux. Je lançe l’impression d’un PDF, la fenêtre se referme en silence, et rien ne sort. Pas de message d’erreur, pas de travail en attente, pas de voyant qui clignote. Je recommence, et cette fois la feuille arrive. Quand on imprime des corrigés de devoirs à la chaîne, c’est le genre de panne qui rend fou.

L’imprimante n’y est pour rien. Le coupable est une couche logicielle récente d’Ubuntu, placée entre les applications et CUPS, et le bogue est connu. Voici comment le reconnaître, et comment vivre avec en attendant un correctif.

Le symptôme, précisément

La machine : Ubuntu 25.10, GNOME, une Brother MFC-J6920DW branchée sur le réseau. Les impressions partent de Papers, la visionneuse PDF par défaut. Le 3 octobre, en notant les heures, cela donnait ceci :

Heure	Résultat
11 h 09	imprimé
11 h 37	perdu, sans message
11 h 40	imprimé
12 h 01	perdu, sans message

L’alternance est trop régulière pour être un hasard de réseau. Et surtout, les impressions perdues ne laissent aucune trace côté CUPS :

# Tous les travaux, terminés ou non
lpstat -W all -o

Si le document que vous venez d’envoyer n’apparaît pas dans cette liste, il n’a jamais atteint CUPS. La file d’attente, le pilote et l’imprimante sont donc hors de cause : le travail s’est perdu avant.

La fausse piste

J’ai d’abord accusé la file d’impression. Celle qu’Ubuntu crée automatiquement vient de cups-browsed, qui découvre les imprimantes du réseau et fabrique des files temporaires, de type implicitclass://. C’est un suspect habituel. J’ai donc créé à la main une file permanente, qui parle directement à l’imprimante :

# Une file IPP directe, sans pilote constructeur
sudo lpadmin -p Brother_direct -E \
     -v ipp://BRW48E244C152F5.local:631/ipp/print -m everywhere
lpadmin -d Brother_direct

L’adresse est celle de mon imprimante ; la vôtre s’obtient avec lpinfo -v.

Cette file fonctionne très bien, je l’ai gardée. Mais vingt minutes plus tard, une impression se perdait à nouveau, cette fois sur la nouvelle file. Ce n’était pas ça.

Le journal donne le coupable

La bonne idée, que j’aurais dû avoir en premier, est de lire le journal de la session plutôt que celui de CUPS :

journalctl --user --since "-1 hour" | grep -i 'socket\|cpdb'

À chaque impression perdue correspond exactement une ligne :

oct. 03 11:37:12 xdg-desktop-portal-gnome[1850575]: [Error] [Frontend] Error opening socket on Brother_MFC_J6920DW CUPS : La connexion est fermée
oct. 03 12:01:00 xdg-desktop-portal-gnome[1997875]: [Error] [Frontend] Error opening socket on Brother_direct CUPS : La connexion est fermée

La seconde ligne nomme la nouvelle file : la preuve que changer de file ne servait à rien. Et le programme qui se plaint n’est ni Papers ni CUPS, c’est xdg-desktop-portal-gnome.

Qui fait quoi dans une impression

Sur un Ubuntu récent, une application GTK4 comme Papers n’ouvre pas elle-même la fenêtre d’impression et ne parle pas directement à CUPS. La chaîne est plus longue :

1. l’application demande une impression au portail (xdg-desktop-portal, et sa partie GNOME) ;
2. le portail affiche la fenêtre d’impression, construite avec GTK4 ;
3. GTK4 s’adresse à CPDB (Common Print Dialog Backends), une couche intermédiaire qui doit permettre aux fenêtres d’impression de parler à plusieurs systèmes d’impression ;
4. le module CUPS de CPDB (cpdb-backend-cups) ouvre un canal par lequel le document est transmis à CUPS.

C’est à la dernière étape que cela casse. D’après ce que j’observe, le canal s’ouvre correctement pour la première impression qui suit le démarrage du portail, puis reste dans un état fermé : à l’impression suivante, l’ouverture échoue, le portail note l’erreur dans le journal et ne prévient personne. L’application croit que tout s’est bien passé.

Je n’ai pas lu le code pour savoir pourquoi le canal reste fermé ; je décris ici un comportement observé, pas une cause démontrée.

Un bogue déjà signalé

Le problème figure sur Launchpad depuis le 19 octobre 2025 : bogue n° 2128983, contre le paquet cpdb-backend-cups en version 2.0b7-0ubuntu2 sur Ubuntu 25.10. Le rapport parle d’une fenêtre d’impression lente à s’ouvrir, d’une première impression perdue sans entrée dans la file, et d’une seconde tentative qui passe. Le contournement proposé là-bas est simplement d’imprimer deux fois.

Mon cas en diffère un peu : chez moi c’est la première impression qui passe et la suivante qui se perd. Le mécanisme me paraît le même, mais je ne peux pas l’affirmer. À la date où j’écris, le rapport est au statut « New », sans personne assigné et sans correctif publié. Si vous êtes touché, cliquer sur « This bug affects me » en haut de la page est la façon la plus utile de le faire remonter.

Le contournement : relever le portail

Puisque le portail accepte une impression après chaque démarrage, il suffit de le redémarrer. À la main :

systemctl --user restart xdg-desktop-portal-gnome

Le redémarrage prend moins d’une seconde et ne ferme aucune fenêtre. Mais y penser avant chaque impression n’est pas une solution. J’ai donc écrit un petit veilleur qui le fait à ma place, avec deux déclencheurs :

• dès que CUPS annonce qu’un travail vient d’être créé, le veilleur attend huit secondes, le temps que le document arrive en entier, puis redémarre le portail. L’impression suivante trouvera ainsi un portail neuf ;
• en filet de sécurité, si l’erreur de socket apparaît quand même dans le journal, il redémarre aussi le portail. Cette impression-là est perdue, mais la suivante passera.

La première version n’avait que le filet de sécurité. Elle réparait après coup, donc une impression sur deux continuait à se perdre : c’est le tableau du début. C’est le premier déclencheur qui règle vraiment le problème.

Le script

À enregistrer dans ~/.local/bin/cpdb-portail-veille, puis à rendre exécutable avec chmod +x.

#!/bin/bash
DELAI=8          # secondes laissées au document pour arriver dans CUPS
VERROU="${XDG_RUNTIME_DIR:-/tmp}/cpdb-portail-veille.dernier"

relever() {
    local maintenant dernier
    maintenant=$(date +%s)
    dernier=$(cat "$VERROU" 2>/dev/null || echo 0)
    (( maintenant - dernier < 5 )) && return      # pas deux fois de suite
    echo "$maintenant" > "$VERROU"
    echo "$1 : redemarrage du portail GNOME"
    systemctl --user restart xdg-desktop-portal-gnome.service
}

# 1. Une impression vient de partir : on relève le portail pour la suivante
stdbuf -oL dbus-monitor --system \
    "type='signal',interface='org.cups.cupsd.Notifier',member='JobCreated'" 2>/dev/null |
while IFS= read -r ligne; do
    [[ "$ligne" == *"member=JobCreated"* ]] || continue
    ( sleep "$DELAI"; relever "impression envoyee" ) &
done &

# 2. Filet de sécurité : l'erreur de socket est apparue quand même
journalctl --user -f -n0 --output=cat _SYSTEMD_USER_UNIT=xdg-desktop-portal-gnome.service |
while IFS= read -r ligne; do
    [[ "$ligne" == *"Error opening socket"* ]] || continue
    relever "socket CPDB ferme"
done

Le service

Pour qu’il tourne dès l’ouverture de session, un service utilisateur dans ~/.config/systemd/user/cpdb-portail-veille.service :

[Unit]
Description=Releve le portail GNOME quand le socket d'impression CPDB se ferme

[Service]
Type=simple
ExecStart=%h/.local/bin/cpdb-portail-veille
Restart=always
RestartSec=5

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now cpdb-portail-veille.service

Vérifier sans gâcher de papier

On peut déclencher le veilleur avec un travail mis en attente, qu’on annule aussitôt :

lp -d Brother_direct -H hold un_fichier.pdf
cancel -a Brother_direct
# Dix secondes plus tard :
journalctl --user -u cpdb-portail-veille --since "-1 min"

Le journal doit afficher impression envoyee : redemarrage du portail GNOME. Chez moi, depuis la mise en place du premier déclencheur le 3 octobre à midi, six travaux se sont enchaînés sans qu’aucune erreur de socket ne revienne dans le journal. Une après-midi, c’est encore court : je mettrai ce billet à jour si le problème reparaît.

Le cas de Chrome

Le veilleur ne règle pas tout. Google Chrome, installé depuis le paquet .deb, charge GTK4 et CPDB dans son propre processus, sans passer par le portail. Redémarrer le portail ne lui fait donc aucun effet.

La parade est de lui faire utiliser GTK3, qui possède encore son propre moteur d’impression CUPS, sans CPDB :

google-chrome-stable --gtk-version=3

Pour que ce soit permanent, copiez le lanceur système dans votre dossier personnel et ajoutez l’option sur chaque ligne Exec= :

cp /usr/share/applications/google-chrome.desktop ~/.local/share/applications/
sed -i 's|google-chrome-stable|google-chrome-stable --gtk-version=3|' \
    ~/.local/share/applications/google-chrome.desktop

Si un lanceur com.google.Chrome.desktop existe aussi, il faut lui appliquer le même traitement. On vérifie ensuite quelle bibliothèque Chrome a réellement chargée :

grep -o 'libgtk-[34][^ ]*' /proc/$(pgrep -o chrome)/maps | sort -u

Deux limites à connaître : une mise à jour de Chrome ne touche pas à cette copie personnelle, mais la copie ne suivra pas non plus les changements éventuels du lanceur d’origine. Et l’option ne vaut que pour les lancements qui passent par ce lanceur.

Ce que j’en retiens

Trois choses, par ordre d’utilité.

Regarder si le travail arrive dans CUPS avant de toucher à l’imprimante. Une seule commande, lpstat -W all -o, m’aurait épargné la création d’une file inutile. Pas de travail dans la liste : le problème est en amont.

Lire le journal de la session, pas seulement celui du système. Le portail tourne au nom de l’utilisateur, ses erreurs sont dans journalctl --user. Celui de CUPS, lui, était parfaitement propre, et pour cause.

Une panne silencieuse coûte plus cher qu’une panne bruyante. Le défaut tient en une ligne de journal. Ce qui a coûté du temps, c’est qu’aucune fenêtre n’ait dit « l’impression a échoué ».

❦