Ho letto che ci sono due cartelle per i file di 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 seguente risposta: https://unix.stackexchange.com/a/47715/33386 . Qualcuno può compilare 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 della /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 2015-08-31:

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

Il posto migliore dove inserire i file delle unità di sistema : /etc/systemd/system assicurati solo di aggiungere una destinazione 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 inserire i file delle unità utente : /etc/systemd/user o $HOME/.config/systemd/user ma dipende dalle autorizzazioni e dalla situazione.

La verità è che le unità di sistema (o come le chiamano la frase introduttiva, "configurazioni di unità") possono andare ovunque - purché tu sia disposto a creare collegamenti simbolici manuali e sei consapevole delle avvertenze. Rende la vita più facile mettere l'unità dove systemctl daemon-reloadpuò trovarla per alcuni buoni motivi:

• L'uso di una posizione standard significa che i generatori di systemd li troveranno e li renderanno facili da abilitare all'avvio systemctl enable. Questo perché la tua unità verrà automaticamente aggiunta a un albero di dipendenza unità (una cache di unità).
• Non è necessario pensare alle autorizzazioni, poiché solo gli utenti privilegiati possono scrivere nelle aree designate.

Come lo sa?

E come fa esattamente a systemctl enablesapere dove creare il collegamento simbolico? È difficile codificarlo all'interno dell'unità stessa nella [install]sezione. Di solito c'è una linea come

[Install]
WantedBy = multi-user.target

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

Punti chiave nel manuale:

Unità aggiuntive potrebbero essere caricate in systemd ("collegato") da directory non sul percorso di caricamento dell'unità. Vedi il comando link per systemctl (1).

In systemctl, cerca Comandi file unità

Percorso caricamento file unità

I file di unità vengono caricati da una serie di percorsi determinati durante la compilazione, descritti nelle due tabelle seguenti. I file di unità trovati nelle directory elencate in precedenza sostituiscono i file con lo stesso nome nelle directory più in basso nell'elenco.

Quando $SYSTEMD_UNIT_PATHviene impostata la variabile , il contenuto di questa variabile sovrascrive il percorso di carico dell'unità. Se $SYSTEMD_UNIT_PATHtermina con un componente vuoto (":"), il normale percorso di caricamento dell'unità verrà aggiunto al contenuto della variabile.

La tabella 1 e la tabella 2 man systemd.unitsono buone.

Caricare i percorsi durante l'esecuzione in modalità di sistema ( --system).

• /etc/systemd/system Configurazione locale
• /run/systemd/system Unità di runtime
• /usr/lib/systemd/system Unità di pacchetti installati

Carica percorso durante l'esecuzione in modalità utente ( --user)

C'è una differenza tra le unità per utente e tutte le unità / utenti globali .

User-dipendente

• $XDG_CONFIG_HOME/systemd/user Configurazione utente (utilizzata solo quando $XDG_CONFIG_HOMEè impostata)
• $HOME/.config/systemd/user Configurazione utente (utilizzata solo quando $XDG_CONFIG_HOMEnon è impostata)

• $XDG_RUNTIME_DIR/systemd/user Unità di runtime (utilizzate solo quando $XDG_RUNTIME_DIRè impostato)

• $XDG_DATA_HOME/systemd/user Unità di pacchetti che sono state installate nella home directory (utilizzata solo quando $XDG_DATA_HOMEè impostata)

• $HOME/.local/share/systemd/user Unità di pacchetti che sono state installate nella home directory (utilizzate solo quando $XDG_DATA_HOMEnon sono impostate)

--global (tutti gli utenti)

Unità che si applicano a tutti gli utenti, vale a dire anche di proprietà di ciascun utente. Quindi ogni utente può interrompere questi servizi anche se un amministratore li abilita all'avvio.

• /etc/systemd/user Configurazione locale per tutti gli utenti ( systemctl --global enable userunit.service)
• /usr/lib/systemd/user Unità di pacchetti che sono stati installati a livello di sistema per tutti gli utenti
• /run/systemd/user Unità di runtime

Area grigia

Da un lato, il File Hierarchy Standard specifica che /etcè per le configurazioni locali che non eseguono i binari. D'altra parte specifica che /usr/local/"è destinato all'amministratore di sistema durante l'installazione del software in locale". Si potrebbe anche argomentare (se non solo a scopo di organizzazione) che tutti i file di unità di sistema dovrebbero andare sotto /usr/local/lib/systemd/system, ma questo è inteso per i file di unità che fanno parte del "software" e non da un gestore di pacchetti. Le corrispondenti unità utente di sistema che sono a livello di sistema potrebbero andare sotto /usr/local/lib/systemd/user.

/etc/systemd/systemè dove metti i tuoi script, pacman inserisce gli script dei pacchetti/usr/lib/systemd/system .

L'emissione systemctl enable foo.servicecrea collegamenti simbolici da /usra /etc. Vedere la sezione Percorso di carico dell'unità di man systemd.unit(5)per maggiori dettagli.

Ho scritto 3, uno per ntpd, uno per secondo, scheda Ethernet statica e uno per l'esecuzione p0f, l'identificatore del sistema operativo passivo. Li ho messi tutti dentro /etc/systemd/system. Sembra che potrei forse lasciare systemdgestire le cose NTP, ma non credo di voler fare affidamento su di esso così tanto.