[Questo non affronta direttamente il problema dei file systemd-tmp ma penso che tu abbia già riconosciuto che in questo caso particolare stai meglio usando solo l'eco.]
Innanzitutto, "multi-user.target" potrebbe essere o meno ciò che si desidera utilizzare. Se hai familiarità con il concetto di runlevel da init init in stile SysV, multi-user è l'equivalente di sistema di runlevel 3, che è un sistema multi-user che si avvia su una console, non su una GUI. L'equivalente di runlevel 5, che si avvia su X, è graphical.target . Il valore predefinito è determinato da un collegamento simbolico in /etc/systemd/system(e / o /lib/systemd/system; quello in /etcsovrascriverà quello in /lib) chiamato default.target , usa ls per trovare dove punta:
»ls -l /etc/systemd/system/default.target
default.target -> /usr/lib/systemd/system/multi-user.target
Per i normali desktop linux questo sarà graphical.target. Questo in realtà non è importante se vuoi che il servizio di avvio che stai creando venga avviato indipendentemente da quale sia il runlevel / target predefinito - in tal caso, possiamo semplicemente usare default.target e non preoccuparti di cosa sia un alias. Se si utilizza più utenti, tuttavia, e l'impostazione predefinita è grafica, il servizio non verrà eseguito.
A seconda del servizio, potrebbero esserci obiettivi o servizi più appropriati e specifici che si desidera avviare questo in relazione. Sulla base dell'altra tua domanda, default.target probabilmente va bene. Come nota, la differenza tra un "target" e un "servizio" è che un servizio contiene un[Service] sezione che esegue effettivamente un processo; un obiettivo è solo un modo di raggruppare i servizi attraverso le varie direttive "dipendenti" e "richiede"; non fa nulla di proprio oltre a innescare altri obiettivi o servizi.
L'avvio di un servizio è determinato da quali altri servizi dipendono esplicitamente da esso. Nel caso di un evento semplice e autonomo come questo che vogliamo eseguire in ritardo nel processo di avvio, possiamo usare questa combinazione di direttive:
[Unit]
After=default.target
[Install]
WantedBy=default.target
La sezione "Installa" viene utilizzata quando il servizio è installato; "WantedBy" specifica un target con cui si desidera includere questo servizio (il che significa che verrà eseguito se tale target lo fa, ma nb. Ciò non determina quando verrà eseguito in relazione ad altri ). Poiché in realtà vogliamo che questo servizio venga eseguito in un secondo momento anziché prima, quindi specifichiamo una clausola "Dopo". Questo in realtà non deve essere lo stesso del target WantedBy (di solito non lo è) e può essere completamente omesso se non ti interessa quando succede; Lo sto solo usando per il sospetto che la maggior parte delle altre cose verranno eseguite in relazione a cose che sono da qualche parte incatenate a qualcosa che ha specificatoBefore=default.target (che avremmo anche potuto usare; i desideri di un bersaglio vengono valutati prima che venga eseguito il bersaglio).
Per esempio, farò solo eco "ciao mondo" alla console. Il servizio stesso è descritto nella [Service]sezione:
[Service]
Type=forking
ExecStart=/usr/local/bin/helloworld
Il comando richiede un percorso completo. Il motivo per cui non ho semplicemente usato /usr/bin/echo "hello world"è che non funzionerà (l'output va a / dev / null, credo), e mentre un servizio fa echo "hello world" > /dev/consoletestamento, la sperimentazione dimostra che l'uso del reindirizzamento della shell in una direttiva ExecStart non funzionerà . Quindi, / usr / local / bin / helloworld è uno script di shell con quella linea uno, echo "hello world" > /dev/console.
Nota il Type=forking, che è necessario per uno script di shell.
Il nostro, file completo servizio minimo è solo quei tre sezioni ( [Unit], [Service], e [Install]). Per installare, posizionare il file o un link simbolico in / etc / systemd / system o / usr / lib / systemd / system e:
systemctl --system enable helloworld
Dovrebbe stampare ln -s ... . Questo non esegue il servizio, lo configura solo per l'avvio come discusso sopra.
In poche parole. man systemd.unite man systemd.serviceavere maggiori dettagli.