Serviços systemd, tarefas agendadas e logs em um VPS, pedidos em linguagem natural

Publicado em 2026-08-25 por frfrand

Cómo crear servicios systemd, programar tareas recurrentes y leer logs en un VPS pidiéndoselo a una IA. Un ejemplo de uso real para cada herramienta del MCP de ArduMaker: crear_servicio_vps, controlar_servicio_vps, ver_logs_systemd_vps, crear_tarea_vps, ver_logs_tarea_vps y el resto del área de automatización.

Escrever um unit file do systemd à mão é daquelas coisas que se faz três vezes por ano e sempre acaba procurando a sintaxe. O mesmo com os timers: ninguém lembra de cor como se expressa "todas as terças-feiras às 4 da manhã".

Com o MCP do ArduMaker, isso se descreve em uma frase e a IA monta o arquivo. Este artigo percorre as ferramentas de serviços, tarefas agendadas e logs, com um uso cotidiano para cada uma.

Ao contrário dos domínios e das portas, que são resolvidos no host pai, tudo deste guia acontece dentro do seu VPS: os serviços, os timers e os logs são da sua máquina e você os administra por completo. Como no restante da área de cloud, cada chamada leva company_id além do vps_id — ver_contexto_inicial te devolve ambos de uma.

Ferramentas cobertas: listar_servicios_vps, crear_servicio_vps, ver_servicio_vps, editar_servicio_vps, controlar_servicio_vps, eliminar_servicio_vps, ver_logs_systemd_vps, listar_tareas_vps, crear_tarea_vps, ver_tarea_vps, editar_tarea_vps, controlar_tarea_vps, eliminar_tarea_vps y ver_logs_tarea_vps.

Serviços que precisam estar sempre ativos

listar_servicios_vps — "Quais serviços estão rodando nesta máquina?" Exibe os serviços systemd configurados dentro da VPS. Uso típico: você herdou um servidor de outro provedor e precisa entender o que está rodando antes de alterar qualquer coisa.

crear_servicio_vps — "Coloque meu bot do Node como serviço, para iniciar sozinho" Cria um serviço a partir do conteúdo bruto do arquivo de unit (service_name e content), com a opção de iniciá-lo imediatamente. A IA monta o arquivo com o ExecStart, o WorkingDirectory e o Restart=always corretos. É exatamente o mesmo poder que você tem no painel: o conteúdo do arquivo de unit não é validado além do que o systemd valida, então peça para ele mostrar antes de aplicar. Uso típico: transformar um processo que hoje roda em um screen esquecido em algo que sobreviva a uma reinicialização.

ver_servicio_vps — "Mostre como ficou configurado" Retorna o arquivo de unit completo e o status ao vivo. Uso típico: verificar se a variável de ambiente que você adicionou ontem está realmente no arquivo.

editar_servicio_vps — "Adicione a variável de ambiente da chave da API" Sobrescreve o arquivo de unit: substituição completa, não um patch. Leia antes de escrever. Uso típico: mudou a porta de um aplicativo, ou é necessário adicionar um parâmetro ao comando de inicialização.

controlar_servicio_vps — "Reinicie o worker" Executa start, stop, restart, enable ou disable. Duas precisões que se confundem seguido:

• enable e disable só alteram se o serviço inicia ao bootear. Não ligam nem desligam agora. Se quiser as duas coisas, são duas chamadas.
• Aqui não há lista de serviços protegidos. Diferente da exclusão, esta ferramenta pode parar ou desabilitar serviços críticos como nginx, docker ou ssh. É o trabalho mais repetido de todos, e também o único desta seção onde uma frase mal interpretada desliga algo que importa. Peça à IA para dizer o que vai tocar antes de tocar.

eliminar_servicio_vps — "Apague o serviço antigo do projeto que encerramos" Ele para, desabilita e remove o unit file. Aqui sim há rede: um conjunto de serviços críticos está protegido —ssh, nginx, docker, mysql e companhia— e a ferramenta se recusa a apagá-los. Uso típico: limpeza ao dar baixa em um cliente.

ver_logs_systemd_vps — "Por que o worker morreu?" Lê o journalctl do serviço. Uso típico: o momento exato em que algo caiu e você precisa do erro real, não de uma suposição.

Tarefas que se repetem sozinhas

listar_tarefas_vps — "Quais tarefas agendadas existem?" Mostra os timers do systemd configurados na máquina. Uso típico: descobrir por que o servidor tem um pico de carga todos os dias no mesmo horário.

criar_tarefa_vps — "Agende um backup do banco todos os dias às 3 da manhã" Cria a tarefa com seu task_name, seu command e seu schedule, com a opção de executá-la uma vez imediatamente, além de agendá-la.

O horário usa a sintaxe OnCalendar do systemd, não cron e não "3 da manhã". Os três formatos que você vai usar:

• --* 03:00:00 — todos os dias às 3.
• Tue --* 04:00:00 — terças-feiras às 4.
• Atalhos: daily, hourly, weekly.

Na prática, não é preciso decorar: você descreve o horário em português e a IA traduz. Mas, se for revisar o que ficou configurado, é essa sintaxe que você verá.

Uso típico: backups, limpeza de arquivos temporários, sincronizações noturnas, envio de relatórios.

ver_tarefa_vps — "Quando ela roda e quando rodou pela última vez?" Detalhe completo: conteúdo do service e do timer, estado, próxima execução e última. Uso típico: confirmar que o backup de ontem à noite realmente rodou antes de mexer na produção.

editar_tarea_vps — "Pasala para as 5 da manhã, às 3 bate com outra coisa" Muda o comando, o horário, ou os dois — é necessário ao menos um. Um detalhe de implementação que vale a pena conhecer porque se nota: por dentro ele exclui a tarefa e a recria. Se estava habilitada, deixa habilitada. Mas é uma recriação, não um ajuste no local, então a próxima execução é recalculada do zero. Uso típico: reordenar a janela noturna quando dois processos pesados se sobrepõem.

controlar_tarefa_vps — "Rode o backup agora, não espere a noite" Quatro ações: start executa o comando uma vez, agora mesmo; stop interrompe essa execução; enable e disable ligam e desligam a programação automática. Não há restart aqui, diferentemente dos serviços. Uso típico: você quer um backup antes de uma migração, sem esperar o horário agendado.

eliminar_tarefa_vps — "Remova a tarefa do relatório que não enviamos mais" Exclui a tarefa. E um aviso honesto: aqui não há lista de nomes protegidos como existe para os serviços. O que você pedir para excluir, será excluído. Uso típico: limpar automações herdadas que continuam rodando sem que ninguém leia o resultado — vale a pena listar e confirmar antes.

ver_logs_tarea_vps — "O backup de ontem terminou bem?" Logs da tarefa, com duas visualizações: service (a saída do próprio comando) ou timer (o timer que a dispara). O primeiro é aquele que quase sempre queremos; o segundo serve quando a suspeita é que a tarefa nem sequer foi disparada. Uso típico: a verificação que todos deveriam fazer e quase ninguém faz, agora a uma pergunta de distância.

TÚ: El bot de Telegram se cayó otra vez durante la noche.

IA: ver_logs_systemd_vps(company_id = 3, vps_id = 7, service_name = "bot-telegram") -> "FATAL: connection refused (postgres)" a las 03:07

listar_tareas_vps(company_id = 3, vps_id = 7) -> backup-postgres, OnCalendar --* 03:00:00

"El bot murió a las 03:07 porque no pudo conectar con postgres. A las 03:00 corre el backup, que bloquea la base unos minutos. El bot no reintenta, por eso queda caído hasta la mañana."

TÚ: Que reintente solo, y movelo el backup a las 4.

IA: ver_servicio_vps(company_id = 3, vps_id = 7, service_name = "bot-telegram") -> [unit file actual]

editar_servicio_vps(company_id = 3, vps_id = 7, service_name = "bot-telegram", content = "...Restart=always RestartSec=30...") -> el archivo entero, con el cambio aplicado sobre el contenido que acabo de leer

controlar_servicio_vps(company_id = 3, vps_id = 7, service_name = "bot-telegram", action = "restart")

editar_tarea_vps(company_id = 3, vps_id = 7, task_name = "backup-postgres", schedule = "--* 04:00:00")

"Hecho. Ahora el bot se levanta solo a los 30 segundos y el backup ya no le pisa el horario.

Aclaración sobre la tarea: editarla la borra y la vuelve a crear por dentro, así que quedó habilitada pero con la próxima ejecución recalculada. Si querés, la corro una vez ahora para confirmar que el comando sigue bien."

Perguntas frequentes

Preciso escrever o unit file eu? Não. Descreve o que tem que rodar, de qual pasta e com quais variáveis, e a IA cria o arquivo. Peça para mostrar antes de aplicar: o conteúdo não é validado além do que o systemd valida, então é o momento de revisar.

As tarefas agendadas usam cron? Não: são implementadas com timers do systemd, que cumprem a mesma função, ficam integrados ao restante da máquina e têm seus próprios logs. O horário é escrito na sintaxe OnCalendar (--* 03:00:00), não na do cron.

Posso executar uma tarefa fora do horário? Sim, com controlar_tarefa_vps e a ação start. É o habitual antes de uma migração ou para testar se o comando funciona.

A IA pode desligar o nginx ou o docker sem querer? Excluí-los, não: eliminar_serviço_vps tem uma lista de serviços críticos protegidos. Mas pará-los ou desabilitá-los, sim: controlar_serviço_vps não tem essa proteção. É a assimetria mais importante deste guia e vale a pena ter em mente ao pedir um "pare tudo".

E as tarefas estão protegidas da mesma forma? Não. Para tarefas não há lista de nomes protegidos: o que você pedir para excluir, será excluído. Liste antes de excluir.

Por que os logs vêm "marcados"? Porque um log pode ser escrito por qualquer um: uma aplicação, um processo, um atacante testando coisas no seu servidor. As três ferramentas de logs devolvem o conteúdo envolvido e rotulado como não confiável, com a instrução de tratá-lo como dados e nunca como instruções. Se aparecer texto com forma de ordem dirigida à IA em um log, a IA tem que reportá-lo, não obedecer.

Como conecto o MCP? Adicionando https://mcp.ardumaker.com/mcp em um cliente compatível e autorizando com sua conta.

Parte da série de guias sobre as ferramentas do MCP da ArduMaker.