Il sostituto corretto per Rc.local in Systemd invece di ricreare Rc.local?

Non riesco a trovare il modo corretto per eseguire alcuni local script (o comandi molto locali) su systemd, so già che non devo creare un servizio (in systemd un'unità) per questo tipo di script (o devo?)….

La soluzione che ho trovato è creare rc.local e dargli i permessi di esecuzione.

printf '#!/bin/bash nnexit 0' >/etc/rc.local 
chmod +x /etc/rc.local

Ad esempio, se ottengo un server legacy con un semplice rc.local configurato da te, saprò cosa hai fatto e quanto farà male aggiornare o installare qualcosa di nuovo sulla distribuzione, poiché rc.local è stato rispettato da external pacchetti, ma d'altra parte se installo un server e creo un'unità systemd o due o tre (o anche servizi sysvinit), solo per fare un compito semplice, questo a volte può renderti la vita più difficile, e molto di più le mie unità i nomi un giorno possono entrare in conflitto con i nomi dei nuovi servizi creati dallo sviluppo della distribuzione e forse installati su un aggiornamento, causando problemi ai miei script!

Vedo un'altra domanda chiedendo informazioni su dov'è rc.local e la risposta è stata crearlo e concedere i permessi di esecuzione, penso che la mia domanda sia davvero non un duplicato , perché non voglio sapere dove sia – credimi, voglio solo accettare che è obsoleto , ma non riesco a trovare il modo corretto per fare questo genere di cose, dovrei davvero creare un'unità solo per alcuni semplici del genere?

Risposta accettata:

Come sottolineato altrove, diventa moderatamente impuro usare rc-local.service sotto systemd .

1. In teoria è possibile che la tua distribuzione non lo abiliti. (Penso che questo non sia comune, ad esempio perché la disabilitazione della stessa opzione di build rimuove anche poweroff / reboot comandi che molte persone usano).
2. La semantica non è del tutto chiara. Systemd definisce rc-local.service in un modo, ma Debian fornisce un file drop-in che altera almeno un'impostazione importante.

rc-local.service spesso può funzionare bene. Se sei preoccupato per quanto sopra, tutto ciò che devi fare è crearne una tua copia! Ecco la magia:

# /etc/systemd/system/my-startup.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/libexec/my-startup-script

[Install]
WantedBy=multi-user.target

Non credo che tu debba capire ogni singolo dettaglio[*], ma ci sono due cose che devi sapere qui.

1. Devi abilitarlo con systemctl enable my-startup.service .

2. Se il tuo script ha una dipendenza da qualsiasi altro servizio, incluso network-online.target , devi dichiararlo. Per esempio. aggiungi un [Unit] sezione, con le righe Wants=network-online.target e After=network-online.target .

   Non devi preoccuparti delle dipendenze dai servizi di "avvio anticipato", in particolare i servizi che sono già stati ordinati prima di basic.target . Servizi come my-startup.service vengono ordinati automaticamente dopo basic.target , a meno che non impostino DefaultDependencies=no .

   Se non sei sicuro che una delle tue dipendenze sia un servizio di "avvio anticipato", un approccio consiste nell'elencare i servizi ordinati prima di basic.target , eseguendo systemctl list-dependencies --after basic.target . (Nota che è --after , non --before ).

Correlati:ottieni lo script da eseguire di nuovo se l'input è sì?

Ci sono alcune considerazioni che penso siano applicate anche a rc.local pre-systemd :

1. Devi assicurarti che i tuoi comandi non siano in conflitto con un altro programma che tenta di controllare la stessa cosa.
2. È meglio non avviare programmi di lunga durata, noti anche come demoni da rc.local .

[*] Ho usato Type=oneshot + RemainAfterExit=yes perché ha più senso per la maggior parte degli script one-shot. Formalizza che eseguirai una serie di comandi, che my-startup verranno mostrati come "attivi" una volta completati e che non avvierai un demone.