Substituindo um binário em execução no sistema de arquivos somente leitura

4

Eu tenho um script bash simples de atualizador, que substitui arquivos removendo os arquivos antigos incidentes e copiando novos arquivos de um arquivo morto para o sistema de arquivos raiz de destino incorporado em execução. Dessa forma, o script pode atualizar os arquivos do sistema, bem como o próprio script de atualização.

Recentemente, estendi o script para manipular um sistema de arquivos somente leitura, remontando com acesso R / W ( mount -o remount,rw /dev/rootfs / ), fazendo seu negócio de atualização e remontando novamente com acesso R / O ( mount -o remount,ro /dev/rootfs / ).

Essa abordagem falha, no entanto. Normalmente, o script falha na primeira execução no ponto de remontar novamente com o acesso ao R / O ou na segunda execução no ponto de remontar com acesso R / W. Esta é uma mensagem de erro representativa:

root@device:~# mount -o remount,rw /dev/rootfs /
EXT3-fs (mmcblk0p2): warning: couldn't remount RDWR because of unprocessed orphan inode list.  Please umount/remount instead.
mount: mounting /dev/rootfs on / failed: Invalid argument

Após algumas pesquisas (por exemplo, link ), percebi que o problema está no mecanismo como arquivos abertos são excluídos do sistema de arquivos. Ou seja, apenas um link para o arquivo inode é desvinculado no momento da chamada, enquanto o arquivo representado pelo inode é realmente excluído quando o arquivo é fechado por todos os programas que o utilizam. Então, quando eu remontar de volta ao modo R / O, os links para o inode são gonne enquanto o próprio inode não estiver, causando corrupção no sistema de arquivos, resultando no erro listado. Esta conclusão está correta?

Agora, estou interessado em saber como resolver o problema adequadamente. Eu suponho que evitando remontar de volta para o modo R / O e reinicializar o sistema é ok, certo? Mas existe uma solução melhor, permitindo voltar ao modo R / O e evitar a reinicialização do sistema?

Por favor, note que a solução deve ser independente do tipo de sistema de arquivos. Especificamente, eu corro em ext3 / ext4 e ubifs.

Editar: Estou procurando uma solução geral, que não exija a reinicialização de serviços individuais (por exemplo, entender o sistema). Na verdade, não é um problema reinicializar o sistema, apenas parece correto retornar o sistema ao mesmo estado em que estava antes de executar o script de atualização, ou seja, se o sistema de arquivos era R / O antes de sua execução, ele talvez fosse R / O depois disso também. Mas talvez tal premissa seja inválida.

    
por yman 14.12.2015 / 18:28

0 respostas