Come rimuovere in modo sicuro un blocco Zypper su SUSE Linux Enterprise

Se SUSE Linux Enterprise segnala che Zypper è bloccato da un altro processo, attendere innanzitutto il completamento di eventuali aggiornamenti software, operazioni sui pacchetti YaST o attività di manutenzione automatizzata in corso. Verificare quale processo di gestione dei pacchetti detiene il controllo prima di interrompere qualsiasi operazione. Se non è in corso alcuna operazione sui pacchetti e il blocco persiste, esaminare lo stato di blocco senza eliminare indiscriminatamente i file di blocco; quindi riprovare con Zypper. Un blocco del pacchetto creato con zypper addlockè un problema diverso e richiede una soluzione diversa.

Cosa significa "bloccato da un altro processo"?

Zypper e gli strumenti di gestione dei pacchetti sottostanti proteggono le transazioni dei pacchetti da modifiche sovrapposte. Un aggiornamento, una patch, un'installazione, un'attività del software YaST o un aggiornamento pianificato possono impedire temporaneamente una seconda transazione. Il blocco è un meccanismo di coordinamento: rimuoverlo mentre RPM o Zypper stanno ancora modificando i pacchetti può lasciare il database dei pacchetti o il sistema in uno stato incoerente.

Distinzione verificata: un blocco di processo impedisce operazioni simultanee sui pacchetti; un blocco di pacchetto impedisce che un pacchetto specifico venga selezionato per l'installazione, l'aggiornamento o la rimozione. La documentazione di SUSE descrive i blocchi di pacchetto come una funzionalità separata. La guida di SUSE sui pacchetti RPM spiega i blocchi di pacchetto di Zypper . Se l'errore indica un altro processo o dice che il gestore di pacchetti è occupato, inizia con i controlli di processo riportati di seguito. Se dice che un pacchetto specifico è bloccato o escluso, esegui sudo zypper lockse rivedi le regole del pacchetto elencate.

1. Verifica se un'operazione di pacchetto è ancora in corso

Attendi qualche minuto se è appena stato avviato un aggiornamento, un'installazione o un aggiornamento del repository. Su un server, contatta prima l'amministratore o il responsabile dell'automazione della manutenzione; un'operazione di patch in background potrebbe non avere un terminale visibile.

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

Cerca un'attività Zypper, RPM, YaST o PackageKit reale e annota il suo PID, il tempo trascorso e il comando. L'espressione grep evita di trovare corrispondenze con il comando di ricerca stesso per Zypper e RPM. L'elenco dei processi è un'istantanea, quindi ripeti la ricerca dopo una breve attesa se il risultato non è chiaro. L'esempio seguente è una visualizzazione illustrativa del terminale, non un report di una macchina reale.

Ciò che non è ancora stato stabilito: vedere un processo non significa che sia bloccato. Una transazione di pacchetto potrebbe essere in fase di download di metadati o in attesa di spazio di archiviazione o di un repository. Non interromperla solo perché il comando non ha dato risultati. Se sta procedendo, lasciala terminare e poi esegui nuovamente il comando Zypper originale.

2. Verificare i servizi di gestione del software e le attività di manutenzione

Le installazioni desktop potrebbero utilizzare PackageKit, mentre i server gestiti potrebbero eseguire aggiornamenti pianificati tramite timer di systemd o SUSE Manager. Seleziona solo i servizi presenti sul tuo host:

systemctl status packagekit
systemctl list-timers --all

Se PackageKit non è presente, systemd segnala che l'unità non è stata trovata; ciò non significa che Zypper sia danneggiato. Se è attivo, controlla le voci recenti del suo registro e verifica che non siano in corso installazioni o aggiornamenti prima di considerare un arresto:

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

Quando un'operazione PackageKit confermata è terminata ma il relativo servizio rimane attivo e blocca Zypper, coordinarsi con la persona o l'automazione che gestisce gli aggiornamenti. Su un host in cui è opportuno arrestarlo, utilizzare sudo systemctl stop packagekit, quindi verificare con systemctl status packagekit. Non disabilitare il servizio o arrestare i timer di aggiornamento non correlati come soluzione generale. I nomi e le pianificazioni degli aggiornamenti dipendono dai componenti installati sul sistema e dalle politiche di gestione.

3. Se non è presente alcun proprietario attivo, esaminare in sicurezza una serratura guasta.

Un blocco obsoleto può verificarsi in seguito a una sessione interrotta, un riavvio o un'attività di gestione non riuscita, ma la sua sola presenza non ne identifica la causa. La documentazione utente di SUSE non fornisce un'unica istruzione universale per eliminare un file di blocco per ogni versione e configurazione di SLES. Evitare comandi come rmquelli utilizzati su percorsi ipotizzati e non utilizzarli kill -9su un PID sconosciuto. Un file di blocco può essere ricreato o sostituito mentre una transazione è attiva e la sua eliminazione non arresta il processo proprietario della transazione.

Ricontrolla l'elenco dei processi, esamina i log di servizio pertinenti e assicurati che non sia in corso alcuna operazione sui pacchetti. Se riesci a identificare un file PID o un percorso di blocco obsoleto, verifica il proprietario e conferma con la procedura documentata per il tuo specifico service pack SLES o con le linee guida di supporto prima di modificarlo. Per i sistemi di produzione, acquisisci l'errore e i log esatti e segui la procedura di supporto SUSE della tua organizzazione. È a questo punto che i dettagli locali diventano importanti: il testo dell'errore, il service pack SLES, gli strumenti desktop installati e l'agente di gestione possono influenzare la corretta azione di ripristino.

4. Riprova con Zypper e rivedi la transazione.

Una volta completata l'operazione concorrente, aggiornare i metadati del repository:

sudo zypper refresh

Un aggiornamento riuscito conferma che Zypper ora può accedere ai suoi repository e che il blocco del processo non impedisce più l'esecuzione del comando. Se il tuo compito originale era quello di applicare una patch al sistema, visualizza in anteprima le modifiche proposte prima di applicarle:

sudo zypper patch --dry-run

Esamina i pacchetti e le azioni nell'output. Una prova a secco è un controllo di pianificazione; non installa gli aggiornamenti elencati. Quando la proposta è prevista e la finestra di manutenzione lo consente, esegui sudo zypper patch. La documentazione di SUSE SLES 15 SP7 tratta la gestione del software da riga di comando, inclusa l'installazione e la rimozione del software; il comportamento dei comandi e le opzioni disponibili possono variare a seconda della versione. Consulta la documentazione sulla gestione del software di SLES 15 SP7 e il riferimento a Zypper di SUSE .

Presupposti comuni da evitare

• "Il blocco è sempre obsoleto." Questo messaggio non è sufficiente a confermarlo. Potrebbe trattarsi di un aggiornamento reale. Verificare prima i processi attivi e i log.
• "Il blocco di un pacchetto e il blocco di un processo sono la stessa cosa." Si tratta di controlli separati. Utilizzare zypper locksquando un pacchetto specifico è bloccato esplicitamente; non rimuovere le regole del pacchetto per terminare una transazione in corso.
• "L'eliminazione di un file di blocco risolve il problema del proprietario." Non termina un processo attivo né completa in modo sicuro la sua transazione. Identifica prima il proprietario e segui le linee guida specifiche della release per la gestione dello stato obsoleto.
• "Il riavvio del server è la soluzione standard." Un riavvio potrebbe interrompere le modifiche ai pacchetti e non è giustificato dal solo errore. Utilizzatelo solo quando la procedura di manutenzione o le linee guida dell'assistenza lo prevedono.

Verifica la correzione

Il problema si risolve quando sudo zypper refreshl'operazione viene completata senza errori di blocco e il comando previsto può essere eseguito. Per l'applicazione di patch, esaminare sudo zypper patch --dry-rune confermare le azioni proposte prima di applicarle. Se il blocco si ripresenta, registrare l'errore esatto, l'elenco dei processi, lo stato del servizio pertinente, l'output recente del journal e la versione di SLES, quindi analizzare il processo o lo strumento di gestione che lo riacquisisce anziché eliminare ripetutamente lo stato di blocco.