Servicios systemd

Chinaski corre como servicios systemd estándar en Linux. Como son unidades template, un solo conjunto de archivos ejecuta cualquier número de sites en el mismo host. Esta página cubre las tres familias de unidades incluidas (el propio CMS, el backup diario, el adaptador opcional del asistente de IA) y cómo trabajar con ellas día a día.

El servicio principal: `chinaski@<instance>`

Cada instancia del CMS corre bajo su propia unidad systemd. Habilita y arranca una nueva con su nombre de instancia:

systemctl enable --now chinaski@1

(2, prod, staging: cualquier cosa alfanumérica funciona igual.) De qué se encarga la unidad:

Ejecuta el CMS como un usuario chinaski dedicado, sin login, desde el directorio de esa instancia.
Establece las rutas de base de datos y de salida automáticamente a partir del nombre de la instancia: normalmente no las configuras tú.
Lee un archivo de entorno por instancia, /etc/chinaski<instance>/env, que tú creas antes de arrancar. Debe contener CHINASKI_SECRET y LISTEN_URL (enlaza a loopback, p. ej. http://127.0.0.1:3001, cuando un proxy inverso está delante del site: los comentarios del archivo de ejemplo explican por qué importa).
Reinicia ante fallos con un retraso corto, limitado a cinco intentos por minuto para que una configuración rota no quede en bucle infinito.
Detiene de forma elegante: el shutdown espera hasta cinco minutos a que las peticiones en curso y un build en ejecución terminen.
Corre enjaulada: sistema de archivos de solo lectura excepto su propio directorio, sin privilegios nuevos, /tmp privado, memoria limitada a 1 GB, CPU al 200%.

Cada instancia es la misma unidad con un nombre distinto, y cada una tiene su propia base de datos, salida y entorno: ver Instances para el modelo completo.

Eventos y logs

Todo llega a journald, etiquetado como chinaski-<instance>:

journalctl -u chinaski@<instance>       # sigue con -f
systemctl status chinaski@<instance>

Si el servicio falla al arrancar, el journal muestra por qué; el instalador apunta ahí automáticamente cuando un primer arranque falla.

El backup diario: `chinaski-backup@`

Cada instancia tiene una unidad oneshot correspondiente y un timer:

El servicio toma una instantánea de la base de datos de la instancia y espeja su media, corriendo con una vista de solo lectura del directorio del site y acceso de escritura solo al directorio de backup.
El timer se dispara a diario a las 03:17 hora local (minuto deliberadamente impar para que varias instancias en un mismo host no respalden en el mismo instante), con un pequeño retraso aleatorio, y se recupera si el host estaba apagado cuando le tocaba.
Comprueba que esté registrada con systemctl list-timers chinaski-backup@<instance>.timer: tras editar una programación, sí revisa, porque systemd omite en silencio una cadena de calendario con typo.
Limitada a menos de 10 minutos; incluso una base de datos de 1 GB termina en muy menos de un minuto en disco local.

El adaptador opcional: `chinaski-mcp@`

Si usas asistentes de IA contra el API de un site, ese adaptador tiene su propia unidad por instancia:

Ordenada después de la unidad del CMS de la misma instancia (para que el CMS exista primero).
Lee su URL de API y su API key desde /etc/chinaski<instance>/mcp-env (también con permisos restringidos).
Sobre de recursos menor que el CMS (la mitad de memoria y CPU), con el mismo hardening de sandbox y auto-reinicio.

Habilita una con systemctl enable --now chinaski-mcp@<instance> después de que exista la instancia del CMS correspondiente.

Comandos del día a día

systemctl status chinaski@<instance>     # ¿está corriendo?
systemctl restart chinaski@<instance>    # tras cambios manuales de archivos (p. ej. admin assets)
journalctl -u chinaski@<instance> -f     # sigue el log
systemctl list-timers 'chinaski-backup@*'   # confirma cada programación de backup

Los deploys no cambian la unidad: el script de deploy se encarga del reinicio después de un build verificado. Si más adelante adoptas el Manager, él maneja estas mismas unidades por nombre (start/stop/restart), así que las instancias pueden pasar a su control sin reinstalarse.

Salvaguardas, en resumen

Auto-reinicio ante fallos (con tope de backoff contra bucles de crash).
Paradas elegantes: las peticiones y los builds se drenan antes de que el proceso salga.
Techos de memoria/CPU por unidad, ajustados para que un builder desbocado no mate de hambre al host.
Un sandbox por instancia: ninguna instancia puede leer ni escribir los archivos de otra.
Journald captura todo: no hay un daemon de logging separado que gestionar.