Si SUSE Linux Enterprise signale que Zypper est verrouillé par un autre processus, attendez la fin de toute mise à jour logicielle, opération sur un paquet YaST ou tâche de maintenance automatisée en cours. Vérifiez quel processus de gestion de paquets est en train de bloquer l'activité avant d'interrompre toute opération. Si aucune opération n'est en cours et que le verrouillage persiste, examinez l'état du système sans supprimer les fichiers de verrouillage sans précaution ; puis relancez Zypper. Un verrouillage créé avec une autre méthode zypper addlockconstitue un problème différent et nécessite une solution différente.
Zypper et les outils de gestion de paquets sous-jacents protègent les transactions de paquets contre les modifications simultanées. Une actualisation, un correctif, une installation, une tâche logicielle YaST ou une mise à jour planifiée peut temporairement empêcher une seconde transaction. Le verrou est un mécanisme de coordination : le supprimer pendant que RPM ou Zypper modifie encore des paquets peut rendre la base de données de paquets ou le système incohérent.
Distinction vérifiée : un verrouillage de processus empêche les opérations simultanées sur les paquets ; un verrouillage de paquet empêche la sélection d'un paquet spécifique pour installation, mise à jour ou suppression. La documentation SUSE décrit les verrouillages de paquets comme une fonctionnalité distincte. Le guide de SUSE sur la création de paquets RPM explique les verrouillages de paquets Zypper . Si l'erreur mentionne un autre processus ou indique que le gestionnaire de paquets est occupé, commencez par les vérifications de processus ci-dessous. Si elle indique qu'un paquet particulier est verrouillé ou exclu, exécutez sudo zypper lockset examinez plutôt les règles de paquets listées.
Veuillez patienter quelques minutes si une mise à jour, une installation ou une actualisation de dépôt vient de démarrer. Sur un serveur, vérifiez d'abord auprès de l'administrateur ou du responsable de la maintenance automatisée ; une tâche de correctif en arrière-plan peut ne pas afficher de terminal.
ps -eo pid,ppid,etime,stat,cmd | grep -E '[z]ypper|[r]pm|packagekit|YaST|yast'Recherchez une tâche Zypper, RPM, YaST ou PackageKit et notez son PID, son temps d'exécution et sa commande. L'expression grep évite de prendre en compte la commande de recherche elle-même pour Zypper et RPM. La liste des processus étant un instantané, répétez l'opération après une courte attente si le résultat n'est pas clair. L'exemple ci-dessous est une illustration de la sortie du terminal, et non un rapport provenant d'une machine réelle.
Ce qui n'est pas encore établi : l'affichage d'un processus ne prouve pas qu'il est bloqué. Une transaction de paquet peut être en train de télécharger des métadonnées ou d'attendre de l'espace de stockage ou un dépôt. Ne l'interrompez pas simplement parce que la commande est restée silencieuse. Si elle progresse, laissez-la se terminer et relancez ensuite la commande Zypper d'origine.
Les installations de bureau peuvent utiliser PackageKit, tandis que les serveurs gérés peuvent exécuter des mises à jour planifiées via les minuteurs systemd ou SUSE Manager. Cochez uniquement les services présents sur votre hôte :
systemctl status packagekit
systemctl list-timers --allSi PackageKit est absent, systemd signale que l'unité est introuvable ; cela ne signifie pas que Zypper est défectueux. S'il est actif, consultez ses entrées de journal récentes et vérifiez qu'aucune installation ou mise à jour n'est en cours avant d'envisager son arrêt.
sudo journalctl -u packagekit --since "30 minutes ago"Lorsqu'une opération PackageKit confirmée est terminée mais que son service reste actif et bloque Zypper, veuillez contacter la personne ou l'automatisation en charge des mises à jour. Sur un hôte où son arrêt est approprié, utilisez la commande appropriée sudo systemctl stop packagekit, puis vérifiez avec la commande `package-service` systemctl status packagekit. Ne désactivez pas le service ni n'arrêtez les minuteurs de mise à jour non liés comme solution générale. Les noms et les planifications de mise à jour dépendent des composants installés sur le système et de sa politique de gestion.
Un verrou obsolète peut survenir suite à une interruption de session, un redémarrage ou l'échec d'une tâche de gestion, mais sa présence seule n'en identifie pas la cause. La documentation utilisateur de SUSE ne fournit pas d'instruction universelle pour supprimer un fichier de verrou pour toutes les versions et configurations de SLES. Évitez d'utiliser des commandes telles que ` rmdelete` sur des chemins indéterminés et ne les utilisez pas kill -9sur un PID inconnu. Un fichier de verrou peut être recréé ou remplacé pendant qu'une transaction est active, et sa suppression n'arrête pas le processus propriétaire de la transaction.
Revérifiez la liste des processus, examinez les journaux de service pertinents et assurez-vous qu'aucune opération de paquetage n'est en cours. Si vous identifiez un fichier PID obsolète ou un chemin de verrouillage, vérifiez son propriétaire et confirmez avec la procédure documentée pour votre Service Pack SLES ou les instructions du support avant de le modifier. Pour les systèmes de production, capturez l'erreur exacte et les journaux, puis suivez la procédure de support SUSE de votre organisation. C'est à ce stade que les détails locaux sont importants : le texte de l'erreur, le Service Pack SLES, les outils de bureau installés et l'agent de gestion peuvent influencer la mesure de récupération appropriée.
Une fois l'opération concurrente terminée, actualisez les métadonnées du référentiel :
sudo zypper refreshUne actualisation réussie confirme que Zypper peut désormais accéder à ses dépôts et que le verrouillage du processus ne bloque plus cette commande. Si votre tâche initiale consistait à corriger le système, veuillez prévisualiser les modifications proposées avant de les appliquer :
sudo zypper patch --dry-runExaminez les paquets et les actions dans le résultat. Une exécution à blanc est une vérification de planification ; elle n'installe pas les mises à jour listées. Lorsque la proposition est attendue et que votre fenêtre de maintenance le permet, exécutez la commande sudo zypper patch. La documentation SUSE SLES 15 SP7 couvre la gestion des logiciels en ligne de commande, notamment l'installation et la désinstallation ; le comportement des commandes et les options disponibles peuvent varier selon la version. Consultez la documentation de gestion des logiciels SLES 15 SP7 et la référence Zypper de SUSE .
zypper lockslorsqu'un package nommé est explicitement verrouillé ; ne supprimez pas les règles de package pour effacer une transaction en cours.Le problème est résolu lorsque sudo zypper refreshl'opération s'achève sans erreur de verrouillage et que la commande prévue peut être exécutée. sudo zypper patch --dry-runAvant toute application de correctif, examinez et confirmez les actions proposées. Si le verrouillage se reproduit, notez l'erreur exacte, la liste des processus, l'état des services concernés, les dernières entrées du journal et la version de SLES. Ensuite, recherchez le processus ou l'outil de gestion qui réacquiert le verrouillage plutôt que de supprimer systématiquement l'état du verrou.
Identifiez le processus qui détient le verrou du paquet Zypper, distinguez les conflits de processus des verrous de paquets et réessayez les mises à jour sans supprimer aveuglément les fichiers de verrouillage.
Enregistrez SLE HA, initialisez SLES 15 nœuds, puis ajoutez le fencing, le quorum et les ressources de service testées avant de vous fier au basculement.
Identifiez l'origine d'une erreur d'actualisation Zypper : SUSE, RMT ou un point de terminaison tiers. Appliquez ensuite la correction côté serveur ou de cache appropriée sans désactiver les mises à jour essentielles.
Résolvez les erreurs d'espace du pool fin SUSE LVM en vérifiant l'utilisation des données et des métadonnées, en étendant le pool en toute sécurité et en évitant les pannes répétées.
Identifiez si Btrfs est intentionnellement en lecture seule, manque d'espace ou protège les données après des erreurs, puis choisissez une méthode de récupération adaptée à la cause.
Préparez des canaux miroirs, créez une clé d'activation et initialisez un client SLES 15 sans accès Internet direct tout en préservant la connexion nécessaire aux enregistrements du gestionnaire.
Corrigez l'erreur de lancement XIO de YaST via SSH, vérifiez le transfert X11 et xauth, et passez à l'interface ncurses lorsqu'une fenêtre distante n'est pas nécessaire.
Trouvez l'instantané Btrfs antérieur à la mise à jour, testez-le en lecture seule et rendez la récupération permanente avec Snapper tout en comprenant quelles données restent en dehors de la restauration racine.
Envoyer les journaux système SLES à un collecteur rsyslog distant via TLS authentifié, avec vérifications de certificat, mise en mémoire tampon en cas de panne et tests de livraison.
Utilisez les journaux RAM, swap, noyau et Zypper pour identifier la pression réelle sur la mémoire, protéger l'état du paquet et choisir une nouvelle tentative de mise à niveau SLES plus sûre.
