Por que um pacote de software funciona bem mesmo quando está sendo atualizado?

Digamos que eu esteja executando um software e, em seguida, corro o gerenciador de pacotes para atualizar o software, percebo que o Linux não interrompe o processo de execução da atualização do pacote - ele ainda está funcionando bem. Como o Linux faz isso?

linux files inode

— Howard
fonte

Respostas:

O motivo é que o Unix não bloqueia um arquivo executável enquanto ele é executado ou, mesmo que goste do Linux, esse bloqueio se aplica ao inode, não ao nome do arquivo. Isso significa que um processo para mantê-lo aberto está acessando os mesmos dados (antigos), mesmo depois que o arquivo foi excluído (na verdade, desvinculado) e substituído por um novo com o mesmo nome, que é essencialmente o que faz uma atualização de pacote.

Essa é uma das principais diferenças entre o Unix e o Windows. O último não pode atualizar um arquivo bloqueado, pois está faltando uma camada entre os nomes de arquivo e os inodes, o que dificulta a atualização ou a instalação de alguns pacotes, pois geralmente requer uma reinicialização completa.

— jlliagre
fonte

Para esclarecer, no Linux você não pode modificar um arquivo executável enquanto estiver em execução. Mas você pode desvincular o arquivo e substituí-lo por um novo arquivo com o mesmo nome.

— Cjm

No Linux, você pode modificar um arquivo executável enquanto estiver em execução. O resultado provavelmente seria imprevisível, a menos que você realmente saiba o que está fazendo. Adicionado o ponto "mesmo nome" que não foi declarado explicitamente.

— Jlliagre

@jlliagre A menos que eu estou mal-entendido, você não pode, tanto quanto eu estou ciente: sprunge.us/egiR

— Chris Baixo

Porém, uma coisa interessante sobre o NFTS - se você renomear a partir da linha de comando ou de outro programa, poderá colocar um arquivo com o mesmo nome lá atrás, e isso não afetará os programas que têm o arquivo original aberto. (o comando de mudança de nome no explorer não funciona para isso)

— Steffan Donal

@cjm Você está correto sobre a proteção "file text busy" no Linux, resposta atualizada. Não existe essa restrição no Solaris com a qual estou mais familiarizado. Você ainda pode modificar as bibliotecas compartilhadas com os dois sistemas operacionais.

— Jlliagre

Os executáveis geralmente são abertos uma vez, anexados a um descritor de arquivo e não possuem um descritor de arquivo para o seu binário reaberto durante um único período de execução. Por exemplo, se você executar bash, exec()geralmente criará apenas um descritor de arquivo para o inode apontado pela /bin/bashinvocação única.

Isso geralmente significa que, para binários simples que não tentam se reler durante a execução (usando o caminho pelo qual foram chamados), o conteúdo armazenado em cache permanece válido como um inode pendente. Isso significa que existe essencialmente uma réplica da versão anterior do executável.

Em casos mais complexos, isso pode causar problemas. Por exemplo, um arquivo de configuração pode ser atualizado e subsequentemente relido, ou o programa pode ser reexecutado através do caminho em que foi executado. Também pode haver problemas se os programas estiverem interconectados e um for executado antes da atualização e um depois (possivelmente pelo primeiro programa). Isso também é verdade para algumas bibliotecas.

Para casos de uso simples, porém, é seguro atualizar sem reiniciar o processo.

— Chris Down
fonte

O outro perigo, mesmo em casos simples, é que, porque o aplicativo em execução está usando uma cópia em cache do binário, até que você reinicie o aplicativo manualmente, ele ainda está executando a versão antiga do código. Embora isso não deva importar a maior parte do tempo; se a atualização incluiu correções de segurança, apesar do patch estar instalado, o sistema ainda está vulnerável porque a versão antiga ainda está em execução.

— precisa

Receio que seu primeiro parágrafo seja impreciso. Os kernels Unix / Linux não carregam programas executáveis de uma só vez, mas os mapeiam na memória. Isso significa que apenas as páginas realmente usadas acabam na RAM. Esse é o objetivo da proteção "Arquivo de texto ocupado" no Linux. Não há garantia de que parte de um executável não será lida muito tempo após o lançamento. Além disso, algumas páginas nunca serão carregadas para programas grandes o suficiente e isso é ainda mais verdadeiro para bibliotecas carregadas dinamicamente. Por exemplo, o bashbinário possui cerca de 200 páginas em 4K, não tendo certeza de que todas elas são usadas em uma sessão média.

— Jlliagre

@ jlliagre Eu estava falando sobre ialloc()uma estrutura do kernel na leitura, não o mapeamento de memória das próprias páginas. Não estou certo ao pensar que, nos modernos sistemas de arquivos ext *, o inode é eventualmente consistente no kernel (e dentro do subsistema VM)?

— Chris Baixo

Não há garantia de que partes do conteúdo executável não sejam lidas muito tempo depois de executadas e também não há garantia de que as mesmas páginas não serão lidas novamente após algum tempo durante o tempo de execução.

— Jlliagre

@ Jlliagre Certo, mas não foi isso que eu quis dizer. Talvez eu tenha picado minhas palavras um pouco na minha resposta, vou tentar esclarecer o que eu quis dizer.

— Chris Down