Generatore di file servizio Systemd
Compila un form con eseguibile, working directory, politica di riavvio e utente — ottieni una unit .service pronta all'installazione (e un'opzionale unit .timer di supporto), con ogni riga generata spiegata.
Preset
Parti da un carico comune
Carica valori predefiniti sensati per i campi sotto. Tutto resta modificabile in seguito.
[Unit]
Descrizione e ordinamento
La sezione [Unit] è metadata e ordinamento — dice a systemd cos'è questo servizio e dopo cosa dovrebbe partire, ma non avvia nulla da sola.
Le unit dopo cui questo dovrebbe avviarsi, separate da spazio.
[Service] — processo
Cosa eseguire
Richiesto un percorso assoluto.
Predefinito a User se lasciato vuoto.
[Service] — ambiente
Variabili d'ambiente
Ogni riga diventa una propria riga Environment=. Usa invece EnvironmentFile per i segreti che non vuoi tenere nel file unit stesso.
Opzionale, percorso assoluto.
[Install]
Quando si avvia automaticamente
La sezione [Install] conta solo per systemctl enable — dice la sequenza di boot di quale target dovrebbe includere questo servizio.
[Service] — affidabilità
Politica di riavvio
Non è un interruttore on/off — scegli la variante che corrisponde a come questo processo dovrebbe fallire.
Riavvia in caso di crash, uscita con codice diverso da zero o timeout — ma un deliberato "systemctl stop" o un'uscita pulita exit(0) vengono lasciati stare. La scelta abituale per un'app o un server di gioco di lunga durata: si riprende dai crash senza opporsi a un admin che l'ha fermato di proposito.
Secondi da attendere prima di riavviare.
Opzionale
Limita quanta RAM e CPU può usare questo singolo servizio. Lascia disattivato a meno che tu non abbia davvero bisogno di un tetto rigido.
Validazione
Errori comuni
Sembra pulito — nessun problema rilevato.
Unit companion opzionale
Esegue questo servizio secondo una pianificazione invece che (o in aggiunta a) al boot — l'equivalente systemd di un cron job, legato a carichi Type=oneshot. Preferisci il semplice cron per qualcosa di più semplice? Un Generatore di cron job separato copre quel caso — OnCalendar= è una sintassi diversa da cron e non è un sostituto diretto.
Output
File unit generati
my-application.service
[Unit] Description=My application After=network.target Wants=network.target [Service] Type=simple ExecStart=/usr/bin/node /opt/wespner-app/server.js WorkingDirectory=/opt/wespner-app User=wespner-app Environment="NODE_ENV=production" Environment="PORT=3000" Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
Comandi di installazione
sudo cp my-application.service /etc/systemd/system/my-application.service sudo systemctl daemon-reload sudo systemctl enable --now my-application.service journalctl -u my-application.service -f # follow logs
Gestisci un tuo server di gioco?
Server di gioco Wespner con protezione DDoS, dischi NVMe e attivazione in pochi minuti.