Não foi possível remontar / voltar para somente leitura após a atualização do pacote

Estou usando o Debian Stretch. Minha partição raiz está montada read-only. Somente quando eu instalo ou atualizo os pacotes, é /remontado para read-write(usando o apt hook) e depois remontado para ro.

Às vezes, após a atualização do pacote, não consigo /voltar ao modo somente leitura:

mount -o remount,ro /
mount: / is busy

Nas versões mais antigas do Debian (Wheezy), eu podia listar arquivos abertos que foram desvinculados de lsof:

 lsof +L1

ou, mais especificamente, arquivos que impedem a /remontagem de volta à ro:

{ lsof +L1 ; lsof|sed -n '/SYSV/d; /DEL|(path /p;' ; } | grep -Ev '/(dev|home|tmp|var)'

No entanto, no Debian Stretch, lsof +L1não lista nenhum arquivo.

Não vejo nenhuma alteração +|-Lno man lsofque explicaria por que parou de funcionar.

Por que lsof + L1 não lista mais os arquivos abertos que foram desvinculados?

Como posso listar os arquivos que impedem / sejam remontados para somente leitura?

ATUALIZAR

Eu parei de todos os processos que podem ser interrompidos, e só tem inite gettyainda em execução, mas eu ainda não pode remontar /a ro.

Como posso listar os arquivos que impedem / sejam remontados para somente leitura?

A) fuserpode ser encontrado no psmiscpacote; este é um caso de uso em que acho que fuserbrilha e é mais útil que lsof.

# fuser -v -m / 2>&1 | grep '[Ff]r.e'

Isso mostrará todos os processos que têm arquivos abertos em / para leitura (f) e gravação (F). Os arquivos que impediriam / sejam remontados para somente leitura são aqueles que são abertos para gravação (F).

Mate os processos que são executáveis ​​sendo executados com os arquivos do diretório raiz abertos para gravação .

# for fupid in $(fuser -v -m / 2>&1 | grep Fr.e | awk '{print $2}'); do kill $fupid; done

Isso está acima dos systemdcomentários com uma ressalva. Se systemdfor, initentão fusero verá e há outras considerações. Com a systemdexecução, ele pode (re) iniciar processos pelas suas costas, mesmo que apenas tenham sido identificados e eliminados fuser. systemdé muito mais avançado que o tradicional sysvinit.

B) O UPDATE na descrição indica que o sistema possui apenas ... inite gettyainda está em execução ...

Eu vejo o comentário que diz que o sistema não está usando systemd, está usando init. No trecho, systemd é init . O comentário não disse explicitamente sysvinit, portanto, suponho que o sistema em questão possa estar usando a extensão padrão systemdpara init. Ou que outras pessoas que tropeçam neste post, que usam trecho desystemd , acham essa parte útil.

De acordo com o Wiki Debian ,

O processo de inicialização do sistema é tratado pelo daemon init. No squeeze e nas versões anteriores, esse daemon é fornecido pelo pacote sysvinit e nenhuma alternativa é suportada. No wheezy , o daemon init padrão ainda está disponívelsysvinit , mas uma "visualização de tecnologia" do systemd está disponível. No jessie and stretch , o sistema init padrão ésystemd , mas a mudança para o sysvinit é suportada.

Desde Jessie, apenas o systemd é totalmente suportado; O sysvinit é suportado principalmente, mas os pacotes Debian não são necessários para fornecer scripts de início do sysvinit. O runit também é empacotado, mas não recebeu o mesmo nível de teste e suporte que os outros, e atualmente não é suportado pelo PID 1.

Com systemd execução, há algumas etapas adicionais que devem ser tomadas para liberar / para que possam ser remontadas sem problemas.

É provável que system.sliceesteja mantendo arquivos abertos para systemd-journald.serviceou systemd-udevd.service(ambos com dependências de soquete). Ou, se NetworkManagerestiver em execução ele pode reaparecer dhclientque escreve locações para / var / ... (& / var / nem sempre é seu próprio dispositivo), etc. fuserpode encontrar e você matar dhclient, mas NetworkManagercomeça-lo de volta para cima.

A moral é que muitas coisas são automatizadas que poderiam 'querer' / (e mais ainda com systemd).

Para ter certeza, se possível, o systemdequivalente ao nível de execução 1 é correspondido por rescue.target(e runlevel1.targeté um link simbólico para rescue.target).

1) Comece isolando o sistema para rescue.target

# systemctl isolate rescue.target

Deve solicitar que você digite a senha root; siga as instruções na tela.

2) No shell de resgate, descubra o que quer /.

# systemctl show -p Wants /

Normalmente, é system.slice; pare tudo o que quiser. por exemplo

# systemctl stop system.slice

3) Neste ponto, a remontagem não deve relatar mount: / is busye mount -o remount,ro / deve funcionar. Caso contrário, verifique novamente com fuser.

4) FWIW; Também vi vezes quando umountfalha quando / se outro dispositivo é montado em um subdiretório de outra montagem, ou seja, montagens aninhadas. Por exemplo, umount /falharia se / var / ou / boot / estivesse em outro dispositivo (e montado). Embora mount -o remount,ro /ainda deva funcionar neste caso.

lsblk pode ser útil para visualizar montagens aninhadas.

Por que lsof + L1 não lista mais os arquivos abertos que foram desvinculados?

Como eles não estão disponíveis (soquetes ou a maioria dos FIFOs e pipes), não são mais arquivos abertos (o processo pai fechou o descritor de arquivos) ou eles ainda têm uma contagem de links maior que 1.

man lsof (8) detalhes ...

+ | -L [l]

Esta opção ativa ('+') ou desativa ('-') a listagem das contagens de links de arquivos, onde elas estão disponíveis - por exemplo, elas não estão disponíveis para soquetes ou para a maioria dos FIFOs e tubulações.

Quando + L for especificado sem um número a seguir, todas as contagens de links serão listadas. Quando -L for especificado (o padrão), nenhuma contagem de links será listada.

Quando + L é seguido por um número, apenas os arquivos com uma contagem de links menor que esse número serão listados . (Nenhum número pode seguir -L.) Uma especificação no formato '' + L1 '' selecionará arquivos abertos que foram desvinculados. Uma especificação do formulário +aL1 <file_system>selecionará arquivos abertos não vinculados no sistema de arquivos especificado.

Você tem /proc montou?

Aparentemente, alguém que cuida de /montar somente leitura na maioria das vezes, posso imaginar que você também pode optar por não montar procfs. Mas procfs é necessário paralsof encontrar arquivos abertos.

Os arquivos mantidos abertos pelos processos são expostos pelo kernel através de links simbólicos no procfs. Os diretórios /proc/<pid>/fdcontêm um link simbólico para cada arquivo mantido aberto. O nome dos links simbólicos são os números dos descritores de arquivo e o caminho referenciado pelo link simbólico é o caminho do arquivo.

Os links simbólicos /procpendentes ainda permanecem em arquivos abertos que já foram excluídos. E o caminho referenciado do arquivo é renomeado para terminar com "(excluído)".

O lsof +L1que faz não é essencialmente diferente de uma linha rápida como:

stat -c%N /proc/[0-9]*/fd/* | grep deleted

Portanto, você pode usar uma linha única semelhante para listar todos os arquivos abertos que podem impedir a remontagem do sistema de arquivos raiz (desde que funcione /proc).

No entanto, se você /procmontou, as únicas outras causas em que consigo pensar são os erros ... Enfim, FYI, no meu atual sistema Debian Stretch. lsof +L1funciona como esperado.

bash# lsb_release -d
Description:    Debian GNU/Linux 9.5 (stretch)

bash# uname -a
Linux bwp-249-8 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux

bash# lsof -v
lsof version information:
    revision: 4.89
    [...]

Eu pude reproduzir esse problema apenas uma vez e resolvi-o usando apenas mountcom a opção -n .

Citando homem mount :

-n, --no-mtab
      Mount without writing in /etc/mtab.  This is necessary for example when /etc is on a read-only filesystem.

O mountpróprio programa que abriu arquivos para escrever no sistema de arquivos raiz pareceu uma explicação plausível para mim. Especificamente mountescreve /etc/mtabdepois de tudo e /etcmuitas vezes é parte do sistema de arquivos raiz. No entanto, não consegui reproduzi-lo novamente na mesma máquina depois que o fiz uma vez ...

Isso pode resolver seu problema?

Sem visibilidade em seu sistema, é muito difícil dizer exatamente qual é o problema. Os comentários e respostas anteriores são um bom começo.

Dito isto, eu voltaria até o wiki do debian que descreve os pré-requisitos para montagem / somente leitura.

O link para a documentação está aqui: https://wiki.debian.org/ReadonlyRoot

O grande eu vou levá-lo por aqui:

1 - existem locais específicos em / que devem ser lidos / gravados. Com base na documentação, é algo parecido com isto:

seus dispositivos de bloco provavelmente serão diferentes, dependendo da configuração da pilha de armazenamento (partições, lvm sem partições, etc.), mas a idéia principal é que você precisa desses 4 pontos de montagem para que seu sistema de arquivos montado subseqüente tenha a opção de montagem RW.

2 - existem vários arquivos especiais em / etc que você precisa para criar um link simbólico ou implementar alguma outra alteração (especificamente detalhada no artigo vinculado). Estes podem ou não se aplicar com base em quais aplicativos seu servidor linux está executando. alguns dos arquivos podem nem existir na sua máquina, mas incluí tudo nos documentos. Lembre-se de que recomendo fazer essas alterações, mesmo que você tenha matado o pid do processo. Aqui estão os caminhos diretamente do wiki debian:

• adjtime
• init.d / alsa-utils
• / etc / courier / shared / index
• quaisquer arquivos de estado de cups, classes.conf, cupsd.conf, printers.conf subscriptions.conf
• /etc/lvm/lvm.conf
• mtab (que parece que você tentou endereçar dando o sinalizador mount -n)
• rede / execução (usada por ifup e ifdown, em compressão. pode não se aplicar ao alongamento, ymmv)
• nologin
• resolv.conf
• arquivos passwd e shadow
• samba / dhcp.conf
• chupar
• udev

Depois de verificar todas as opções acima e confirmar que elas estão em conformidade com as especificações no wiki, a próxima coisa a verificar é /etc/apt/apt.conf

DPkg {
// Auto re-mounting of a readonly /
Pre-Invoke { "mount -o remount,rw /"; };
Post-Invoke { "test ${NO_APT_REMOUNT:-no} = yes || mount -o remount,ro / || true"; };
}; 

com base no seu erro, a última coisa que você pode verificar com base na documentação é a seguinte:

"Após uma atualização dos pacotes, você pode se deparar com o problema que a montadora se recusa a remontar o sistema de arquivos, dizendo-lhe" / está ocupado ". Isso é causado por arquivos excluídos que ainda são usados ​​por um processo. Para descobrir quais processos usam itens excluídos os arquivos usam a ferramenta checkrestart (1) do pacote debian-goodies ou usam o seguinte comando: Geralmente são daemons usando bibliotecas atualizadas. Você precisa reiniciá-los para que os arquivos sejam liberados. "

comando fornecido no doc .:

{lsof +L1; lsof|sed -n '/SYSV/d; /DEL\|(path /p;'} |grep -Ev '/(dev|home|tmp|var)'

Sem conhecer a configuração exata do sistema de arquivos, o particionamento e a configuração do dispositivo de armazenamento, é difícil fornecer muito mais a seguir. Eu começaria voltando e revisando seus pré-requisitos na documentação (e descrita acima).