systemd services, scheduled tasks and logs on a VPS, requested in natural language

Published on 2026-08-25 by 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.

Writing a systemd unit file by hand is one of those things you do three times a year and always end up looking up the syntax. The same goes for timers: nobody remembers off the top of their head how to express "every Tuesday at 4 AM".

With ArduMaker's MCP, that is described in a single sentence and the AI creates the file. This article covers services, scheduled tasks, and logs tools, with everyday use for each one.

Unlike domains and ports, which are resolved on the parent host, everything in this guide happens inside your VPS: the services, timers, and logs belong to your machine and you manage them entirely. As in the rest of the cloud area, each call carries company_id in addition to vps_id — ver_contexto_inicial returns both at once.

Tools covered: 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 and ver_logs_tarea_vps.

Services that must always be up

listar_servicios_vps — "What services are running on this machine?" Shows the systemd services configured inside the VPS. Typical use: you inherited a server from another provider and need to understand what is running before touching anything.

crear_servicio_vps — "Set up my Node bot as a service, so it starts on its own" Creates a service from the raw unit file content (service_name and content), with the option to start it immediately. The AI builds the file with the correct ExecStart, WorkingDirectory, and Restart=always. It is exactly the same power you have from the panel: the unit file content is not validated beyond what systemd validates, so ask it to show it to you before applying it. Typical use: moving a process that currently runs in a forgotten screen to something that survives a reboot.

ver_servicio_vps — "Show me how it was configured" Returns the full unit file and the live status. Typical use: verifying that the environment variable you added yesterday is actually in the file.

editar_servicio_vps — "Add the API key environment variable to it" Overwrites the unit file: full replacement, not a patch. Read before writing. Typical use: an application's port changed, or you need to add a parameter to the startup command.

controlar_servicio_vps — "Restart the worker" Executes start, stop, restart, enable or disable. Two clarifications that are often confused:

• enable and disable only change whether the service starts at boot. They do not turn it on or off right now. If you want both, they are two separate calls.
• There is no list of protected services here. Unlike deletion, this tool can stop or disable critical services such as nginx, docker or ssh. It is the most repeated task of all, and also the only one in this section where a misinterpreted phrase shuts down something that matters. Ask the AI to tell you what it will touch before touching it.

eliminar_servicio_vps — "Delete the old service from the project we closed" It stops it, disables it and removes the unit file. Here there is indeed a safety net: a set of critical services is protected —ssh, nginx, docker, mysql and others— and the tool refuses to delete them. Typical use: cleanup when offboarding a client.

ver_logs_systemd_vps — "Why did the worker die?" Reads the service's journalctl. Typical use: the exact moment something crashed and you need the real error, not a guess.

Tasks that run on their own

listar_tareas_vps — "What scheduled tasks are there?" Shows the systemd timers configured on the machine. Typical use: finding out why the server has a load spike every day at the same time.

crear_tarea_vps — "Schedule a database backup every day at 3 AM" Creates the task with its task_name, its command and its schedule, with the option to run it once immediately in addition to scheduling it.

The schedule uses systemd OnCalendar syntax, not cron and not "3 AM". The three formats you will use:

• --* 03:00:00 — every day at 3.
• Tue --* 04:00:00 — Tuesdays at 4.
• Shortcuts: daily, hourly, weekly.

In practice you don't need to memorize it: you describe the schedule in Spanish and the AI translates it. But if you are going to review what was configured, that is the syntax you will see.

Typical use: backups, temporary file cleanup, nightly synchronizations, report sending.

ver_tarea_vps — "When does it run and when did it last run?" Full details: service and timer contents, status, next execution and last one. Typical use: confirming that last night's backup actually ran before touching production.

editar_tarea_vps — "Move it to 5 AM, at 3 it clashes with something else" Changes the command, the schedule, or both — at least one is required. An implementation detail worth knowing because it shows: internally it deletes the task and recreates it. If it was enabled, it stays enabled. But it's a recreation, not an in-place adjustment, so the next execution is recalculated from scratch. Typical use: reordering the night window when two heavy processes overlap.

controlar_tarea_vps — "Run the backup now, don't wait until night" Four actions: start runs the command once, right now; stop interrupts that execution; enable and disable turn automatic scheduling on and off. There is no restart here, unlike services. Typical use: you want a backup before a migration, without waiting for the scheduled time.

eliminar_tarea_vps — "Remove the task from the report we no longer send" Deletes the task. And an honest warning: there is no list of protected names here as there is for services. Whatever you ask to delete, gets deleted. Typical use: cleaning up inherited automations that keep running without anyone reading their output — it's worth listing and confirming first.

ver_logs_tarea_vps — "Did last night's backup finish successfully?" Task logs, with two views: service (the command's own output) or timer (the timer that triggers it). The first is almost always what you want; the second is useful when you suspect the task didn't even run. Typical use: the check everyone should do and almost no one does, now just one question away.

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."

Frequently Asked Questions

Do I have to write the unit file myself? No. You describe what needs to run, from which folder, and with which variables, and the AI creates the file. Ask it to show it to you before applying it: the content is not validated beyond what systemd validates, so this is the time to review it.

Do scheduled tasks use cron? No: they are implemented with systemd timers, which serve the same purpose, integrate with the rest of the machine, and have their own logs. The schedule is written in OnCalendar syntax (--* 03:00:00), not cron syntax.

Can I run a task outside of its schedule? Yes, with controlar_tarea_vps and the start action. This is common before a migration or to test that the command works.

Can the AI accidentally shut down nginx or docker? Deleting them, no: eliminar_servicio_vps has a list of protected critical services. But stopping or disabling them, yes: controlar_servicio_vps does not have that protection. This is the most important asymmetry in this guide and it is worth keeping in mind when asking for a "stop everything".

Are tasks protected the same way? No. For tasks there is no list of protected names: whatever you ask to delete, gets deleted. List them before deleting.

Why do logs come "tagged"? Because anyone can write a log: an application, a process, an attacker testing things against your server. The three logging tools return their content wrapped and labeled as untrusted, with the instruction to treat it as data and never as instructions. If text in the form of a command directed at the AI appears in a log, the AI must report it to you, not obey it.

How do I connect the MCP? By adding https://mcp.ardumaker.com/mcp in a compatible client and authorizing it with your account.

Part of the series of guides on ArduMaker's MCP tools.