Ho letto che ci sono due cartelle per i file unit (non in modalità utente).

/usr/lib/systemd/system/: units provided by installed packages
/etc/systemd/system/: units installed by the system administrator

In conflitto con questa comprensione è la risposta a questa domanda:come scrivere uno script di avvio per Systemd. Qualcuno può inserire le informazioni mancanti in modo da capire cosa sta succedendo? (AGGIORNAMENTO:la risposta è stata aggiornata e la mia comprensione non è più in conflitto con essa. )

Inoltre, sembra che gli script siano organizzati in sottocartelle all'interno di /etc/systemd/system/ cartella:

getty.target.wants
multi-user.target.wants

In un'altra posizione ho letto che ci sono altre posizioni. Sembra che questi siano per servizi specifici dell'utente.

/usr/lib/systemd/user/ where services provided by installed packages go.
/etc/systemd/user/ where system-wide user services are placed by the system administrator.
~/.config/systemd/user/ where the user puts its own services.

Aggiornamento 31-08-2015:

Per il bene degli altri, ecco un collegamento a una domanda correlata che ho posto di recente:dove metto gli script eseguiti dalle unità di sistema?

Risposta accettata:

Il posto migliore per mettere il sistema file di unità: /etc/systemd/system Assicurati solo di aggiungere un target nella sezione [Installa], leggi "Come fa a saperlo?" per dettagli. AGGIORNAMENTO :/usr/local/lib/systemd/system è un'altra opzione, leggi "Area grigia" per i dettagli."

Il posto migliore dove mettere utente file di unità: /etc/systemd/user o $HOME/.config/systemd/user ma dipende dai permessi e dalla situazione.

La verità è che le unità systemd (o, come le chiama la frase introduttiva, "configurazioni di unità") possono andare ovunque —a condizione che tu sia disposto a creare collegamenti simbolici manuali e che tu sia a conoscenza degli avvertimenti. Rende la vita più facile mettere l'unità dove systemctl daemon-reload può trovarlo per alcuni buoni motivi:

• L'utilizzo di una posizione standard significa che i generatori di systemd li troveranno e ne renderanno facile l'abilitazione all'avvio con systemctl enable . Questo perché la tua unità verrà automaticamente aggiunta a un albero delle dipendenze delle unità (una cache di unità).
• Non è necessario pensare alle autorizzazioni, perché solo gli utenti privilegiati giusti possono scrivere nelle aree designate.

Come fa a saperlo?

E come si abilita esattamente systemctl enable sai dove creare il collegamento simbolico? Puoi codificarlo in modo rigido all'interno dell'unità
stessa sotto il [install] sezione. Di solito c'è una linea come

[Install]
WantedBy = multi-user.target

che corrisponde a una posizione predefinita nel filesystem.
In questo modo, systemctl enable sa che questa unità dipende da un gruppo di file di unità chiamato multi-user.target ("target" è il termine usato per designare i gruppi di unità dipendenti. Puoi elencare tutti i gruppi con systemctl list-units --type target ). Il gruppo di file unit da caricare con un target viene inserito in un targetname.target.wants directory. Questa è solo una directory piena di collegamenti simbolici (o la cosa reale). Se il tuo [Install] la sezione dice che è WantedBy il multi-user.target , ma se non esiste un collegamento simbolico in multi-user.target.wants directory, quindi non verrà caricato. Quando i generatori di unità systemd aggiungono il file dell'unità alla cache dell'albero delle dipendenze all'avvio (puoi attivare manualmente i generatori con systemctl daemon-reload ), sa automaticamente dove inserire il collegamento simbolico, in questo caso nella directory /etc/systemd/system/multi-user.target.wants/ dovresti abilitarlo.

Punti chiave nel manuale:

systemd-run -u restart --description="Restarts machine" --on-calendar="2020-12-18 00:04:00" systemctl --force reboot

# This is a transient unit file, created programmatically via the systemd API. Do not edit.
[Unit]
Description=Restarts machine

[Service]
ExecStart=
ExecStart="/usr/bin/systemctl" "--force" "reboot"