Início / unix / Perguntas / 416640
Accepted
goteguru
Asked: 2018-01-13 10:14:53 +0800 CST

Como desabilitar o comportamento agressivo do shell de emergência do systemd?

  • 772

Por padrão, o systemd cai para um shell de emergência ao menor erro. Por exemplo, se uma das montagens em fstab falhar por algum motivo, o sistema não inicializa imediatamente. Eu administro dezenas de diversos sistemas de produção e considero esse comportamento muito prejudicial. (Na verdade, acho que é uma grande falha de design, mas é uma opinião pessoal).

Eu gostaria de aumentar a resiliência de inicialização do sistema. Idealmente, o sistema deve sempre inicializar, drivers ausentes, montagens, etc. O que pode ser executado, deve ser executado.

Eu sei que o systemd gera automaticamente arquivos *.mount de /etc/fstab e eu poderia usar a opção nofail com um pequeno tempo limite x-systemd.device (ou definir eu mesmo os arquivos .mount relevantes). No entanto, isso não resolveria meu problema, quero tornar o sistema mais resiliente, "corrigir" o fstab toda vez não é muito conveniente e não tenho certeza de quantos outros "problemas" possíveis existem que tornariam meu sistema não inicializável apenas porque algum desenvolvedor em algum lugar pensou que é importante o suficiente.

Em suma, gostaria de recuperar o controle sobre minha máquina e não deixar o systemd decidir qual problema é sério o suficiente para interromper o processo de inicialização. É possível?

systemd boot

3 respostas

  1. Best Answer

    É literalmente apenas falhas de montagem, isso é tudo que você precisa mudar.

    Portanto, a carta do seu pedido seria trivial de responder. Crie um arquivo drop-in:

    # /etc/systemd/system/local-fs.target.d/nofail.conf

# Clear OnFailure= (set it to nothing)
[Unit]
OnFailure=

    Acredito que isso não adicionará nenhum problema novo, além daqueles que o linux sysvinit já sofreu ao permitir esse cenário de falha parcial.

    No entanto, você também apontou a questão de quanto tempo o systemd deve esperar para que os dispositivos de bloco especificados fiquem disponíveis. Não vejo como configurar isso sem fornecer uma substituição para o gerador fstab como um todo. https://www.freedesktop.org/software/systemd/man/systemd.generator.html

    Se você despejar uma grande quantidade de código menos usado aqui, parece improvável que aumente a resiliência do sistema. Acho que a solução mais próxima seria corrigir o gerador fstab existente. Não é extremamente complexo, suspeito que você possa se safar / acompanhar quaisquer mudanças significativas.

    Tecnicamente, se sua distribuição tiver um mountallscript sysvinit independente, você pode tentar conectá-lo. Mas isso mudará significativamente o processo de inicialização - na verdade, é mais uma bifurcação. Eu não recomendaria essa abordagem.

    https://unix.stackexchange.com/a/393711/29483

    Se você pesquisar nos arquivos da unidade, há apenas algumas maneiras de a inicialização voltar para emergency.target. Geralmente é quando uma .mountunidade de um sistema de arquivos local falha, causando local-fs.target falha. Ou quando seu initramfs falhar ao montar o sistema de arquivos raiz, se seu initramfs usar systemd.

    local-fs.targettem OnFailure=emergency.target. E falha porque as unidades para sistemas de arquivos locais são adicionadas automaticamente à lista Requires de local-fs.target (a menos que tenham DefaultDependencies=no).

    $ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount
    • 10

  2. Desative a montagem automática de qualquer sistema de arquivos que não seja essencial para a operação de inicialização adicionando uma noautoopção de montagem à sua /etc/fstabentrada:

    /dev/sdxy /u01 nfs defaults 0 0

    para:

    /dev/sdyx /u01 nfs noauto 0 0

    e, em seguida, monte o sistema de arquivos após a inicialização usando uma linha em /etc/rc.local:

    mount /u01

    Este exemplo usa NFS, mas também se aplica a LUNs importados de um servidor de arquivos.

    • 0

  3. Tente isso, talvez?

    systemctl mask emergency.service
systemctl mask emergency.target
    • 0

relate perguntas