Risposte:
Come ha sottolineato Heemayl nel commento, la pagina man risponde alla tua domanda. Dal web:
desidera =
Una versione più debole di Richiede =. Le unità elencate in questa opzione verranno avviate se l'unità di configurazione è. Tuttavia, se le unità elencate non si avviano o non possono essere aggiunte alla transazione, ciò non ha alcun impatto sulla validità della transazione nel suo insieme. Questo è il modo raccomandato per collegare l'avvio di un'unità all'avvio di un'altra unità.
E richiede =:
Configura le dipendenze dei requisiti da altre unità. Se questa unità viene attivata, verranno attivate anche le unità elencate qui. Se una delle altre unità viene disattivata o la sua attivazione non riesce, questa unità verrà disattivata. Questa opzione può essere specificata più di una volta oppure è possibile specificare più unità separate da spazio in un'opzione, nel qual caso verranno create le dipendenze dei requisiti per tutti i nomi elencati. Si noti che le dipendenze dei requisiti non influenzano l'ordine in cui i servizi vengono avviati o arrestati. Questo deve essere configurato in modo indipendente con le opzioni After = o Before =. Se un'unità foo.service richiede un'unità bar.service come configurato con Require = e nessun ordine è configurato con After = o Before =, allora entrambe le unità verranno avviate simultaneamente e senza alcun ritardo tra di loro se foo.service è attivato. Spesso,
Si noti che questo tipo di dipendenza non implica che l'altra unità deve essere sempre nello stato attivo quando questa unità è in esecuzione. In particolare: i controlli delle condizioni non riusciti (come ConditionPathExists =, ConditionPathExists =,… - vedi sotto) non causano il fallimento del processo di avvio di un'unità con una dipendenza Richiede = su di essa. Inoltre, alcuni tipi di unità possono disattivarsi da soli (ad esempio, un processo di servizio può decidere di uscire in modo pulito o un dispositivo potrebbe essere scollegato dall'utente), che non viene propagato alle unità che hanno una dipendenza Requisito =. Utilizzare il tipo di dipendenza BindsTo = insieme a After = per assicurarsi che un'unità non possa mai essere nello stato attivo senza un'altra unità specifica anche nello stato attivo (vedere di seguito).
Dalla pagina freedesktop.org
Il servizio verrà avviato solo se è stato raggiunto il multi-user.target (non so cosa succede se si tenta di aggiungerlo a quella destinazione?) E systemd proverà ad avviare display-manager.service prima del servizio . Se display-manager.service fallisce per qualsiasi motivo, il servizio verrà comunque avviato (quindi se hai davvero bisogno di display-manager, utilizzalo Requires=per quello). Se il multi-user.target non viene raggiunto, tuttavia, il servizio non verrà avviato.
Qual è il tuo servizio? È un sistema di chioschi? Intuitivamente suppongo che tu voglia aggiungere il tuo servizio a multi-user.target (quindi è lanciato all'avvio) e che dipenda strettamente dal servizio display-manager.service via Requires=display-manager.service. Ma ora è solo un'ipotesi selvaggia.
La nostra distribuzione di server utilizza LDAP contenente tutti gli ID utente e le mappe di montaggio automatico. Le home directory degli utenti sono montate su NFS e gli utenti di solito creano cronjobs @reboot con il codice eseguibile nelle loro home directory. Usiamo anche sssd per la cache. Inutile dire che ci affidiamo molto alla capacità di fornire un ordine di avvio deterministico affinché questa configurazione funzioni. Abbiamo sviluppato una configurazione di sistema molto sintetica e abbiamo scoperto un'oscura sfumatura tra le opzioni della sezione "vuole" e "richiede".
Se si verifica un errore di un servizio durante l'avvio e esiste un altro servizio dipendente da "richiede" su quel servizio con "riavvio = sempre" impostato come opzione di servizio, tale servizio dipendente non verrà riavviato. Se, tuttavia, si dispone di "desideri" come opzione, il servizio dipendente verrà riavviato, come previsto.
man systemd.unit