Remediați eroarea „Zypper blocat de un alt proces” în SUSE Linux Enterprise

Mesajul „Zypper este blocat de un alt proces” înseamnă că o altă sarcină de gestionare a pachetelor deține blocarea sistemului pentru gestionarea software-ului. Aceasta poate fi o actualizare normală în curs, un program de actualizare grafic, YaST, o lucrare de automatizare sau - mai rar - o stare de blocare învechită după o sarcină întreruptă. Soluția corectă depinde de situația în care vă aflați. Așteptarea protejează o tranzacție activă; oprirea unei sarcini identificate, dar blocate, poate fi potrivită în timpul unei ferestre de întreținere. Ștergerea fișierelor de blocare sau închiderea proceselor pachetului fără verificare poate întrerupe modificările pachetului și poate crea o problemă mai dificilă de recuperare.

Mai întâi, confirmă ce fel de lacăt vezi

O blocare de proces și o blocare de pachet sunt diferite. Blocarea de proces împiedică modificarea simultană a sistemului de către două tranzacții de gestionare a pachetelor. O blocare de pachet, prin contrast, este o regulă a administratorului care împiedică instalarea, actualizarea sau eliminarea pachetelor selectate. SUSE documentează blocările de pachet separat; comanda zypper lockslistează acele reguli de pachet, dar nu identifică procesul care deține o blocare de tranzacție.

Verificați textul exact al erorii. Dacă denumește un ID de proces (PID), înregistrați-l. Dacă comanda este în așteptare în loc să eșueze, lăsați-o nefuncțională pentru scurt timp și verificați dacă cealaltă actualizare progresează. Nu porniți software-ul YaST, o altă zyppercomandă sau o actualizare a agentului de gestionare în timp ce o tranzacție este activă.

Alege răspunsul care se potrivește situației

1. Găsiți procesul care menține blocarea

Rulați această verificare doar în citire dintr-un terminal:

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

Rezultatul poate dezvălui o actualizare din linia de comandă, YaST, un client PackageKit sau un proces de gestionare, cum ar fi agentul client SUSE Manager. Numele procesului în sine nu este suficient pentru a decide dacă oprirea este sigură: o sarcină de pachet care rulează poate efectua o muncă importantă. Verificați timpul scurs, starea procesului, procesul părinte și orice fereastră de actualizare pe care o cunoașteți. Dacă nu sunteți root, rugați un administrator să execute verificarea sau să confirme proprietarul procesului.

Dacă eroarea raportează un PID, inspectați procesul specific în loc să vă bazați doar pe o căutare de text:

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

Înlocuiți 1234cu PID-ul din mesajul dvs. Un proces care utilizează CPU, își schimbă starea sau aparține unui serviciu de actualizare cunoscut ar trebui, în general, să aibă voie să se finalizeze. Dacă este o comandă de terminal pe care ați inițiat-o dvs., reveniți la terminalul respectiv și citiți promptul curent sau ieșirea de progres.

2. Decideți dacă să așteptați sau să opriți o sarcină

Așteptați când tranzacția este activă

Dacă pachetele se descarcă, se instalează sau comanda așteaptă confirmare, așteptarea este opțiunea cu cel mai mic risc. O actualizare a unui pachet poate rula mai mult timp pe spațiu de stocare lent, seturi mari de actualizări sau sisteme cu multe pachete. Când se termină, încercați din nou comanda inițială. Dacă nu există progres pentru o perioadă neobișnuit de lungă, notați PID-ul și ora, apoi verificați jurnalele relevante ale terminalului sau ale serviciului de actualizare înainte de a decide ce să faceți.

Opriți doar o sarcină pe care o puteți identifica și întrerupe în siguranță

Dacă ați pornit cealaltă comandă și aceasta se află încă la un prompt interactiv, răspundeți la ea sau anulați-o acolo folosind opțiunea normală a promptului. Pentru un program de actualizare desktop, utilizați propria acțiune de anulare sau închidere dacă oferă în mod clar una. Nu utilizați kill -9ca o comandă rapidă. Terminarea bruscă poate întrerupe o tranzacție RPM sau poate lăsa sistemul într-o stare care necesită reparații suplimentare. Pe un server de producție, coordonați-vă cu proprietarul actualizării și urmați procedura de întreținere în loc să opriți un proces nefamiliar.

3. Verificați instrumentele software de automatizare și grafică

Pe sistemele SLES gestionate, actualizările pot fi declanșate de un administrator, un planificator sau un server central de gestionare. Verificați calendarul de întreținere al organizației dvs. și starea oricărei sarcini de actualizare înainte de a lansa o altă tranzacție. Dacă lacătul apare în mod repetat în același timp, comparați marcajele temporale cu sarcinile programate. Soluția durabilă poate fi reprogramarea întreținerii manuale sau coordonarea unei singure ferestre de actualizare - nu dezactivarea serviciului de gestionare.

Pe o stație de lucru, un centru software sau o sesiune YaST poate utiliza aceeași bibliotecă de gestionare a pachetelor ca și Zypper. Închideți sau terminați operațiunea software prin intermediul acelei aplicații. Nu presupuneți că „PackageKit” este prezent în fiecare instalare SLES; verificați procesul real înainte de a încerca comenzi de service. Dezactivarea globală a unui program de actualizare poate, de asemenea, împiedica întreținerea de securitate așteptată, așadar modificați politica respectivă doar dacă proprietarul sistemului intenționează să facă acest lucru.

4. Dacă PID-ul înregistrat nu mai rulează

Dacă eroarea denumește un PID, verificați-l din nou cu ps -p PID. Dacă nu există niciun proces, reîncercați comanda Zypper originală o dată. Unele versiuni de bibliotecă pot detecta că un proces înregistrat s-a încheiat și pot curăța starea tranzitorie, dar comportamentul poate varia în funcție de versiune și de modul în care s-a încheiat comanda anterioară. Nu eliminați manual /run/zypp.pidun alt fișier de blocare doar pentru că PID-ul lipsește. Documentația AutoYaST a SUSE avertizează în mod explicit că ruperea blocării de gestionare a pachetelor se face pe riscul utilizatorului.

Dacă eroarea persistă după reîncercare, opriți sistemul și colectați eroarea exactă, pachetul service pack SLES, ora și istoricul actualizărilor recente. O repornire controlată poate șterge o condiție tranzitorie, dar o programați numai după confirmarea faptului că nu există nicio operațiune activă a pachetului și după verificarea impactului asupra serviciilor care rulează. Pe sistemele critice, solicitați administratorului sau asistenței SUSE să revizuiască mai întâi starea.

5. Folosește comanda de diagnosticare corectă

zypper pseste utilă după modificările pachetelor, dar este adesea înțeleasă greșit. În Ghidul de administrare SLES, listează procesele care încă utilizează fișiere care au fost șterse sau înlocuite în timpul aplicării patch-urilor, actualizării sau eliminării pachetelor. Nu este comanda pentru a descoperi cine deține în prezent blocarea tranzacției Zypper. Folosiți psși PID-ul din mesajul de blocare pentru sarcina respectivă.

În mod similar, zypper lockslistează blocările la nivel de pachet. Merită să verificați dacă un pachet individual rămâne indisponibil după ce blocarea procesului a dispărut, dar nu va elibera o blocare activă a tranzacției. Distincția contează: ștergerea unei blocări a pachetului sau modificarea selecției unui pachet nu poate remedia un alt proces care încă utilizează managerul de pachete.

Când să escaladeze

Escalați problema către administratorul de sistem dacă blocarea revine după fiecare repornire, dacă un proces pare să se fi blocat în timpul unei actualizări critice, dacă baza de date a pachetelor raportează erori suplimentare sau dacă sistemul este gestionat central. Includeți comanda exactă, textul complet al erorii, PID-ul, versiunea SLES sau pachetul service pack și rezultatul verificării procesului doar în citire. SUSE documentează /var/log/zypper.logca fișier jurnal Zypper; un administrator poate inspecta intrările în jurul momentului erorii. Evitați partajarea publică a jurnalelor dacă acestea conțin nume de gazdă, detalii despre depozit, nume de utilizator sau căi interne.

Verificați dacă Zypper este din nou disponibil

După ce tranzacția cunoscută s-a finalizat — sau după ce administratorul a rezolvat condiția de blocare — executați o comandă doar pentru citire inofensivă, cum ar fi zypper --versionsau zypper repos. Dacă se finalizează fără avertismentul de blocare, încercați din nou comanda dorită pentru pachet în timpul unei ferestre de actualizare aprobate. Examinați modificările propuse de Zypper înainte de confirmare. O comandă reușită ar trebui să se finalizeze fără întreruperea unui al doilea proces de gestionare a pachetelor; dacă mesajul de blocare reapare, identificați noul PID în loc să ștergeți fișierele sau să repetați tranzacția.

Referințe oficiale SUSE

• Ghid de administrare SLES 15 SP6: gestionarea software-ului cu instrumente din linia de comandă
• Întrebări frecvente despre AutoYaST pentru SLES 15 SP6: Zypper și blocarea bazei de date RPM
• Ghid de administrare SLES 15 SP7: depanare și fișiere jurnal
• documentația proiectului libzypp