Servicios systemd, tareas programadas y logs en un VPS, pedidos en lenguaje natural

Publicado el 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.

Escribir un unit file de systemd a mano es de esas cosas que uno hace tres veces por año y siempre termina buscando la sintaxis. Lo mismo con los timers: nadie recuerda de memoria cómo se expresa "todos los martes a las 4 de la mañana".

Con el MCP de ArduMaker, eso se describe en una frase y la IA arma el archivo. Este artículo recorre las herramientas de servicios, tareas programadas y logs, con un uso cotidiano para cada una.

A diferencia de los dominios y los puertos, que se resuelven en el host padre, todo lo de esta guía pasa adentro de tu VPS: los servicios, los timers y los logs son de tu máquina y los administrás enteros. Como en el resto del área de cloud, cada llamada lleva company_id además del vps_id — ver_contexto_inicial te devuelve ambos de una.

Herramientas cubiertas: 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.

Servicios que tienen que estar siempre arriba

listar_servicios_vps — "¿Qué servicios corren en esta máquina?" Muestra los servicios systemd configurados dentro del VPS. Uso típico: heredaste un servidor de otro proveedor y necesitas entender qué hay corriendo antes de tocar nada.

crear_servicio_vps — "Pon mi bot de Node como servicio, que arranque solo" Crea un servicio a partir del contenido crudo del archivo de unidad (service_name y content), con la opción de iniciarlo en el momento. La IA arma el archivo con el ExecStart, el WorkingDirectory y el Restart=always correctos. Es exactamente el mismo poder que tienes desde el panel: el contenido del archivo de unidad no se valida más allá de lo que valide systemd, así que pídele que te lo muestre antes de aplicarlo. Uso típico: pasar un proceso que hoy corre en un screen olvidado a algo que sobreviva a un reinicio.

ver_servicio_vps — "Muéstrame cómo quedó configurado" Devuelve el archivo de unidad completo y el estado en vivo. Uso típico: verificar que la variable de entorno que agregaste ayer efectivamente está en el archivo.

editar_servicio_vps — "Agrega la variable de entorno de la API key" Sobrescribe el archivo de unidad: reemplazo completo, no un parche. Lee antes de escribir. Uso típico: cambió el puerto de una aplicación, o hay que sumar un parámetro al comando de arranque.

controlar_servicio_vps — "Reiniciá el worker" Ejecuta start, stop, restart, enable o disable. Dos precisiones que se confunden seguido:

• enable y disable solo cambian si el servicio arranca al bootear. No lo prenden ni lo apagan ahora. Si querés las dos cosas, son dos llamadas.
• Acá no hay lista de servicios protegidos. A diferencia del borrado, esta herramienta puede detener o deshabilitar servicios críticos como nginx, docker o ssh. Es el trabajo más repetido de todos, y también el único de esta sección donde una frase mal interpretada apaga algo que importa. Pedile a la IA que te diga qué va a tocar antes de tocarlo.

eliminar_servicio_vps — "Borrá el servicio viejo del proyecto que cerramos" Lo detiene, lo deshabilita y quita el unit file. Acá sí hay red: un conjunto de servicios críticos está protegido —ssh, nginx, docker, mysql y compañía— y la herramienta se niega a borrarlos. Uso típico: limpieza al dar de baja un cliente.

ver_logs_systemd_vps — "¿Por qué se murió el worker?" Lee el journalctl del servicio. Uso típico: el momento exacto en que algo se cayó y necesitás el error real, no una suposición.

Tareas que se repiten solas

listar_tareas_vps — "¿Qué tareas programadas hay?" Muestra los timers de systemd configurados en la máquina. Uso típico: descubrir por qué el servidor tiene un pico de carga todos los días a la misma hora.

crear_tarea_vps — "Programá un backup de la base todos los días a las 3 AM" Crea la tarea con su task_name, su command y su schedule, con la opción de correrla una vez de inmediato además de programarla.

El horario usa sintaxis OnCalendar de systemd, no cron y no "3 AM". Los tres formatos que vas a usar:

• --* 03:00:00 — todos los días a las 3.
• Tue --* 04:00:00 — los martes a las 4.
• Atajos: daily, hourly, weekly.

En la práctica no hace falta que te la acuerdes: describís el horario en castellano y la IA lo traduce. Pero si vas a revisar lo que quedó configurado, es la sintaxis que vas a ver.

Uso típico: backups, limpieza de archivos temporales, sincronizaciones nocturnas, envío de reportes.

ver_tarea_vps — "¿Cuándo corre y cuándo corrió por última vez?" Detalle completo: contenido del service y del timer, estado, próxima ejecución y última. Uso típico: confirmar que el backup de anoche efectivamente corrió antes de tocar producción.

editar_tarea_vps — "Pasala a las 5 AM, a las 3 choca con otra cosa" Cambia el comando, el horario, o los dos — hace falta al menos uno. Un detalle de implementación que conviene conocer porque se nota: por dentro borra la tarea y la vuelve a crear. Si estaba habilitada, la deja habilitada. Pero es un recreado, no un ajuste en el lugar, así que la próxima ejecución se recalcula desde cero. Uso típico: reordenar la ventana nocturna cuando dos procesos pesados se pisan.

controlar_tarea_vps — "Corré el backup ahora, no esperes a la noche" Cuatro acciones: start corre el comando una vez, ya mismo; stop interrumpe esa ejecución; enable y disable prenden y apagan la programación automática. No hay restart acá, a diferencia de los servicios. Uso típico: querés un respaldo antes de una migración, sin esperar al horario programado.

eliminar_tarea_vps — "Sacá la tarea del reporte que ya no mandamos" Borra la tarea. Y una advertencia honesta: acá no hay lista de nombres protegidos como sí la hay para los servicios. Lo que le pidas borrar, se borra. Uso típico: limpiar automatismos heredados que siguen corriendo sin que nadie lea su resultado — vale la pena listar y confirmar antes.

ver_logs_tarea_vps — "¿El backup de anoche terminó bien?" Logs de la tarea, con dos vistas: service (la salida del propio comando) o timer (el timer que la dispara). El primero es el que casi siempre querés; el segundo sirve cuando la sospecha es que la tarea ni siquiera se disparó. Uso típico: la comprobación que todos deberían hacer y casi nadie hace, ahora a una pregunta de distancia.

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

Preguntas frecuentes

¿Tengo que escribir el unit file yo? No. Describís qué tiene que correr, desde qué carpeta y con qué variables, y la IA arma el archivo. Pedile que te lo muestre antes de aplicarlo: el contenido no se valida más allá de lo que valide systemd, así que es el momento de revisarlo.

¿Las tareas programadas usan cron? No: se implementan con timers de systemd, que cumplen la misma función, quedan integrados con el resto de la máquina y tienen sus propios logs. El horario se escribe en sintaxis OnCalendar (--* 03:00:00), no en la de cron.

¿Puedo ejecutar una tarea fuera de horario? Sí, con controlar_tarea_vps y la acción start. Es lo habitual antes de una migración o para probar que el comando funciona.

¿Puede la IA apagar nginx o docker sin querer? Borrarlos, no: eliminar_servicio_vps tiene una lista de servicios críticos protegidos. Pero detenerlos o deshabilitarlos, sí: controlar_servicio_vps no tiene esa protección. Es la asimetría más importante de esta guía y conviene tenerla presente al pedir un "pará todo".

¿Y las tareas están protegidas igual? No. Para tareas no hay lista de nombres protegidos: lo que le pidas borrar, se borra. Listá antes de eliminar.

¿Por qué los logs vienen "marcados"? Porque un log lo escribe cualquiera: una aplicación, un proceso, un atacante probando cosas contra tu servidor. Las tres herramientas de logs devuelven su contenido envuelto y etiquetado como no confiable, con la instrucción de tratarlo como datos y nunca como instrucciones. Si en un log aparece texto con forma de orden dirigida a la IA, la IA te lo tiene que reportar, no obedecer.

¿Cómo conecto el MCP? Agregando https://mcp.ardumaker.com/mcp en un cliente compatible y autorizándolo con tu cuenta.

Parte de la serie de guías sobre las herramientas del MCP de ArduMaker.