Início / unix / Perguntas / 507702
Accepted
TheMeaningfulEngineer
Asked: 2019-03-22 04:39:18 +0800 CST

"antes" e "quer" para o mesmo serviço systemd?

  • 772

Neste exemplo de um arquivo de unidade systemd:

# systemd-timesyncd.service
...

Before=time-sync.target sysinit.target shutdown.target
Conflicts=shutdown.target
Wants=time-sync.target

systemd-timesyncd.servicedeve começar antes time-sync.target . Isso define uma dependência de ordenação .

Mas ao mesmo systemd-timesyncd.service tempo quer time-sync.target . Assim time-sync.targeté a dependência de requisitos

Qual é o caso de uso para essa relação e por que eles não estão em conflito entre si?

systemd dependencies

3 respostas

  1. Best Answer

    O caso de uso dessa relação dupla é semelhante a uma relação “fornece”. systemd-timesyncdfornece um serviço de sincronização de tempo, portanto, satisfaz qualquer dependência que uma unidade tenha do time-sync.target. Deve começar antes time-sync.targetporque é necessário para qualquer serviço que dependa de sincronização de tempo, e quer time-sync.targetporque qualquer unidade que dependa de sincronização de tempo deve ser iniciada junto com o systemd-timesyncdserviço.

    Acho que o mal-entendido vem da sua interpretação de “quer”. A relação “quer” no systemd não é uma dependência: systemd-timesyncdnão precisa time-syncfuncionar. É uma relação “começar junto com”: diz que a unidade de configuração ( systemd-timesyncd.service) quer que as unidades listadas ( time-sync.target) comecem junto com ela.

    Consulte também Qual serviço fornece time-sync.target no systemd?

    • 16

  2. O objetivo desse mecanismo é garantir que os relacionamentos de ordenação possam ser feitos, mas não entrem em vigor a menos que seja necessário.

    time-sync.targeté um marco de pedidos. Todos os serviços que fornecem "sincronização de tempo" especificam que são Beforeo time-sync.target, para que o destino só fique pronto quando a "sincronização de tempo" estiver em vigor. Todos os serviços que precisam de "sincronização de tempo" para entrar em vigor quando executados especificam que são Afteros arquivos time-sync.target.

    Se este também tivesse Wantsrelação com aquele alvo, então acabaria sempre por ser ordenado por ele, pois sempre estaria incluído no conjunto de coisas que se ordenam.

    Isso é visto como subótimo no caso em que não há de fato nenhum serviço de "sincronização de tempo" concreto; e o pensamento das pessoas do sistema é que tal ordenação não deveria estar em vigor em tal caso. Em vez disso, os serviços devem ser solicitados como se time-sync.targetnão existissem, permitindo que alguns deles sejam iniciados muito mais cedo, se essa for sua posição "natural" sem o marco.

    A solução é time-sync.targetrealmente não estar lá. Ele não é desejado pelos serviços que esperam iniciar depois que a sincronização de horário estiver disponível. Portanto, não existe no conjunto de coisas ordenadas se apenas esses serviços forem iniciados. Ele só é trazido para o conjunto se um serviço real de "sincronização de tempo" for iniciado, com isso (em vez dos serviços do cliente) tendo o Wantsrelacionamento que o traz.

    Os alvos não precisam necessariamente ser coleções de serviços. Eles também podem ser marcos de pedidos.

    Há um bom número desses marcos puros, no systemd e em outros lugares. O name-servicesdestino na coleção de pacotes de serviços do conjunto de ferramentas nosh é um marco de pedido puro semelhante.

    Leitura adicional

    • Jonathan de Boyne Pollard (2018). system-control. Guia de no . Programas.
    • 6

  3. time-sync.targeté uma espécie de sinalizador no sistema, para que os serviços que dependem de um horário correto não precisem depender de systemd-timesyncd, ntpd, o que for.

    A Beforeentrada diz ao systemd para iniciar systemd-timesyncd, então time-sync.target (isso é apenas para ordenação). O Wantsdiz para realmente definir o sinalizador.

    • 1

relate perguntas