Por que o unattended-upgrades não funciona no Debian

Por que o unattended-upgrades não faz nada numa instalação nova do Debian

No Debian, o unattended-upgrades pode estar instalado e ainda assim nunca executar uma única atualização, porque instalar o pacote e ativá-lo são etapas distintas. O pacote faz uma pergunta do debconf antes de se configurar, e a resposta padrão dele é sim. O instalador do Debian faz primeiro uma pergunta separada sobre atualizações. A resposta padrão é não ativar atualizações automáticas, e essa escolha armazena a resposta false para a pergunta do pacote, caso o pacote seja instalado mais tarde. O Ubuntu responde à mesma pergunta de outra forma. Por isso, o mesmo pacote parece funcionar no Ubuntu e parece estar com problemas no Debian.

Nada no sistema informa isso. Não há erro durante o boot, aviso no login nem ficheiro de log para consultar, porque o código que gravaria esse log nunca é chamado. Ativá-lo requer um comando. O restante deste guia aborda os quatro pontos que ainda podem impedi-lo de funcionar: de quais repositórios ele pode instalar atualizações, quando os timers do systemd são realmente executados, como identificar uma execução que falhou e se o sistema pode reiniciar automaticamente.

Imprima o que a sua máquina considera correto antes de alterar qualquer coisa

dpkg -l unattended-upgrades | tail -n 1
sudo apt install -y debconf-utils
sudo debconf-show unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

debconf-show imprime o valor armazenado de unattended-upgrades/enable_auto_updates. Um * no início dessa linha indica que algo definiu o valor, em vez de deixar o valor predefinido pelo pacote. Numa máquina instalada pelo instalador do Debian, esse algo é o instalador.

cat pode imprimir cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory. Isso, por si só, explica a ausência de atividade: sem esse ficheiro, não existem chaves periódicas e nada é agendado.

apt-config dump é o comando relevante. O APT lê os ficheiros em /etc/apt/apt.conf.d/ pela ordem dos nomes e combina-os. Por isso, um valor simples definido em 99local substitui o mesmo valor em 20auto-upgrades. Apenas nomes sem extensão ou com a extensão .conf são considerados. Assim, um ficheiro como 99local.bak é ignorado. Ler um ficheiro mostra o que esse ficheiro define. apt-config dump mostra o que o APT fará efetivamente.

Duas chaves determinam se alguma coisa acontece:

• APT::Periodic::Update-Package-Lists atualiza as listas de pacotes. Essa é a tarefa que apt update executa manualmente.
• APT::Periodic::Unattended-Upgrade executa efetivamente a atualização.

Os respetivos valores não são verdadeiro e falso. São intervalos em dias. "1" significa "executar se isto não tiver sido feito no último dia", "7" significa semanalmente e "0" significa nunca. APT::Periodic::Unattended-Upgrade "0"; é uma configuração válida que não executa nada, indefinidamente, sem apresentar qualquer erro. Se o seu resultado mostrar 0 para essa chave, ou não mostrar essa chave, encontrou o motivo.

Ative: dpkg-reconfigure ou escreva as chaves manualmente

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

A pergunta tem prioridade baixa, por isso uma instalação normal nunca a mostra. dpkg-reconfigure mostra perguntas de prioridade baixa, independentemente da prioridade do debconf configurada, portanto --priority=low apenas explicita o comportamento que já tem. A única flag a evitar é --default-priority, que desativa esse comportamento e oculta novamente a pergunta. Responda afirmativamente à caixa de diálogo. Depois, o postinst do pacote escreve /etc/apt/apt.conf.d/20auto-upgrades com base na sua resposta.

Numa máquina criada por um script, não existe nenhuma caixa de diálogo para responder. Por isso, defina primeiro a resposta:

echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean true' \
  | sudo debconf-set-selections
sudo dpkg-reconfigure -f noninteractive unattended-upgrades
apt-config dump APT::Periodic

Também pode escrever diretamente as duas chaves:

printf 'APT::Periodic::Update-Package-Lists "1";\nAPT::Periodic::Unattended-Upgrade "1";\n' \
  | sudo tee /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

Isto funciona imediatamente. O script de configuração do pacote lê novamente este ficheiro para o debconf antes de fazer a pergunta. Assim, um dpkg-reconfigure posterior ou uma reinstalação do pacote encontra o seu "1" e mantém-no. No entanto, só reconhece exatamente as linhas APT::Periodic::Unattended-Upgrade "1"; e APT::Periodic::Unattended-Upgrade "0";. Se escolher outro intervalo, como "7", o false armazenado pelo instalador continua ativo, e o postinst tenta substituir o ficheiro pela sua versão desativada. Sempre que escrever o ficheiro manualmente com algo diferente de "1", defina também a resposta do debconf.

Esta é a única diferença real em relação ao outro lado da família. Nesse caso, o instalador ativa o mesmo pacote por si, por isso a configuração do Ubuntu unattended-upgrades começa num sistema que já aplica atualizações automaticamente e dedica o seu tempo ao ajuste da configuração. Tudo o que se segue aplica-se a ambos.

Quais atualizações o Debian realmente instala?

Ativar o timer não é o mesmo que concordar em instalar tudo. Cada fonte de pacotes contém metadados da versão: uma origem, uma etiqueta, uma suite, um codename e um site. O unattended-upgrades analisa a versão candidata de cada pacote atualizável, lê os metadados da fonte de onde essa versão viria e só a instala se essa fonte corresponder a uma entrada em Unattended-Upgrade::Origins-Pattern ou na lista antiga Unattended-Upgrade::Allowed-Origins. Sem correspondência, não há atualização. Isso é intencional e ocorre sem mensagem.

Mostre os seus padrões e, em seguida, os metadados aos quais eles são comparados:

apt-config dump Unattended-Upgrade::Origins-Pattern
grep -H -E '^(Origin|Label|Suite|Codename|Components):' /var/lib/apt/lists/*Release
apt-cache policy

grep -H mantém o nome do ficheiro em cada linha, para que possa ver a que fonte pertence cada bloco de metadados. Os valores desses campos são os lados direitos dos seus padrões. Dentro de um padrão, ${distro_codename} é substituído em tempo de execução pelo codename da release em uso, para que um único ficheiro continue a funcionar durante uma atualização de release.

Leia os seus próprios padrões com esses metadados ao lado. A resposta à pergunta "estou a receber apenas correções de segurança ou também atualizações de point release" está escrita nessas duas listas e em nenhum outro lugar:

• Um padrão que mencione label=Debian-Security corresponde ao arquivo de segurança. É aí que ficam os avisos de segurança do Debian.
• Um padrão que mencione a suite -updates corresponde a stable-updates, que contém o que o Debian disponibiliza entre point releases, como dados de fusos horários.
• Um padrão que mencione a suite simples da release obtém as alterações das point releases assim que são publicadas, o que significa mais alterações e mais trabalho de testes da sua parte.
• Um repositório que adicionou manualmente não corresponde a nada até escrever um padrão para ele.

Esse último ponto surpreende muitas pessoas. Um repositório de terceiros tem a sua própria origem e a sua própria etiqueta. Por isso, o unattended-upgrades vê a versão candidata, verifica que a fonte não corresponde a nada e passa à frente. Adicionar um padrão para esse repositório é uma decisão que deve ser tomada com cuidado, porque um repositório de fornecedor pode disponibilizar uma nova versão principal dentro da mesma suite. Nesse caso, aceitou atualizações automáticas de versões principais desse software durante a noite.

O unattended-upgrades também nunca o move entre releases do Debian. Ele atualiza pacotes dentro da release em uso. Passar de uma stable para a seguinte continua a ser uma tarefa manual que deve agendar. Se ainda está no Debian 11, essa tarefa está atrasada: o bullseye perdeu o suporte de segurança LTS em 31 August 2026. Por isso, o unattended-upgrades pode continuar a ser executado corretamente todas as noites sem haver nada novo para instalar, e atualizar um servidor Debian 11 para o Debian 13 exige dois saltos cuidadosos.

Ao alterar a lista, lembre-se de que as listas do APT são acrescentadas. Um segundo bloco Origins-Pattern noutro ficheiro é adicionado à lista fornecida pelo pacote, em vez de a substituir. Limpe-a primeiro se a sua intenção for substituí-la:

#clear Unattended-Upgrade::Origins-Pattern;
Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=${distro_codename},label=Debian-Security";
  "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

Coloque as alterações locais num ficheiro novo que fique depois do ficheiro fornecido pelo pacote na ordenação, por exemplo /etc/apt/apt.conf.d/52unattended-upgrades-local. 50unattended-upgrades é um ficheiro de configuração gerido pelo pacote. Depois de o editar, qualquer atualização posterior do pacote que forneça uma versão alterada desse ficheiro para e pergunta o que deve fazer com a sua versão. Um ficheiro separado nunca entra em conflito.

Há mais duas chaves que vale a pena mostrar enquanto está a verificar isto. Unattended-Upgrade::Allowed-Origins é a forma antiga da mesma ideia, escrita como pares origin:archive, e continua a ser lida. Por isso, uma configuração copiada de um tutorial acaba frequentemente com as duas listas e sem uma resposta clara sobre qual delas correspondeu. Unattended-Upgrade::Package-Blacklist contém expressões regulares comparadas com os nomes dos pacotes, e uma expressão demasiado abrangente bloqueia muito mais do que pretendia. A execução de teste abaixo mostra o que foi efetivamente aplicado.

Por que nada foi executado no horário esperado?

Dois timers do systemd controlam este processo, e eles têm funções diferentes. apt-daily.timer inicia apt-daily.service, que atualiza as listas de pacotes e faz os downloads. apt-daily-upgrade.timer inicia apt-daily-upgrade.service, que é o responsável por chamar unattended-upgrade. Ambos executam /usr/lib/apt/apt.systemd.daily com argumentos diferentes. Se o segundo timer estiver desativado ou mascarado, ambas as chaves periódicas podem mostrar 1 e, ainda assim, nada será instalado.

systemctl list-timers 'apt-daily*' --all
systemctl is-enabled apt-daily.timer apt-daily-upgrade.timer
systemctl cat apt-daily-upgrade.timer

list-timers fornece NEXT, LEFT, LAST e PASSED para cada unidade. Um timer sem NEXT não será executado. Se is-enabled mostrar masked, alguém o desativou à força, e nada que você escrever em apt.conf.d vai alterar isso.

Agora leia a seção [Timer] que systemctl cat mostrou. OnCalendar é o momento mais cedo em que o timer pode ser executado. RandomizedDelaySec adiciona uma espera aleatória depois desse momento, para que um conjunto de máquinas Debian não acesse os mesmos mirrors no mesmo segundo. É por isso que a coluna NEXT mostra um horário diferente de OnCalendar, e por que a execução de ontem ocorreu em outro minuto. Isso está funcionando conforme projetado. Persistent=true significa que uma máquina desligada no horário agendado executa o job pouco depois do próximo boot, em vez de ignorar o dia.

Para alterar a janela, faça um override da unidade em vez de editá-la:

sudo systemctl edit apt-daily-upgrade.timer

[Timer]
OnCalendar=
OnCalendar=03:30
RandomizedDelaySec=30m

A linha OnCalendar= vazia é obrigatória, porque as configurações de unidade que aceitam listas são acumuladas: se você a omitir, manterá o agendamento fornecido pelo pacote e adicionará um segundo. systemctl edit recarrega o systemd, portanto confirme o resultado com systemctl list-timers 'apt-daily*' e veja o novo NEXT.

Você não precisa esperar um timer para testar nada disso:

sudo systemctl start apt-daily-upgrade.service
journalctl -u apt-daily-upgrade.service --since -1h

Uma coisa confunde quem procura em /etc/cron.daily: o APT ainda fornece /etc/cron.daily/apt-compat para sistemas sem systemd. Leia-o com cat. Em um sistema com systemd, ele termina logo no início, portanto o trabalho não é executado duas vezes.

Demonstre que funciona: unattended-upgrade --dry-run --debug

sudo unattended-upgrade --dry-run --debug

O comando está no singular e o nome do pacote está no plural. O Debian 12 e 13 também fornecem um /usr/bin/unattended-upgrades, por isso o plural já não termina em command not found nessas versões. No entanto, o comando documentado, e o utilizado ao longo deste guia, é o singular unattended-upgrade.

Este comando responde a quase todas as perguntas do tipo "por que razão esse pacote foi ignorado?", porque apresenta o próprio raciocínio. Perto do início, apresenta as origens que calculou a partir dos seus padrões:

Allowed origins are: ...

Em seguida, apresenta uma linha por pacote candidato, com o registo de origem da versão que instalaria:

Checking: curl ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian' site:'deb.debian.org' isTrusted:True>])

Depois, apresenta a lista de pacotes sobre os quais atuaria ou, num sistema sem nada para fazer:

No packages found that can be upgraded unattended and no pending auto-removals

Junte a primeira e a segunda partes para obter um diagnóstico direto. Procure a linha Checking: correspondente ao pacote que esperava ver atualizado. Compare campo a campo o respetivo registo de origem com as origens permitidas apresentadas acima. Um campo que não corresponda, mais frequentemente label ou archive, é a razão completa pela qual o pacote foi ignorado.

--dry-run marca os pacotes em memória e não instala nada, por isso pode executá-lo quantas vezes quiser. Mesmo assim, acrescenta entradas a /var/log/unattended-upgrades/unattended-upgrades.log.

Se as origens corresponderem e um pacote continuar retido, verifique estes pontos:

• apt-mark showhold apresenta os pacotes fixados por si ou por uma ferramenta. unattended-upgrades não move um pacote retido.
• A atualização teria de remover ou adicionar outro pacote. unattended-upgrades evita essa operação, a menos que as chaves relevantes a permitam. Compare com sudo apt-get -s upgrade, que apresenta a mesma decisão sem essas regras de segurança.
• O dpkg ficou parcialmente configurado depois de uma execução interrompida. Corrija-o com sudo dpkg --configure -a e volte a verificar.
• /var não tem espaço livre, por isso nada é descarregado nem desempacotado. Verifique com df -h /var.
• /boot está cheio de kernels antigos, o que impede a próxima atualização do kernel. Verifique df -h /boot e execute apt-config dump Unattended-Upgrade::Remove-Unused-Kernel-Packages para saber se a limpeza está ativada.

Se executar apt manualmente enquanto o temporizador estiver em execução, verá Could not get lock /var/lib/dpkg/lock-frontend. Essa mensagem significa que o unattended-upgrades está a funcionar corretamente. Aguarde até terminar.

Como descobrir quando uma execução falha?

Comece pelos logs, porque eles existem independentemente de qualquer outra configuração:

sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
journalctl -u apt-daily-upgrade.service --since -7d

O primeiro ficheiro é o log de decisões: o que foi verificado, o que foi escolhido e o que foi instalado. O segundo contém a saída bruta do dpkg. É aí que aparece um pacote cujo script postinst falhou. Surge um log de encerramento separado se as atualizações forem executadas enquanto a máquina está a desligar-se.

O e-mail é o método habitual de notificação:

Unattended-Upgrade::Mail "you@example.com";
Unattended-Upgrade::MailReport "on-change";

MailReport aceita always, on-change e only-on-error. only-on-error parece ser a opção mais disciplinada e normalmente é a escolha errada num servidor em que ninguém inicia sessão, porque uma máquina que deixou de fazer atualizações também deixa de enviar erros. O silêncio passa então a ocultar igualmente um servidor saudável e um servidor parado. on-change envia um e-mail sempre que algo é instalado, por isso a mensagem também comprova que o temporizador continua ativo.

O e-mail só sai da máquina se a máquina conseguir enviar e-mail. unattended-upgrades entrega a mensagem ao sistema de e-mail local, por isso é necessário um MTA (mail transfer agent), como postfix, ou um cliente de relay compatível com sendmail, como msmtp. Verifique com command -v sendmail e command -v mail. Sem nenhum dos dois, o relatório não chega a lado nenhum, a atualização continua a ser concluída e toda a falha fica invisível. Tenha também em conta que o endereço IP novo de um VPS não tem reputação de envio. Por isso, as mensagens enviadas diretamente para uma caixa de correio pública são frequentemente classificadas como spam. Fazer relay através de um fornecedor de e-mail que já utiliza é mais fiável do que executar o seu próprio servidor para este fim.

Se preferir não executar nenhum serviço de e-mail, monitorize o timestamp do log através do sistema de monitorização que utiliza:

stat -c '%y %n' /var/log/unattended-upgrades/unattended-upgrades.log

Se o timestamp não mudar durante uma semana, o temporizador parou, independentemente do que a configuração indicar. Esta verificação deve fazer parte das restantes verificações de rotina da manutenção do seu servidor Linux.

O servidor deve reiniciar sozinho?

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Com Automatic-Reboot definido como true, o unattended-upgrades reinicia o servidor sem confirmação, mas somente quando o ficheiro /var/run/reboot-required existe depois de a execução terminar. No Debian 12 e 13, o pacote unattended-upgrades cria esse marcador através de um hook do kernel, /etc/kernel/postinst.d/unattended-upgrades, que é executado quando um pacote do kernel é instalado. Uma atualização de biblioteca não o cria. Não assuma que o ficheiro existe. Verifique depois da próxima atualização do kernel:

ls -l /var/run/reboot-required /var/run/reboot-required.pkgs
uname -r
dpkg -l 'linux-image-*' | grep '^ii'

Se esse ficheiro nunca aparecer na sua máquina, Automatic-Reboot "true" nunca é acionado. Pode passar meses a acreditar que o servidor reinicia para aplicar atualizações do kernel, enquanto continua a executar o kernel antigo. uname -r ao pacote linux-image instalado mais recentemente esclarece a situação.

Automatic-Reboot-Time agenda o reinício para essa hora, em vez de o executar imediatamente. Com Automatic-Reboot-WithUsers definido como false, o reinício é ignorado enquanto houver alguém ligado. Num servidor que tem sempre uma sessão aberta, isso significa que nunca reinicia.

A decisão diz respeito ao que acontece durante o arranque seguinte, não ao reinício em si. Um serviço iniciado manualmente por alguém não volta a iniciar. Um volume encriptado que exige uma frase-passe durante o arranque não é montado. Duas máquinas que dependem uma da outra podem arrancar pela ordem errada. Ative o reinício automático num servidor web sem estado que possa ficar indisponível durante um minuto às 02:00. Mantenha-o desativado quando for necessária a intervenção de uma pessoa e configure alertas para o ficheiro marcador, para que alguém escolha o momento. Entre estas opções está needrestart, que reinicia os serviços que continuam a utilizar uma biblioteca atualizada e, por isso, abrange tudo exceto o kernel. O modo predefinido pede confirmação antes de reiniciar. Leia /etc/needrestart/needrestart.conf antes de depender dele numa execução sem supervisão.

Isto funciona da mesma forma no testing e no unstable?

Tudo o que foi descrito acima aplica-se ao Debian stable, onde as correções de segurança chegam de um arquivo separado com uma etiqueta própria. É essa estrutura que permite expressar uma definição como "apenas atualizações de segurança". As outras suites são construídas de forma diferente, por isso uma configuração copiada de um servidor stable corresponde menos ao que o autor espera, e as atualizações automáticas numa suite em evolução implicam mudanças automáticas de versão principal. Isso é algo diferente que precisa de ser aceite. Se estiver a avaliar essa opção, executar Debian stable, testing ou unstable num servidor explica o que cada uma oferece. No lado do Red Hat, a mesma tarefa usa outra ferramenta e outra terminologia, e dnf-automatic no Rocky Linux e AlmaLinux executa-a com o seu próprio temporizador e ficheiro de configuração.

As atualizações automáticas reduzem o intervalo entre a publicação de uma correção e a sua instalação. Não indicam o que continua exposto, por isso combine-as com uma verificação de CVEs conhecidos no seu servidor. CVE significa common vulnerabilities and exposures e é o identificador público usado para acompanhar uma correção.

A verificação de cinco minutos

1. apt-config dump APT::Periodic mostra ambas as chaves com um valor diferente de zero.
2. systemctl list-timers 'apt-daily*' mostra um tempo NEXT para ambos os temporizadores.
3. sudo unattended-upgrade --dry-run --debug mostra origens permitidas que incluem o arquivo de segurança correspondente ao seu codename.
4. sudo systemctl start apt-daily-upgrade.service termina, e o timestamp de /var/log/unattended-upgrades/unattended-upgrades.log é atualizado.
5. Uma semana depois, esse mesmo log lista os pacotes que instalou.

Passar nas quatro primeiras verificações significa que a máquina está configurada. Passar na quinta significa que funciona.

FAQ

Por que o Debian instala o unattended-upgrades, mas deixa-o desativado?

O pacote faz uma pergunta ao debconf, unattended-upgrades/enable_auto_updates, e grava /etc/apt/apt.conf.d/20auto-upgrades com base na resposta. O valor padrão definido pelo próprio pacote para essa pergunta é true. No entanto, a pergunta do instalador do Debian sobre atualizações usa por padrão a opção de não instalar atualizações automaticamente, e essa escolha grava false na pergunta do pacote. Assim, quando o pacote é instalado mais tarde como parte de uma tarefa ou como dependência, fica configurado para não fazer nada. Execute sudo debconf-show unattended-upgrades para ver a resposta armazenada e depois sudo dpkg-reconfigure --priority=low unattended-upgrades para alterá-la. A pergunta tem prioridade baixa, por isso uma instalação normal nunca a mostra. Já dpkg-reconfigure mostra perguntas de baixa prioridade por padrão, portanto ela aparece aqui mesmo sem a flag.

Como testo o unattended-upgrades sem esperar pelo timer?

Execute sudo unattended-upgrade --dry-run --debug. O comando mostra as origens que serão aceites, uma linha Checking: por pacote atualizável, com o registo de origem desse pacote anexado, e a lista de pacotes que instalaria, sem instalar nada. Para testar o fluxo real, execute sudo systemctl start apt-daily-upgrade.service e depois consulte journalctl -u apt-daily-upgrade.service --since -1h juntamente com /var/log/unattended-upgrades/unattended-upgrades.log.

O unattended-upgrades instala atualizações normais além das correções de segurança?

Somente quando um padrão determina isso. Uma atualização de pacote é instalada quando a origem de onde ele vem corresponde a uma entrada em Unattended-Upgrade::Origins-Pattern ou no antigo Unattended-Upgrade::Allowed-Origins. O arquivo de segurança, a suite stable-updates e qualquer repositório adicionado por si são entradas separadas. Execute apt-config dump Unattended-Upgrade::Origins-Pattern e apt-config dump Unattended-Upgrade::Allowed-Origins na sua própria máquina e compare os resultados com grep -H -E '^(Origin|Label|Suite|Codename):' /var/lib/apt/lists/*Release. O comando também nunca muda a máquina entre releases do Debian.

Por que a atualização não é executada no horário definido no timer?

apt-daily-upgrade.timer define RandomizedDelaySec sobre OnCalendar, por isso o systemd escolhe um momento aleatório dentro dessa janela em vez de ser executado no horário do calendário. Isso distribui a carga por todas as máquinas Debian que apontam para os mesmos mirrors. systemctl list-timers 'apt-daily*' mostra o momento escolhido. Para alterar a janela, execute sudo systemctl edit apt-daily-upgrade.timer e forneça uma linha OnCalendar= vazia seguida do seu próprio valor.

Devo ativar o reboot automático para atualizações de segurança?

Somente quando for seguro reiniciar sem planeamento. Unattended-Upgrade::Automatic-Reboot "true" reinicia sem confirmação sempre que /var/run/reboot-required existir depois de uma execução. No Debian 12 e 13, esse marcador é criado por um hook do kernel fornecido pelo pacote unattended-upgrades. Por isso, aparece depois de atualizações do kernel, mas não depois de atualizações de bibliotecas. Confirme que o ficheiro aparece na sua máquina depois de uma atualização do kernel antes de confiar nessa configuração. Numa máquina que precise de uma passphrase durante o boot ou que execute serviços iniciados manualmente por alguém, mantenha essa opção como false e monitorize o ficheiro marcador para que uma pessoa escolha o momento do reboot.