This post is also available in:
English (Inglês)
Durante a execução do runcluvfy.sh (Cluster Verification Utility) antes da instalação do Oracle Grid Infrastructure, é comum encontrar o seguinte erro:
Verifying Network Time Protocol (NTP) ...FAILED
PRVG-01017 : NTP configuration file "/etc/ntp.conf" is present on
nodes "node1,node2" on which NTP daemon or service
was not runningÀ primeira vista, a correção parece óbvia: o arquivo existe mas o serviço não está rodando. Mas a causa real costuma ser outra — e renomear o arquivo sem entender o contexto pode criar problemas piores do que o warning original.
Neste artigo, vou explicar por que esse erro ocorre, qual a relação entre NTP e Chrony, e como resolver de forma correta e segura.
💡 Na prática: Na maioria dos casos em RHEL/OL 7+, esse erro aparece porque o sistema usa Chrony para sincronização de tempo, mas o arquivo
/etc/ntp.confficou como resíduo de uma configuração anterior. O CVU encontra o arquivo e espera que o serviçontpdesteja ativo — como não está, reporta o erro.
Por Que o Erro PRVG-01017 Ocorre
O Cluster Verification Utility (CVU) executa uma série de validações antes da instalação do Grid Infrastructure. Uma delas é verificar a sincronização de tempo entre os nós do cluster.
A lógica do CVU é:
- Verificar se o arquivo
/etc/ntp.confexiste - Se existir, verificar se o serviço
ntpdestá rodando - Se o arquivo existe mas o serviço não está ativo, reportar PRVG-01017
O problema é que em distribuições Linux modernas (RHEL 7+, OL 7+, CentOS 7+), o serviço padrão de sincronização de tempo mudou de NTP (ntpd) para Chrony (chronyd). O Chrony usa seu próprio arquivo de configuração (/etc/chrony.conf), mas o arquivo /etc/ntp.conf pode ter ficado no sistema por resíduo de uma instalação anterior ou de um upgrade de SO.
Por Que a Sincronização de Tempo é Crítica em RAC
O Oracle Clusterware depende de sincronização precisa entre os nós. Um clock skew (diferença de relógio) entre nós pode causar:
- Falhas no CSS (Cluster Synchronization Services)
- Node evictions — nós sendo removidos do cluster
- Problemas de consistência de dados em transações distribuídas
- Erros intermitentes difíceis de diagnosticar
Por isso, o CVU valida o time sync obrigatoriamente — e por isso é importante resolver a causa raiz, não apenas silenciar o warning.
Diagnóstico — NTP ou Chrony?
Antes de corrigir, identifique qual serviço de time sync está ativo no seu ambiente.
Verificar se o Chrony está ativo
systemctl status chronydSe retornar active (running), o Chrony é o serviço de time sync do seu ambiente.
Para confirmar que está sincronizando corretamente:
chronyc trackingSaída esperada (exemplo):
Reference ID : A1B2C3D4 (ntp-server.example.com)
Stratum : 3
Ref time (UTC) : Thu Feb 27 10:30:00 2026
System time : 0.000012345 seconds fast of NTP time
Last offset : +0.000003456 secondsSe o Stratum estiver entre 1-15 e o System time estiver na faixa de milissegundos, o time sync está funcionando.
Verificar se o NTP está ativo
systemctl status ntpdSe retornar inactive (dead) ou not found, o ntpd não está em uso.
Verificar se o arquivo /etc/ntp.conf existe
ls -la /etc/ntp.confSe o Chrony está ativo, o NTP está inativo, e o /etc/ntp.conf existe — essa é a causa do PRVG-01017.
Soluções
Solução 1: Remover o /etc/ntp.conf residual (quando usando Chrony)
Esta é a solução mais comum. Se o Chrony está ativo e funcionando, o /etc/ntp.conf é um arquivo residual que pode ser removido com segurança.
Passo 1 — Confirme que o Chrony está ativo em TODOS os nós:
# Executar em cada nó
systemctl status chronyd | grep ActiveResultado esperado: Active: active (running)
Passo 2 — Renomeie o arquivo em TODOS os nós (não delete, faça backup):
# Node 1
mv /etc/ntp.conf /etc/ntp.conf.bkp
# Node 2
mv /etc/ntp.conf /etc/ntp.conf.bkpImportante: Renomeie em vez de deletar. Se algo der errado, você pode restaurar o arquivo original rapidamente.
Passo 3 — Valide executando o CVU novamente:
./runcluvfy.sh stage -pre crsinst -n node1,node2 -verbose | grep -i ntpResultado esperado:
Verifying Network Time Protocol (NTP) ...PASSEDSolução 2: Configurar e iniciar o NTP (quando NÃO usando Chrony)
Se o seu ambiente não usa Chrony e você precisa do NTP, a solução é configurar e iniciar o serviço ntpd.
Passo 1 — Instalar o NTP (se necessário):
yum install ntp -yPasso 2 — Configurar o /etc/ntp.conf:
# Verificar se o servidor NTP está configurado
cat /etc/ntp.conf | grep -i serverSe não houver servidores configurados, adicione:
# Exemplo com servidores NTP públicos
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburstEm ambientes corporativos: Use os servidores NTP internos da sua organização, não os públicos.
Passo 3 — Desativar o Chrony (se estiver instalado) e ativar o NTP:
# Desativar Chrony
systemctl stop chronyd
systemctl disable chronyd
# Ativar NTP
systemctl enable ntpd
systemctl start ntpdPasso 4 — Verificar sincronização:
ntpq -pPasso 5 — Validar com o CVU:
./runcluvfy.sh stage -pre crsinst -n node1,node2 -verbose | grep -i ntpSolução 3: Usar CTSS (Oracle Cluster Time Synchronization Service)
Se você não quer usar NTP nem Chrony, o Oracle oferece o CTSS — um serviço próprio de sincronização de tempo que faz parte do Grid Infrastructure.
Para que o CTSS funcione:
- Remova ou renomeie o
/etc/ntp.confem todos os nós - Desative tanto o
ntpdquanto ochronyd - O Grid Infrastructure detectará a ausência de time sync externo e ativará o CTSS automaticamente durante a instalação
Para verificar se o CTSS está ativo após a instalação:
crsctl check ctssNota: A Oracle recomenda o uso de NTP ou Chrony para produção. O CTSS é uma alternativa, mas depende do clusterware estar funcional.
Checklist Rápido de Diagnóstico
# 1. Qual serviço de time sync está ativo?
systemctl status chronyd
systemctl status ntpd
# 2. O /etc/ntp.conf existe?
ls -la /etc/ntp.conf
# 3. O Chrony está sincronizando corretamente?
chronyc tracking
# 4. Validar com o CVU
./runcluvfy.sh stage -pre crsinst -n node1,node2 -verbose | grep -i ntpConclusão
O erro PRVG-01017 é um warning comum durante a validação pré-instalação do Oracle RAC. Na grande maioria dos casos, a causa é um arquivo /etc/ntp.conf residual em ambientes que migraram para o Chrony.
A correção é simples, mas o ponto crítico é: nunca remova o arquivo sem antes confirmar que algum serviço de time sync está ativo. Clock skew em RAC causa problemas sérios e difíceis de diagnosticar.
O diagnóstico correto segue esta ordem:
- Identificar qual serviço está ativo (Chrony, NTP ou nenhum)
- Garantir que o time sync está funcionando
- Remover o arquivo residual (se aplicável)
- Validar com o
runcluvfy.sh
Referências: