Eu queria ter uma unidade de serviço personalizada dependendo de um ponto de montagem de um sistema de arquivos remoto CVMFS. O sistema de arquivos remoto tem uma configuração estranha no systemd que eu não entendo completamente. Eu fiz uma solução alternativa simples com uma unidade de serviço intermediária, então funciona bem. Mas eu gostaria de entender como as unidades do sistema de arquivos remoto funcionam, para estar ciente desse comportamento no systemd.
Aqui está a unidade de ponto de montagem do sistema de arquivos remoto:
$ systemctl status cvmfs-sft.cern.ch.mount
* cvmfs-sft.cern.ch.mount
Loaded: loaded
Active: active (mounted) since Wed 2024-07-31 23:31:49 CEST; 1min 32s ago
Until: Wed 2024-07-31 23:31:49 CEST; 1min 32s ago
Where: /cvmfs/sft.cern.ch
What: cvmfs2
Ele não lista um arquivo de unidade . A unidade deve ter sido criada dinamicamente de alguma forma. Então, quando adiciono um Requires=cvmfs-sft.cern.ch.mountà minha unidade, ele falha durante a inicialização do Linux com isto:
localhost systemd[1]: Failed to start A one shot script ...
<hostname> systemd[1]: ....service: Failed to schedule restart job: Unit cvmfs-sft.cern.ch.mount not found.
No entanto, se eu iniciar minha unidade após o boot, ela funciona bem. Ou seja, a Requires=cvmfs-sft.cern.ch.mountdependência funciona bem quando eu entro como um usuário normal, o servidor atingiu o alvo multiusuário, o cvmfs está montado e essa unidade cvmfs-sft.cern.ch.mountestá ativa.
O que eu esperava é ter arquivos de unidade reais para os pontos de montagem do cvmfs. O sistema de arquivos remoto levaria seu tempo para montar esses pontos de montagem, e minhas unidades prosseguiriam a partir daí.
De acordo com a documentação do CVMFS , o que realmente gerencia esse sistema de arquivos é isso autofs.service. O autofsserviço executa pontos de montagem como este:
$ systemctl status autofs
* autofs.service - Automounts filesystems on demand
Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/autofs.service.d
`-50-cvmfs.conf
...
CGroup: /system.slice/autofs.service
|-3405 /usr/bin/cvmfs2 ... sft.cern.ch /cvmfs/sft.cern.ch
...
O que eu quero perguntar é o que pode criar tais unidades sem arquivos de unidade no systemd? Se eu tiver um script init.d, o systemd sempre o traduz em um arquivo de unidade real, não é? Neste caso em particular, o status da unidade diz What: cvmfs2. Isso significa que cvmfs2usar o seguinte recurso de systemd.mount?
$ man systemd.mount
...
DESCRIPTION
...
The systemd-mount(1) command allows creating .mount and .automount units
dynamically and transiently from the command line.
Acho que você precisa desse comportamento transitório para pontos de montagem, no caso em que o usuário conecta uma unidade USB no computador, etc. Mas outros tipos de unidades podem ser criados transitoriamente , ou seja, em tempo real, sem um arquivo de unidade?
Existe uma boa maneira de descobrir o que lançou uma unidade tão transitória? No meu caso, as dependências da unidade não me dizem nada:
$ sudo systemctl list-dependencies cvmfs-sft.cern.ch.mount
cvmfs-sft.cern.ch.mount
* |--.mount
* `-system.slice
$ sudo systemctl list-dependencies --reverse cvmfs-sft.cern.ch.mount
cvmfs-sft.cern.ch.mount
Existe algum outro systemctlcomando que possa lhe dizer algo mais sobre a procedência de uma unidade transitória como essa?
O próprio Systemd, tecnicamente.
Assim como o systemd gera representações de unidade .device para dispositivos que são vistos pelo libudev, ele também gera representações de unidade .mount para cada montagem real que é visível em seu /proc/self/mounts, bem como representações de unidade .swap para cada dispositivo de troca ativo.
Mas essas não são "unidades transitórias" no modo como o systemd usa esse termo. Uma unidade transitória se origina do systemd – ela é criada via API (por exemplo, chamando
systemd-mountousystemd-run) e geralmente existe como um arquivo temporário em /run/systemd – enquanto essas unidades que você vê não são isso. Elas são representações de algum estado que se origina de fora do controle do systemd; neste caso, elas representam montagens que foram feitas por programas falando diretamente com o kernel sem envolver o systemd.Portanto,
A unidade não foi lançada de forma alguma. Sua existência é o efeito, não a causa, da montagem real.
Sim, embora em todas as versões atuais, essa tradução não seja feita pelo systemd propriamente dito (ou seja, não pelo gerenciador de serviços); ela é feita por um "gerador" separado que literalmente grava arquivos .service em /run/systemd com base nos scripts init.d.
Somente versões muito antigas do systemd realmente criavam unidades virtuais .service na memória representando scripts init.d, mas isso foi removido há 10 anos. (sim, se você estiver executando o systemd v209, ele já tem dez anos!)
Não, significa que a string
cvmfs2foi especificada como o campo "source" da montagem. É o que você veria na coluna "SOURCE" demountoufindmnt.Isso significa que você provavelmente não precisa depender das montagens individuais – deve ser o suficiente para depender
autofs.servicecomo um todo. Sim, isso desvia um pouco da lógica usual do systemd, mas deve funcionar assumindo que o autofs faça o trabalho que ele deve fazer.(Não consigo pensar de improviso em uma maneira de definir uma dependência de montagem que esperaria que essa montagem aparecesse. Eu esperaria que fosse Requires+After – na verdade, você quer ter o
After=em qualquer caso – mas parece funcionar apenas para dispositivos e não para montagens.)