Ștergeți în siguranță un blocaj Zypper pe SUSE Linux Enterprise

Dacă SUSE Linux Enterprise raportează că Zypper este blocat de un alt proces, permiteți mai întâi finalizarea oricărei actualizări de software active, a operațiunii de pachet YaST sau a oricărei operațiuni de întreținere automată. Verificați ce proces de gestionare a pachetelor deține lucrarea înainte de a opri orice. Dacă nicio operațiune de pachet nu rulează și blocarea persistă, investigați starea învechită fără a șterge orbește fișierele de blocare; apoi încercați din nou Zypper. O blocare de pachet creată cu zypper addlockeste o problemă diferită și necesită o remediere diferită.

Ce înseamnă „blocat de un alt proces”?

Zypper și instrumentele de gestionare a pachetelor subiacente protejează tranzacțiile pachetelor de modificările care se suprapun. O reîmprospătare, o aplicare a unui patch, o instalare, o sarcină software YaST sau o actualizare programată poate împiedica temporar o a doua tranzacție. Blocarea este un mecanism de coordonare: eliminarea ei în timp ce RPM sau Zypper încă modifică pachetele poate lăsa baza de date a pachetelor sau sistemul într-o stare inconsistentă.

Distincție verificată: o blocare a procesului previne operațiunile simultane pe pachete; o blocare a pachetului previne selectarea unui pachet denumit pentru instalare, actualizare sau eliminare. Documentația SUSE descrie blocările pachetelor ca o caracteristică separată. Ghidul SUSE pentru ambalare RPM explică blocările pachetelor Zypper . Dacă eroarea denumește un alt proces sau indică faptul că managerul de pachete este ocupat, începeți cu verificările de proces de mai jos. Dacă indică faptul că un anumit pachet este blocat sau exclus, rulați sudo zypper locksși examinați în schimb regulile de pachet listate.

1. Verificați dacă o operațiune de pachet este încă în execuție

Așteptați câteva minute dacă tocmai a început o actualizare, o instalare sau o reîmprospătare a depozitului. Pe un server, verificați mai întâi cu administratorul sau proprietarul automatizării de mentenanță; o lucrare de corecție în fundal poate să nu aibă un terminal vizibil.

ps -eo pid,ppid,etime,stat,cmd | grep -E '[z]ypper|[r]pm|packagekit|YaST|yast'

Căutați o sarcină reală Zypper, RPM, YaST sau PackageKit și notați PID-ul acesteia, timpul scurs și comanda. Expresia grep evită potrivirea comenzii de căutare în sine pentru Zypper și RPM. O listă de procese este o instantanee, așa că repetați-o după o scurtă așteptare dacă rezultatul este neclar. Exemplul de mai jos este o vizualizare ilustrativă a terminalului, nu un raport de la o mașină reală.

Ceea ce nu este încă stabilit: faptul că vezi un proces nu dovedește că este blocat. O tranzacție de pachet poate descărca metadate sau poate aștepta spațiu de stocare sau un depozit. Nu o închideți doar pentru că comanda a fost silențioasă. Dacă progresează, permiteți-i să se termine și rulați din nou comanda Zypper originală ulterior.

2. Verificați joburile de service și întreținere a software-ului

Instalările desktop pot utiliza PackageKit, în timp ce serverele gestionate pot rula actualizări programate prin intermediul temporizatoarelor systemd sau SUSE Manager. Bifați doar serviciile care există pe gazda dvs.:

systemctl status packagekit
systemctl list-timers --all

Dacă PackageKit lipsește, systemd raportează că unitatea nu a putut fi găsită; asta nu înseamnă că Zypper este defect. Dacă este activ, verificați intrările recente din jurnal și confirmați că nu este în curs nicio instalare sau actualizare înainte de a lua în considerare o oprire:

sudo journalctl -u packagekit --since "30 minutes ago"

Când o operațiune PackageKit confirmată s-a finalizat, dar serviciul său rămâne activ și blochează Zypper, coordonați-vă cu persoana sau automatizarea care gestionează actualizările. Pe o gazdă unde oprirea acesteia este potrivită, utilizați sudo systemctl stop packagekit, apoi verificați cu systemctl status packagekit. Nu dezactivați serviciul și nu opriți temporizatoarele de actualizare fără legătură ca soluție generală. Numele și programele de actualizare depind de componentele instalate ale sistemului și de politica de gestionare.

3. Dacă niciun proprietar nu este activ, investigați în siguranță o încuietoare veche

O blocare învechită poate apărea în urma unei sesiuni întrerupte, a unei reporniri sau a unei sarcini de gestionare eșuate, dar prezența sa în sine nu identifică cauza. Documentația utilizatorului SUSE nu oferă o instrucțiune universală pentru a șterge un fișier de blocare pentru fiecare versiune și configurație SLES. Evitați comenzi precum cele rmîmpotriva căilor ghicite și nu utilizați kill -9pe un PID necunoscut. Un fișier de blocare poate fi recreat sau înlocuit în timp ce o tranzacție este activă, iar ștergerea acestuia nu oprește procesul care deține tranzacția.

Verificați din nou lista de procese, inspectați jurnalele de service relevante și asigurați-vă că nu este în curs nicio operațiune asupra pachetului. Dacă puteți identifica un fișier PID sau o cale de blocare învechită, verificați proprietarul acestuia și confirmați procedura documentată pentru pachetul service pack SLES exact sau instrucțiunile de asistență înainte de a le modifica. Pentru sistemele de producție, capturați eroarea și jurnalele exacte și urmați procesul de asistență SUSE al organizației dvs. Acesta este punctul în care contează detaliile locale: textul erorii, pachetul service pack SLES, instrumentele desktop instalate și agentul de gestionare pot modifica acțiunea de recuperare corectă.

4. Încercați din nou Zypper și verificați tranzacția

După finalizarea operațiunii concurente, actualizați metadatele depozitului:

sudo zypper refresh

O reîmprospătare reușită confirmă faptul că Zypper poate acum accesa depozitele sale și că blocarea procesului nu mai blochează acea comandă. Dacă sarcina inițială a fost să aplicați patch-uri la sistem, previzualizați modificările propuse înainte de a le aplica:

sudo zypper patch --dry-run

Examinați pachetele și acțiunile din rezultat. O rulare preliminară este o verificare a planificării; nu instalează actualizările listate. Când propunerea este așteptată și fereastra de mentenanță o permite, executați comanda sudo zypper patch. Documentația SLES 15 SP7 de la SUSE acoperă gestionarea software-ului din linia de comandă, inclusiv instalarea și eliminarea software-ului; comportamentul comenzilor și opțiunile disponibile pot varia în funcție de versiune. Consultați documentația de gestionare a software-ului SLES 15 SP7 și referința Zypper de la SUSE .

Presupuneri comune de evitat

• „Blocarea este mereu veche.” Nu este verificată doar de mesaj. Este posibil să aparțină unei actualizări reale. Verificați mai întâi procesele active și jurnalele.
• „O blocare a pachetului și o blocare a procesului sunt aceleași lucruri.” Sunt controale separate. Se utilizează zypper locksatunci când un pachet denumit este blocat explicit; nu eliminați regulile pachetului pentru a șterge o tranzacție care rulează.
• „Ștergerea unui fișier de blocare corectează proprietarul.” Nu termină un proces activ și nu finalizează în siguranță tranzacția acestuia. Identificați mai întâi proprietarul și utilizați îndrumările specifice versiunii pentru starea învechită.
• „Repornirea serverului este soluția normală.” O repornire poate întrerupe modificările pachetului și nu este justificată doar de eroare. Folosiți-o numai atunci când procedura de întreținere sau îndrumările de asistență o solicită.

Verificați remedierea

Problema este rezolvată atunci când sudo zypper refreshprocesul se finalizează fără o eroare de blocare și comanda dorită poate fi executată. Pentru aplicarea corecțiilor, inspectați sudo zypper patch --dry-runși confirmați acțiunile propuse înainte de a aplica orice. Dacă blocarea reapare, înregistrați eroarea exactă, lista de procese, starea serviciilor relevante, ieșirea recentă a jurnalului și versiunea SLES, apoi investigați procesul sau instrumentul de gestionare care o redobândește, în loc să ștergeți în mod repetat starea de blocare.