In /etc/systemd/system/. Poi esegui systemctl daemon-reload e systemctl enable --now .service — i comandi generati fanno tutto questo.

Generatore di file di servizio systemd: crea .service e .timer

Generatore di file di servizio systemd

Tieni in esecuzione un programma Node.js, Python o Go su un server Linux, avvialo al boot e riavvialo quando va in crash — senza dover ricordare ogni opzione di systemd. Compila comando e utente, scegli una politica di riavvio e le variabili d’ambiente, e copia il file .service insieme ai comandi per installarlo e avviarlo. Spunta Esegui con una pianificazione (crea un .timer) per ottenere un .timer, alternativa moderna a cron.

Funziona nel tuo browser: nulla di ciò che inserisci viene caricato

Nome del servizio

Diventa il nome del file, ad es. myapp → myapp.service

Descrizione

Comando (ExecStart)

Usa il percorso completo del programma, ad es. /usr/bin/python3 app.py

Directory di lavoro

Esegui come utente

Gruppo

Type

Il comando resta in esecuzione in primo piano (la maggior parte delle app web e degli script).

Restart

Attesa prima del riavvio (s)

Variabili d’ambiente

Una CHIAVE=valore per riga; i valori con spazi vengono messi tra virgolette per te.

File d’ambiente

Max file aperti (LimitNOFILE)

0 mantiene il valore predefinito del sistema.

Avvia dopo che la rete è onlineHardening di base (nessun nuovo privilegio, /tmp privato, sistema di sola lettura)Esegui con una pianificazione (crea un .timer)

myapp.service

[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/srv/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Installa e avvia

sudo tee /etc/systemd/system/myapp.service > /dev/null << 'EOF'
[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/srv/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
systemctl status myapp.service
journalctl -u myapp.service -f

Incolla i comandi sul server come root. Dopo aver modificato un file unit, esegui di nuovo systemctl daemon-reload. Log: journalctl -u <name>.

Come si usa

Inserisci il nome del servizio, il comando con il percorso completo e la directory di lavoro.
Imposta l’utente, la politica di riavvio e le eventuali variabili d’ambiente.
Se vuoi, aggiungi un hardening di base o una pianificazione (OnCalendar) per creare un timer.
Copia i file generati, oppure incolla i comandi di installazione in una shell root sul server.

Opzioni spiegate

Type: simple va bene per i programmi che restano in primo piano; oneshot va bene per gli script eseguiti una sola volta, come le attività pianificate.
Restart: In caso di errore riavvia il servizio quando termina con un errore o va in crash; Sempre lo riavvia anche dopo una chiusura normale.
OnCalendar: Quando scatta il timer, ad es. daily oppure *-*-* 03:00:00 per le 3 di notte ogni giorno. Prova le espressioni con systemd-analyze calendar.

Esempio: un lavoro notturno come timer

Per eseguire uno script ogni notte alle 3, imposta il Comando (ExecStart) su /usr/local/bin/backup.sh, il nome del servizio su backup, Type su oneshot e Restart su Mai, poi seleziona «Esegui con una pianificazione (crea un .timer)» e «Hardening di base». Con l’utente e la directory di lavoro predefiniti, il generatore produce due file. backup.service:

[Unit]
Description=Nightly backup

[Service]
Type=oneshot
User=www-data
WorkingDirectory=/srv/myapp
ExecStart=/usr/local/bin/backup.sh
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=read-only

e backup.timer:

[Unit]
Description=Run backup on a schedule

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
Unit=backup.service

[Install]
WantedBy=timers.target

Con il timer attivo cambiano due cose. Il file del servizio perde la sezione [Install], perché è il timer ad avviarlo, e i comandi di installazione abilitano il timer anziché il servizio:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer
journalctl -u backup.service -f

Il Type non viene cambiato per te quando selezioni l’opzione del timer, quindi scegli oneshot tu stesso per i lavori che terminano. Un servizio oneshot combinato con Restart Sempre non è valido, quindi il generatore omette Restart e mostra un avviso.

Domande frequenti

Dove metto il file?

In /etc/systemd/system/. Poi esegui systemctl daemon-reload e systemctl enable --now <name>.service — i comandi generati fanno tutto questo.

Perché il mio servizio fallisce con “Executable path is not absolute”?

Le versioni più vecchie di systemd richiedono il percorso completo del programma in ExecStart. Trovalo con which, ad es. which node.

Timer o cron?

I timer scrivono nel journal, possono recuperare le esecuzioni perse mentre il server era spento e non girano mai due volte insieme. cron è più semplice per i comandi di una riga e funziona ancora benissimo.

Privacy

Questo strumento funziona interamente nel tuo browser. File e testi vengono elaborati sul tuo dispositivo e non vengono mai caricati sui nostri server.