systemd services

What can you do with it?

• List every service on the VPS and see one in detail: its unit file, whether it is active and whether it starts at boot.
• Create a service from the full content of a unit file.
• Replace the unit file of an existing service.
• Start, stop, restart, enable or disable a service.
• Delete a service (except protected ones) and read its logs.

When should you use it?

• A process that must keep running and does not belong to an ArduMaker app: a worker, a bot, a metrics exporter.
• Restarting a service after changing its configuration.
• Checking why a service keeps crashing.

How does it work in ArduMaker?

Create

1. The name is validated: lowercase, and spaces and / become hyphens. Only letters, digits and _ . @ : -, up to 200 characters; otherwise nombre_invalido.
2. If /etc/systemd/system/<nombre>.service already exists, a .backup copy is saved.
3. The content is written as received (no extra validation), with 644 permissions.
4. systemctl daemon-reload, then systemctl start and systemctl enable.
5. If any of those steps fails, the new unit is deleted, the copy is restored and systemd is reloaded. The answer says which step failed (Failed to start service, Failed to enable service…).

In practice, creating a service always leaves it running and enabled at boot; a service that does not start is not left behind.

Edit

Editing replaces the whole file with the same procedure, but it runs start, not restart: if the service was already running, it keeps the previous configuration until it is restarted with controlar_servicio_vps and the restart action.

Control and delete

• start, stop and restart act now; enable and disable only change whether it starts with the system.
• Control has no protected list: nginx or docker can be stopped.
• Deleting stops, disables, removes /etc/systemd/system/<nombre>.service and reloads systemd. A unit that came with a system package is stopped and disabled, but its file is not in that folder and is not deleted.
• These cannot be deleted: ssh, sshd, networking, systemd-journald, systemd-logind, docker, containerd, nginx, apache2, mysql and postgresql.

What actually changes?

• /etc/systemd/system/<nombre>.service (644) and the enable link for system boot.
• The running process, with standard output and error in the journal.
• An entry in the VPS activity log for each creation, edit, action or deletion.

Unit example

A unit like the one ArduMaker builds for deploy processes:

[Unit]
Description=mi-worker
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/mi-worker
Environment="MODO=produccion"
ExecStart=/opt/mi-worker/venv/bin/python worker.py
Restart=always
RestartSec=3
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

• Restart=always brings it back up if it crashes.
• StandardOutput=journal makes ver_logs_systemd_vps show its output.
• WantedBy=multi-user.target is what makes enable possible.

Diagram

Expected result

• The create, edit and control answers include status, is_active and is_enabled read after the operation.
• ver_servicio_vps returns service_file, content, status, is_active, is_enabled and details.
• ver_logs_systemd_vps returns the last 500 lines of the service journal.

systemctl status mi-worker
journalctl -u mi-worker -n 100 --no-pager

Errors and troubleshooting

Creating and editing are safe to repeat with the same content. controlar_servicio_vps is not, in general (repeating a stop or restart cuts the service again), and it can stop critical services. If the VPS does not answer, the error can be retried (424).

MCP access

Yes, in the /mcp and /mcp/vps profiles. A read-only agent only sees listar_servicios_vps, ver_servicio_vps and ver_logs_systemd_vps.

For the processes of a Git app, prefer ver_config_deploy_app and guardar_config_deploy_app over these tools. Reference at /mcp/docs and examples at /mcp/servicios.

Related features

• Scheduled tasks
• GitHub deploy
• Monitoring
• Web terminal
• VPS servers