Respostas:
Como heemayl observou no comentário, a página de manual responde à sua pergunta. Na web:
Quer =
Uma versão mais fraca do Requer =. As unidades listadas nesta opção serão iniciadas se a unidade de configuração for. No entanto, se as unidades listadas falharem ao iniciar ou não puderem ser adicionadas à transação, isso não terá impacto na validade da transação como um todo. Esta é a maneira recomendada de conectar a inicialização de uma unidade à inicialização de outra unidade.
E Requer =:
Configura dependências de requisitos em outras unidades. Se esta unidade for ativada, as unidades listadas aqui também serão ativadas. Se uma das outras unidades for desativada ou sua ativação falhar, esta unidade será desativada. Essa opção pode ser especificada mais de uma vez ou várias unidades separadas por espaço podem ser especificadas em uma opção. Nesse caso, serão criadas dependências de requisitos para todos os nomes listados. Observe que as dependências de requisitos não influenciam a ordem na qual os serviços são iniciados ou parados. Isso deve ser configurado independentemente com as opções After = ou Before =. Se uma unidade foo.service exigir uma unidade bar.service conforme configurado com Requer = e nenhuma ordem for configurada com After = ou Before =, as duas unidades serão iniciadas simultaneamente e sem nenhum atraso entre elas se foo.service estiver ativado. Frequentemente,
Observe que esse tipo de dependência não implica que a outra unidade sempre precise estar no estado ativo quando esta estiver em execução. Especificamente: falhas nas verificações de condição (como ConditionPathExists =, ConditionPathExists =,… - veja abaixo) não fazem com que o trabalho inicial de uma unidade com uma dependência Requer = falhe. Além disso, alguns tipos de unidades podem desativar por conta própria (por exemplo, um processo de serviço pode decidir sair corretamente ou um dispositivo pode ser desconectado pelo usuário), que não é propagado para unidades com uma dependência Requer =. Use o tipo de dependência BindsTo = junto com After = para garantir que uma unidade nunca esteja no estado ativo sem uma outra unidade específica também no estado ativo (veja abaixo).
Seu serviço será iniciado apenas se o multi-user.target tiver sido atingido (não sei o que acontece se você tentar adicioná-lo a esse destino?) E o systemd tentará iniciar o display-manager.service antes do seu serviço . Se o display-manager.service falhar por qualquer motivo, seu serviço ainda será iniciado (por isso, se você realmente precisar do gerenciador de exibição, use Requires=-o). Se o multiusuário.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 (para que seja lançado na inicialização) e que ele dependa estritamente do display-manager.service via Requires=display-manager.service. Mas isso é adivinhação agora.
Nossa implantação de servidor usa LDAP contendo todos os IDs de usuário e mapas de montagem automática. Os diretórios pessoais do usuário são montados em NFS, e os usuários normalmente criam @reboot cronjobs com o código executável em seus diretórios pessoais. Também usamos sssd para cache. Desnecessário dizer que temos uma grande confiança em poder fornecer uma ordem de inicialização determinística para que essa configuração funcione. Desenvolvemos uma configuração de sistema muito sucinta e descobrimos uma nuance obscura entre as opções da seção "desejos" e "requer".
Se houver uma falha de um serviço durante a inicialização e houver outro serviço dependente de "required" nesse serviço com "restart = always" definido como uma opção de serviço, esse serviço dependente não será reiniciado. Se, no entanto, você tiver "desejos" como opção, o serviço dependente será reiniciado, conforme o esperado.
man systemd.unit