回答:
コメントでheemaylが指摘したように、manページが質問に回答します。ウェブから：
Wants =
Requires =の弱いバージョン。このオプションにリストされているユニットは、構成ユニットが起動している場合に起動されます。ただし、リストされたユニットが開始に失敗するか、トランザクションに追加できない場合、トランザクション全体の有効性に影響はありません。これは、あるユニットの起動を別のユニットの起動にフックする推奨方法です。
そして、Requires =：
他のユニットの要件依存関係を構成します。このユニットがアクティブになると、ここにリストされているユニットもアクティブになります。他のユニットのいずれかが非アクティブ化されるか、そのアクティブ化が失敗すると、このユニットは非アクティブ化されます。このオプションは複数回指定することも、1つのオプションで複数のスペースで区切られたユニットを指定することもできます。その場合、リストされているすべての名前の要件依存関係が作成されます。要件の依存関係は、サービスの開始または停止の順序に影響しないことに注意してください。これは、After =またはBefore =オプションで個別に構成する必要があります。ユニットfoo.serviceにRequires =で構成されたユニットbar.serviceが必要で、After =またはBefore =で順序付けが構成されていない場合、foo.serviceがアクティブになっている場合、両方のユニットが同時に遅延なく開始されます。しばしば、
この依存タイプは、このユニットの実行中に他のユニットが常にアクティブ状態である必要があることを意味しないことに注意してください。具体的には、条件チェック（ConditionPathExists =、ConditionPathExists =、…—以下を参照）に失敗しても、Requires =依存関係を持つユニットの開始ジョブが失敗することはありません。また、一部のユニットタイプはそれ自体で非アクティブ化される場合があります（たとえば、サービスプロセスが正常に終了することを決定したり、ユーザーがデバイスを取り外したりする場合）。BindsTo =依存タイプとAfter =を使用して、特定のユニットがアクティブ状態にならない限り、ユニットがアクティブ状態にならないようにします（以下を参照）。
サービスはmulti-user.targetに到達した場合にのみ開始され（そのターゲットに追加しようとするとどうなりますか？）、systemdはサービスの前にdisplay-manager.serviceを開始しようとします。場合は、表示-manager.serviceが何らかの理由で失敗した（本当にディスプレイマネージャ、使用必要がある場合に、あなたのサービスはまだ開始されますRequires=そのために）。ただし、multi-user.targetに到達しない場合、サービスは起動しません。
あなたのサービスは何ですか？キオスクシステムですか？直感的に、サービスをmulti-user.targetに追加して（起動時にサービスを開始する）、を介してdisplay-manager.serviceに厳密に依存させたいと思いますRequires=display-manager.service。しかし、それは今や単なる推測です。
サーバーの展開では、すべてのユーザーIDと自動マウントマップを含むLDAPを使用しています。ユーザーのホームディレクトリはNFSマウントされており、ユーザーは通常、ホームディレクトリの実行可能コードで@reboot cronjobsを作成します。キャッシュにもsssdを使用します。言うまでもなく、この構成が機能するために決定的なブート順序を提供できることに大きく依存しています。非常に簡潔なsystemd構成を開発し、「wants」セクションオプションと「requires」セクションオプションのあいまいなニュアンスを発見しました。
起動中にサービスに障害が発生し、サービスオプションとして「restart = always」が設定された「requires」に依存する別のサービスが存在する場合、その依存サービスは再起動しません。ただし、オプションとして「欲しい」場合は、期待どおりに依存サービスが再起動します。
man systemd.unit