Résoudre le problème « Zypper verrouillé par un autre processus » dans SUSE Linux Enterprise

Le message « Zypper est verrouillé par un autre processus » signifie qu'une autre tâche de gestion de paquets bloque le verrou de gestion des logiciels du système. Il peut s'agir d'une mise à jour en cours, d'un outil de mise à jour graphique, de YaST, d'une tâche automatisée ou, plus rarement, d'un verrouillage obsolète suite à l'interruption d'une tâche. La solution appropriée dépend du cas. Attendre protège une transaction en cours ; interrompre une tâche bloquée peut être judicieux lors d'une opération de maintenance. Supprimer les fichiers de verrouillage ou arrêter les processus de paquets sans vérification préalable peut interrompre les modifications de paquets et compliquer la récupération.

Tout d'abord, confirmez le type de serrure que vous voyez.

Un verrou de processus et un verrou de paquet sont différents. Le verrou de processus empêche deux transactions de gestion de paquets de modifier le système simultanément. Un verrou de paquet, en revanche, est une règle d'administrateur qui empêche l'installation, la mise à jour ou la suppression de certains paquets. SUSE documente les verrous de paquets séparément ; la zypper lockscommande liste ces règles, mais n'identifie pas le processus qui détient le verrou de transaction.

Vérifiez le texte exact de l'erreur. Si elle mentionne un identifiant de processus (PID), notez-le. Si la commande est en attente plutôt qu'en échec, patientez et vérifiez si l'autre mise à jour progresse. Ne lancez pas YaST Software, une autre zyppercommande ou une mise à jour de l'agent de gestion pendant qu'une transaction est en cours.

Choisissez la réponse qui convient à la situation.

1. Trouvez le processus qui bloque le verrou.

Exécutez cette vérification en lecture seule depuis un terminal :

ps -eo pid,ppid,stat,etime,user,cmd | grep -E '[z]ypper|[y]ast|[p]ackagekit|[r]pm|[z]md'

La sortie peut révéler une mise à jour en ligne de commande, YaST, un client PackageKit ou un processus de gestion tel que l'agent client de SUSE Manager. Le nom du processus seul ne suffit pas à déterminer s'il peut être arrêté sans risque : une tâche de paquetage en cours d'exécution peut effectuer des opérations importantes. Vérifiez le temps écoulé, l'état du processus, le processus parent et toute fenêtre de mise à jour connue. Si vous n'êtes pas administrateur, demandez à un administrateur d'effectuer la vérification ou de confirmer le propriétaire du processus.

Si l'erreur signale un PID, examinez ce processus spécifique plutôt que de vous fier uniquement à une recherche textuelle :

ps -p 1234 -o pid,ppid,stat,etime,user,cmd

Remplacez 1234`<PID>` par l'identifiant du processus (PID) figurant dans votre message. Un processus utilisant le processeur, changeant d'état ou appartenant à un service de mise à jour connu doit généralement être autorisé à se terminer. S'il s'agit d'une commande terminale que vous avez lancée vous-même, retournez à ce terminal et consultez son invite de commande ou sa sortie de progression.

2. Décider s'il faut attendre ou interrompre une tâche

Attendez que la transaction soit active.

Si des paquets sont en cours de téléchargement ou d'installation, ou si la commande attend une confirmation, patienter est l'option la moins risquée. La mise à jour d'un paquet peut prendre plus de temps sur un disque lent, avec des lots de mises à jour importants ou sur un système contenant de nombreux paquets. Une fois la mise à jour terminée, réessayez votre commande initiale. Si aucune progression n'est visible pendant une durée anormalement longue, notez l'identifiant du processus (PID) et l'heure, puis consultez les journaux du terminal ou du service de mise à jour avant de prendre une décision.

N’arrêtez que les tâches que vous pouvez identifier et interrompre sans risque.

Si vous avez lancé une autre commande et qu'elle est toujours à l'invite de commande, répondez-y ou annulez-la à l'aide de l'option habituelle. Pour un programme de mise à jour de bureau, utilisez l'option d'annulation ou de fermeture prévue à cet effet. N'utilisez pas cette méthode kill -9comme raccourci. Un arrêt brutal peut interrompre une transaction RPM ou laisser le système dans un état nécessitant une réparation. Sur un serveur de production, coordonnez-vous avec le responsable des mises à jour et suivez votre procédure de maintenance au lieu d'interrompre un processus inconnu.

3. Vérifier les outils logiciels d'automatisation et graphiques

Sur les systèmes SLES gérés, les mises à jour peuvent être déclenchées par un administrateur, un planificateur ou un serveur de gestion central. Avant de lancer une nouvelle opération, consultez le calendrier de maintenance de votre organisation et l'état des tâches de mise à jour. Si le blocage se produit simultanément à plusieurs reprises, comparez les horodatages avec ceux des tâches planifiées. La solution durable consiste généralement à reprogrammer votre maintenance manuelle ou à organiser une fenêtre de mise à jour unique, et non à désactiver le service de gestion.

Sur un poste de travail, un centre logiciel ou une session YaST peut utiliser la même bibliothèque de gestion de paquets que Zypper. Fermez ou terminez l'opération logicielle via cette application. Ne présumez pas que « PackageKit » est présent sur toutes les installations SLES ; vérifiez le processus en cours avant d'exécuter des commandes de service. La désactivation globale d'un programme de mise à jour peut également empêcher la maintenance de sécurité prévue ; par conséquent, ne modifiez cette stratégie que si le propriétaire du système le souhaite.

4. Si le PID enregistré n'est plus en cours d'exécution

Si l'erreur mentionne un PID, vérifiez-le à nouveau ps -p PID. Si aucun processus n'existe, relancez la commande Zypper initiale. Certaines versions de la bibliothèque peuvent détecter la fin d'un processus enregistré et nettoyer l'état transitoire, mais ce comportement peut varier selon la version et la manière dont la commande précédente s'est terminée. Ne supprimez pas manuellement /run/zypp.pidle fichier de verrouillage simplement parce que le PID est absent. La documentation AutoYaST de SUSE avertit explicitement que la levée du verrouillage de gestion des paquets se fait aux risques et périls de l'utilisateur.

Si l'erreur persiste après la nouvelle tentative, arrêtez le système et notez l'erreur exacte, le Service Pack SLES, l'heure et l'historique des mises à jour récentes. Un redémarrage contrôlé peut résoudre un problème temporaire, mais ne le planifiez qu'après avoir vérifié qu'aucune opération de paquet n'est en cours et après avoir analysé son impact sur les services en cours d'exécution. Sur les systèmes critiques, demandez d'abord à l'administrateur ou au support SUSE d'examiner la situation.

5. Utilisez la commande de diagnostic appropriée

zypper psCette commande est utile après des modifications de paquets, mais elle est souvent mal comprise. Dans le Guide d'administration SLES, elle liste les processus utilisant encore des fichiers supprimés ou remplacés lors de l'application de correctifs, de mises à jour ou de la suppression de paquets. Ce n'est pas la commande permettant de déterminer qui détient actuellement le verrou de transaction Zypper. Utilisez psplutôt la commande `ls` suivie du PID indiqué dans le message de verrouillage pour cette tâche.

De même, zypper locksla liste des verrous au niveau des paquets est affichée. Il est utile de vérifier si un paquet individuel reste indisponible après la suppression du verrou de processus, mais cela ne libérera pas un verrou de transaction actif. Cette distinction est importante : la suppression d'un verrou de paquet ou la modification de la sélection de paquets ne peut pas résoudre le problème d'un autre processus utilisant toujours le gestionnaire de paquets.

Quand faut-il intensifier les efforts ?

Signalez le problème à votre administrateur système si le blocage se reproduit après chaque redémarrage, si un processus semble bloqué lors d'une mise à jour critique, si la base de données des paquets signale des erreurs supplémentaires ou si le système est géré de manière centralisée. Indiquez la commande exacte, le texte complet de l'erreur, le PID, la version ou le Service Pack de SLES, ainsi que le résultat de la vérification des processus en lecture seule. SUSE utilise /var/log/zypper.logle fichier journal de Zypper pour la documentation ; un administrateur peut y consulter les entrées relatives à l'heure de l'incident. Évitez de diffuser publiquement les journaux contenant des noms d'hôtes, des informations sur les dépôts, des noms d'utilisateur ou des chemins internes.

Vérifiez que Zypper est de nouveau disponible.

Une fois la transaction connue terminée (ou l'administrateur ayant résolu le problème d'obsolescence), exécutez une commande en lecture seule sans conséquence, telle que ` zypper install` zypper --versionou zypper repos`zypper install`. Si l'exécution se termine sans avertissement de verrouillage, réessayez la commande de mise à jour prévue pendant une fenêtre de mise à jour autorisée. Consultez les modifications proposées par Zypper avant de confirmer. Une commande réussie devrait s'exécuter sans interrompre un autre processus de gestion de paquets ; si le message de verrouillage réapparaît, identifiez le nouveau PID au lieu de supprimer des fichiers ou de répéter la transaction.

Références officielles SUSE

• Guide d'administration de SLES 15 SP6 : gestion des logiciels à l'aide d'outils en ligne de commande
• FAQ AutoYaST pour SLES 15 SP6 : Zypper et le verrouillage de la base de données RPM
• Guide d'administration de SLES 15 SP7 : dépannage et fichiers journaux
• documentation du projet libzypp