Systemd: Requer vs quer

Question

Existe alguma diferença entre Requer vs Quer nos arquivos de destino?

[Unit]
Description=Graphical Interface 
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service

Obrigado

    

Answer 1

Como heemayl observou no comentário, a man page responde à sua pergunta. Da web:

Wants=

A weaker version of Requires=. Units listed in this option will be started if the configuring unit is. However, if the listed units fail to start or cannot be added to the transaction, this has no impact on the validity of the transaction as a whole. This is the recommended way to hook start-up of one unit to the start-up of another unit.

e requer =:

Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated. This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created. Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.

Note that this dependency type does not imply that the other unit always has to be in active state when this unit is running. Specifically: failing condition checks (such as ConditionPathExists=, ConditionPathExists=, … — see below) do not cause the start job of a unit with a Requires= dependency on it to fail. Also, some unit types may deactivate on their own (for example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not propagated to units having a Requires= dependency. Use the BindsTo= dependency type together with After= to ensure that a unit may never be in active state without a specific other unit also in active state (see below).

Na página freedesktop.org

Seu serviço só será iniciado se o multi-user.target for atingido (não sei o que acontece se você tentar adicioná-lo a esse destino?) e o systemd tentará inicie o display-manager.service antes do seu serviço. Se display-manager.service falhar por qualquer motivo, seu serviço ainda será iniciado (portanto, se você realmente precisar do gerenciador de exibição, use Requires= para isso). Se o multi-user.target não for alcançado, seu serviço não será iniciado.

Qual é o seu serviço? É um sistema de quiosque? Intuitivamente, eu suponho que você queira adicionar seu serviço ao multi-user.target (então é iniciado na inicialização), e ele depende estritamente do display-manager.service via Requires=display-manager.service . Mas isso é apenas uma adivinhação agora.

    

Answer 2

Nossa implantação de servidor usa o LDAP contendo todos os IDs de usuários e mapas de automount. Os diretórios iniciais do usuário são montados por NFS e os usuários normalmente criam cronjobs @reboot com o código executável em seus diretórios iniciais. Nós também usamos sssd para cache. Escusado será dizer que temos uma grande confiança em ser capaz de fornecer uma ordem de inicialização determinista para esta configuração funcionar. Desenvolvemos uma configuração muito sucinta do sistema e descobrimos uma nuance obscura entre as opções de seção "quer" e "requer".

Se você tiver uma falha de um serviço durante a inicialização e houver outro serviço dependente de "requer" nesse serviço com a opção "restart = always" configurada como um serviço, esse serviço dependente não será reiniciado. Se, no entanto, você tiver "quer" como uma opção, o serviço dependente será reiniciado, como esperado.