Como remontar uma unidade de montagem do Systemd com opções diferentes?

Question

Eu desejo expressar a seguinte sequência de comandos em termos de Unidades de montagem do Systemd e invocações do systemctl:

# mount /some/path /some/mountpoint -o ro
# mount /some/mountpoint -o remount,rw
# touch /some/mountpoint/foo # placeholder for write action
# mount /some/mountpoint -o remount,ro

O problema conceitual parece ser aquele systemd.mount (5) opera em pontos de montagem. Como as unidades são ativadas passando o caminho completo em systemctl, não se pode ter várias unidades de montagem para o mesmo ponto de montagem. Modelos não funcionam para unidades de montagem qualquer um.

Então, como isso funciona? É possível em tudo?

    

Answer 1

Use uma unidade de serviço em vez de uma unidade de montagem

Uma simples unidade de serviço com o comando mount funcionou para o meu caso de uso de remontagem (e presumo que funcionará para o seu).

Dado que as montagens geralmente já estão definidas em /etc/fstab e o systemd gerou automaticamente um <mountpoint>.mount para entradas fstab, existem duas abordagens:

1. Basta recorrer a uma unidade de serviço padrão em vez de uma unidade de montagem e controlar diretamente o comando de montagem.
2. Tente usar uma substituição do systemd? (Não testado, não ache que é viável)
   • As unidades de montagem têm um requisito estrito de que a unidade seja nomeada de acordo com o ponto de montagem, portanto, provavelmente não é possível executar duas unidades de montagem separadas para o mesmo ponto de montagem (já mencionado na pergunta).
   • Assim, isso provavelmente não funcionará para as remessas, presumindo que ele apenas substitua a definição original da unidade de montagem gerada a partir do fstab e não seja executado duas vezes.
   • Se você tentou, é mais provável que a montagem original falhe, considerando a opção de remontagem aplicada a algo ainda não montado.

Exemplo

Eu precisava de algo semelhante e esbarrei no seguinte problema ao tentar usar o tipo de unidade de montagem systemd (porque não defini o nome do arquivo da minha unidade de acordo com o ponto de montagem):

Where= setting doesn't match unit name. Refusing.

Dada uma montagem de ligação a um diretório de dados com mais espaço, mas com o ponto de montagem pai tendo nosuid e nodev definidos, eu precisava adicionar privilégios suid e dev para lxc em / var / lib / lxc.

O arquivo da unidade de serviço /etc/systemd/system/lxc-remount.service :

[Unit]
Description=Remount the /var/lib/lxc folder with suid and dev privileges
Requires=var-lib-lxc.mount
After=var-lib-lxc.mount
Before=lxc.service

[Service]
Type=oneshot
ExecStart=/bin/mount -o remount,rw,suid,dev,relatime,discard,data=ordered /var/lib/lxc

[Install]
WantedBy=lxc.service

Comandos para colocar em prática:

$ sudo systemctl daemon-reload
$ sudo systemctl enable lxc-remount.service
Created symlink from /etc/systemd/system/lxc.service.wants/lxc-remount.service to /etc/systemd/system/lxc-remount.service.
$ sudo systemctl start lxc-remount.service

    

Answer 2

É tecnicamente possível implementar isso em cima de systemd mount units. Portanto, não posso simplesmente responder "não". Há algumas desvantagens dessa abordagem.

Por outro lado, você pode atender a todos os requisitos, exceto "use systemd mount units", fazendo a parte de remontar usando o comando mount . Note que systemd é geralmente muito feliz que as pessoas usem o comando mount . Por exemplo, se você desmontar temporariamente um sistema de arquivos com umount , a unidade de montagem systemd será marcada como inactive . E quando você usa mount para montar um sistema de arquivos manualmente, o systemd cria uma unidade de montagem transitória para ele. (Note que não cria uma unidade arquivo ).

Portanto, na prática eu recomendaria usar o comando mount para realizar as operações de remontagem.

Se você estiver lendo esta pergunta e tiver um motivo adicional para não usar o comando mount , faça uma nova pergunta com o motivo específico. Sem conhecer esse motivo, não posso recomendar realmente usar o método abaixo. É apresentado apenas para fins educacionais.

Você precisa alterar a configuração Options= da unidade de montagem e, em seguida, systemctl reload da unidade de montagem.

Você pode fazer isso usando um arquivo drop-in que tenha apenas essa opção, abaixo de /run/systemd/system/ . Então você não precisa editar a configuração no disco. Se o sistema travar parcialmente, não há risco de deixar uma configuração obsoleta.

Não é muito "limpo", no entanto. Ainda corre o risco de seus comandos serem interrompidos a meio, e você pode deixar uma configuração obsoleta em dois lugares - o estado da montagem no kernel, e o estado do monte em systemd. O primeiro problema existiria de qualquer maneira ao usar mount . Mas isso significa que você poderia consertar o primeiro problema e esquecer o segundo problema. Então o segundo problema poderia causar muita confusão mais tarde.

Observe que, quando você cria um arquivo drop-in ou edita o arquivo da unidade, também precisa executar systemctl daemon-reload para selecionar o novo valor Option= antes de recarregar a unidade de montagem.

Este é o segundo problema - eu realmente não recomendaria usar isso, pelo menos por enquanto. systemctl daemon-reload é uma operação meio pesada :-). Também pode ter efeitos colaterais indesejados se você tiver azar. Algum código foi adicionado em algum momento, para trabalhar no sentido de recarregar um arquivo de unidade individual, mas ainda não vejo isso documentado como um recurso utilizável.

(Eu também notei que um dos diretórios de unidades especiais /run/systemd/system.control/ é descrito como "configuração transitória criada usando a dbus API". Acredito que isso seja usado para acompanhar as mudanças nas configurações de controle de recursos e algumas outras). estes são casos especiais, que podem ser alterados usando systemctl --runtime set-property . Suponho que eles não exigem uma recarga completa).