lvmetad trava na inicialização

Question

Eu tenho uma máquina rodando o Arch Linux que tem um problema na inicialização. Ele fica pendurado por 90s esperando por pvscan em dispositivos de bloco e, em seguida, desista. (na verdade, o processo pvscan ainda está travado, e qualquer comando lvm depois disso também irá travar). Às vezes funciona bem.

Depois de algumas pesquisas, parece que o lvmetad (8) é responsável por este travamento, já que ele trava no início:

lvmetad[360]: Cannot lock lockfile [/run/lvmetad.pid], error was [Resource temporarily unavailable]

Se eu matá-lo e iniciá-lo novamente após o boot, os processos pendentes do pvscan são desbloqueados, terminam seus trabalhos e tudo volta ao normal (os comandos lvm funcionam novamente, etc.)

Você pode ver isso nos registros: Pastebin

Eu tentei diminuir a verbosidade do lvmetad, mas só recebo o erro.

algumas vezes o boot é um pouco mais longo que o normal (esperando pela partição root), e o lvmetad começa bem (eu não tenho certeza se é realmente relacionado, no entanto)

Você tem uma ideia de como evitar esse erro?

Coletei mais informações :

• o erro "não é possível log logfile" aparece quando fcntl () falha com EAGAIN (um arquivo a ser bloqueado já está com bloqueio compartilhado ou bloqueio exclusivo por outro processo)
• há um lvmetad em execução no sistema, com um pid muito pequeno (muito menor do que o processo de falha que vemos nos logs)
• o processo lvmetad gerado pelo lvm2-lvmetad.service é executado com -f, portanto, o que está em execução não é esse
• o primeiro foi iniciado 3 segundos antes do segundo (antes do systemd)

O gancho de limpeza do componente lvm2 para initrd deve matar o lvmetad inicial, mas por alguma razão ele não funciona:

run_cleanuphook() {
    kill $(cat /run/lvmetad.pid)
}

matar o processo após a inicialização também não funciona.

Eu peguei um rastreio de depuração (não posso postar um terceiro link, coloquei no final da segunda pasta), e parece que o thread principal está aguardando terminações de outros threads, e há um client_thread preso em uma leitura no fd 6 (/run/lvm/lvmetad.socket)

    

Answer 1

Observe que o autor relatou isso como um bug para o Archlinux e há uma discussão útil aqui link