Como remover um cadeado Zypper com segurança no SUSE Linux Enterprise

Se o SUSE Linux Enterprise reportar que o Zypper está bloqueado por outro processo, primeiro deixe qualquer atualização de software, operação de pacote do YaST ou tarefa de manutenção automatizada em andamento terminar. Verifique qual processo de gerenciamento de pacotes é o responsável pela tarefa antes de interromper qualquer coisa. Se nenhuma operação de pacote estiver em execução e o bloqueio persistir, investigue o estado obsoleto sem excluir arquivos de bloqueio indiscriminadamente; em seguida, tente executar o Zypper novamente. Um bloqueio de pacote criado com outro método zypper addlocké um problema diferente e requer uma solução diferente.

O que significa "bloqueado por outro processo"?

O Zypper e as ferramentas subjacentes de gerenciamento de pacotes protegem as transações de pacotes contra alterações sobrepostas. Uma atualização, aplicação de patch, instalação, tarefa de software do YaST ou atualização agendada pode impedir temporariamente uma segunda transação. O bloqueio é um mecanismo de coordenação: removê-lo enquanto o RPM ou o Zypper ainda estão alterando pacotes pode deixar o banco de dados de pacotes ou o sistema em um estado inconsistente.

Distinção verificada: um bloqueio de processo impede operações simultâneas de pacotes; um bloqueio de pacote impede que um pacote específico seja selecionado para instalação, atualização ou remoção. A documentação da SUSE descreve os bloqueios de pacote como um recurso separado. O guia de empacotamento RPM da SUSE explica os bloqueios de pacote do Zypper . Se o erro mencionar outro processo ou indicar que o gerenciador de pacotes está ocupado, comece verificando os processos abaixo. Se o erro indicar que um pacote específico está bloqueado ou excluído, execute sudo zypper lockse revise as regras de pacote listadas.

1. Verificar se uma operação de pacote ainda está em execução.

Aguarde alguns minutos se uma atualização, instalação ou atualização de repositório acabou de ser iniciada. Em um servidor, verifique primeiro com o administrador ou responsável pela automação de manutenção; uma tarefa de aplicação de patches em segundo plano pode não ter um terminal visível.

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

Procure por uma tarefa real do Zypper, RPM, YaST ou PackageKit e anote seu PID, tempo decorrido e comando. A expressão grep evita a correspondência com o próprio comando de busca para Zypper e RPM. A listagem de processos é um instantâneo, portanto, repita-a após uma breve espera se o resultado não for claro. O exemplo abaixo é uma visualização ilustrativa do terminal, não um relatório de uma máquina real.

O que ainda não está comprovado: ver um processo em execução não significa que ele esteja travado. Uma transação de pacote pode estar baixando metadados ou aguardando armazenamento ou um repositório. Não a interrompa apenas porque o comando está inativo. Se estiver em andamento, deixe-a terminar e execute novamente o comando Zypper original em seguida.

2. Verifique os serviços de gerenciamento de software e as tarefas de manutenção.

As instalações em desktops podem usar o PackageKit, enquanto os servidores gerenciados podem executar atualizações agendadas por meio de temporizadores do systemd ou do SUSE Manager. Verifique apenas os serviços que existem no seu host:

systemctl status packagekit
systemctl list-timers --all

Se o PackageKit estiver ausente, o systemd reportará que a unidade não foi encontrada; isso não significa que o Zypper esteja com defeito. Se estiver ativo, verifique as entradas recentes do journal e confirme se nenhuma instalação ou atualização está em andamento antes de considerar pará-lo.

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

Quando uma operação do PackageKit confirmada for concluída, mas o serviço permanecer ativo e estiver bloqueando o Zypper, coordene com a pessoa ou automação responsável pelo gerenciamento de atualizações. Em um host onde a interrupção seja apropriada, use `zypper -r` sudo systemctl stop packagekit, e verifique com `zypper -r` systemctl status packagekit. Não desative o serviço nem interrompa temporizadores de atualização não relacionados como uma solução geral. Os nomes e os cronogramas de atualização dependem dos componentes instalados no sistema e da política de gerenciamento.

3. Se nenhum proprietário estiver ativo, investigue uma fechadura obsoleta com segurança.

Um arquivo de bloqueio obsoleto pode ser consequência de uma sessão interrompida, uma reinicialização ou uma tarefa de gerenciamento com falha, mas sua presença por si só não identifica a causa. A documentação do usuário da SUSE não fornece uma instrução universal para excluir um arquivo de bloqueio para todas as versões e configurações do SLES. Evite comandos como ` rmlock` em caminhos incertos e não os utilize kill -9em um PID desconhecido. Um arquivo de bloqueio pode ser recriado ou substituído enquanto uma transação estiver ativa, e excluí-lo não interrompe o processo que possui a transação.

Verifique novamente a lista de processos, inspecione os logs de serviço relevantes e certifique-se de que nenhuma operação de pacote esteja em andamento. Se identificar um arquivo PID ou caminho de bloqueio desatualizado, verifique o proprietário e confirme com o procedimento documentado para o seu pacote de serviços SLES específico ou com as orientações de suporte antes de alterá-lo. Para sistemas de produção, capture o erro e os logs exatos e siga o processo de suporte SUSE da sua organização. É aqui que os detalhes locais importam: o texto do erro, o pacote de serviços SLES, as ferramentas de desktop instaladas e o agente de gerenciamento podem influenciar a ação de recuperação correta.

4. Tente novamente com o Zypper e revise a transação.

Assim que a operação concorrente for concluída, atualize os metadados do repositório:

sudo zypper refresh

Uma atualização bem-sucedida confirma que o Zypper agora pode acessar seus repositórios e que o bloqueio do processo não impede mais a execução desse comando. Se sua tarefa original era aplicar patches no sistema, visualize as alterações propostas antes de aplicá-las:

sudo zypper patch --dry-run

Analise os pacotes e ações na saída. Uma execução a seco é uma verificação de planejamento; ela não instala as atualizações listadas. Quando a proposta for esperada e sua janela de manutenção permitir, execute o comando sudo zypper patch. A documentação do SLES 15 SP7 da SUSE abrange o gerenciamento de software pela linha de comando, incluindo a instalação e remoção de software; o comportamento do comando e as opções disponíveis podem variar de acordo com a versão. Consulte a documentação de gerenciamento de software do SLES 15 SP7 e a referência do Zypper da SUSE .

Suposições comuns a evitar

• "O bloqueio está sempre desatualizado." Essa informação não foi confirmada apenas pela mensagem. Pode se tratar de uma atualização real. Verifique primeiro os processos ativos e os registros.
• “Um bloqueio de pacote e um bloqueio de processo são a mesma coisa.” São controles separados. Use-os zypper locksquando um pacote específico estiver explicitamente bloqueado; não remova as regras do pacote para limpar uma transação em execução.
• "Excluir um arquivo de bloqueio corrige o proprietário." Isso não encerra um processo ativo nem conclui sua transação com segurança. Identifique o proprietário primeiro e use as orientações específicas da versão para estados obsoletos.
• “Reiniciar o servidor é a solução normal.” Uma reinicialização pode interromper alterações de pacotes e não se justifica apenas pela ocorrência do erro. Use-a somente quando seu procedimento de manutenção ou as diretrizes de suporte assim o exigirem.

Verifique a correção

O problema é resolvido quando sudo zypper refresha operação é concluída sem erros de bloqueio e o comando pretendido pode ser executado. Para a aplicação de patches, inspecione sudo zypper patch --dry-rune confirme as ações propostas antes de aplicar qualquer coisa. Se o bloqueio retornar, registre o erro exato, a lista de processos, o status do serviço relevante, a saída recente do journal e a versão do SLES. Em seguida, investigue o processo ou a ferramenta de gerenciamento que o readquire, em vez de excluir repetidamente o estado de bloqueio.