Eu uso systemd-timesyncdcomo cronometrista do sistema há vários anos. Eu executo um derivado do Debian chamado raspbian para meu Raspberry Pis. Estou muito satisfeito com o cliente SNTP systemd-timesyncd, mas gostaria de experimentá-lo chronydpara uso em aplicativos fora da rede.
O seguinte comando pode ser usado para listar a configuração de systemd-timesyncd:
$ systemctl cat systemd-timesyncd
Em buster, havia uma seção de código nesta listagem que fornecia systemd-timesyncda capacidade de "desculpar-se" se encontrasse outro serviço de cronometragem (daemon NTP) instalado:
# /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService
Em algum momento após o lançamento de buster(simultâneo com o lançamento de bullseye??), o esquema acima foi alterado; o comando systemctl cat systemd-timesyncdnão contém mais referências para restringir ou inibir a inicialização systemd-timesyncdse outros cronometristas forem encontrados.
Alguém se lembra da história dessa mudança? Mais importante ainda, systemd-timesyncdainda inibe sua inicialização se encontrar outro daemon de cronometragem instalado? Onde/como isso é feito?
O
systemd-timesyncdserviço não verifica mais conflitos sozinho. Em vez disso, o conflito é resolvido tendosystemd-timesyncdem seu próprio pacote, o que entra em conflito com outros pacotes de serviço de horário : portanto, agora é impossível ter dois servidores de horário instalados (usando pacotes Debian).A forma como isso funciona, mais detalhadamente, é que o
systemd-timesyncdpacote possui umaConflicts: time-daemonentrada.time-daemoné um pacote virtual fornecido por todos os daemons de tempo , e todos eles entram em conflito com ele, de modo que apenas um único daemon de tempo pode ser instalado de uma vez (os pacotes não podem entrar em conflito entre si, portanto o aparente autoconflito não é um problema). Este é o mecanismo padrão no Debian para garantir que um único pacote de um conjunto que fornece um determinado recurso seja fornecido. A divisão do pacote é significativa porque tal conflito de pacote não poderia ser definido nosystemdpróprio pacote.Isso pode parecer mais frágil, pois não lida com servidores de horário instalados manualmente. No entanto, eles não deveriam entrar
/usr/sbinde qualquer maneira, então o esquema anterior também não os teria resolvido. Além disso, ativar e desativar automaticamente os daemons de tempo não era confiável e não parecia possível no momento consertar isso .