After=multi-user.target やその他のシステムサービスで動作しない

systemdが解決しようとするいくつかの競合を定義してWantedBy=multi-user.target追加しました。After=multi-user.targetこの回答の下でより大きな説明/実験を見ることができます。

代わりにサービスが早すぎる場合は、サービスが失敗する理由を見つけてください。実行する代わりにサービス/ターゲットをAfter=multi-user.target実行してください。After=

After=network.target私の考えでは、唯一の問題がネットワークであれば追加します。

ユーザーログインが必要な場合はバスを使用してください--user。

グラフィックセッションが必要な場合は、WantedBy=graphical.targetシステムバスまたはWantedBy=graphical-session.targetユーザーバスを検討してください。

---

使用すると関係をWantedBy=multi-user.target結びます。multi-user.targetWants=updatecontinue.service

これはただ始まるとupdatecontinue.service始まるという意味です。起動に失敗しmulti-user.targetてもupdatecontinue.service問題はありませんmulti-user.target。

updatecontinue.serviceその後、関係を提供しますRequires=multi-user.target。これは重大な紛争です。 （起動するRequires=とWants=これ、それも始まります）。例外：それデバイスをアクティブにできません。これデバイスが起動しません。

したがって、実際には互いに起動する2つのデバイスしかありませんが、これはおそらく望むものではありません。Requires=明確にするために依存関係を削除します。

---

Before/関係は機能します。以下はAfter/なしで対話する2つのサービスの例です。BeforeAfter

$ systemctl --user cat {early,late}.service
# /home/stew/.config/systemd/user/early.service
[Unit]
Wants=late.service

[Service]
ExecStartPre=sleep 2
ExecStart=sleep 20

# /home/stew/.config/systemd/user/late.service
[Service]
ExecStart=sleep 5

$ systemctl --user start early
$ journalctl --user --since "2 minutes ago" --no-hostname
Mar 08 15:54:42 systemd[1064]: Starting early.service...
Mar 08 15:54:42 systemd[1064]: Started late.service.
Mar 08 15:54:44 systemd[1064]: Started early.service.

同時にサービスが開始されることを確認できます。

late.serviceそれでは関係を築きましょうAfter=early.service。

$ systemctl --user cat {early,late}.service
# /home/stew/.config/systemd/user/early.service
[Unit]
Wants=late.service
[Service]
ExecStartPre=sleep 2
ExecStart=sleep 20

# /home/stew/.config/systemd/user/late.service
[Unit]
After=early.service
[Service]
ExecStart=sleep 5

$ systemctl --user start early
$ journalctl --user --since "2 minutes ago" --no-hostname
Mar 08 16:01:09 systemd[1064]: Starting early.service...
Mar 08 16:01:11 systemd[1064]: Started early.service.
Mar 08 16:01:11 systemd[1064]: Started late.service.

この場合、完了がlate.service始まったことがわかります（スタンバイセルになります）。early.serviceExecStartPreactive (running)

---

サービスとは異なり、ターゲットは「開始済み」状態に移行しません。代わりに、彼らは「達成」された。 andを使って同じことを試してみましょうearly.target。late.serviceしかし、late.service始めるのに少し時間がかかります。

$ systemctl --user cat early.target late.service
# /home/stew/.config/systemd/user/early.target
[Unit]
Wants=late.service

# /home/stew/.config/systemd/user/late.service
[Service]
ExecStartPre=sleep 2
ExecStart=sleep 5

$ systemctl --user start early.target
$ journalctl --user --since "2 minutes ago" --no-hostname
Mar 08 16:07:27 systemd[1064]: Starting late.service...
Mar 08 16:07:29 systemd[1064]: Started late.service.
Mar 08 16:07:29 systemd[1064]: Reached target early.target.

early.target「到着」に2秒かかることがわかります。これは、すべての目標の「Wants =」が「アクティブ化」ステップを完了し、「アクティブ（実行中）」状態に入ったときにのみ、ターゲットが「達成」されることを意味します。

これを知ることで、After=foo.targetaとの混合がWantedBy=foo.targetやや矛盾する理由がわかります。 foo.target到着前に始めるのを待っています。その間は、foo.target始める前にあなたに連絡したいと思います。

できるだけ遅くサービスを提供しようとしています。

するAfter=default.target

基本ターゲット設定した値と同じですsystemctl set-default。

SysVランレベルとそのsystemdターゲットの完全なリストは次のとおりです。

0    runlevel0.target, poweroff.target     {Shut down and power off the system.}
1    runlevel1.target, rescue.target       {Set up a rescue shell.}
2    runlevel2.target, multi-user.target   {Set up a non-graphical multi-user system.}
3    runlevel3.target, multi-user.target   {Set up a non-graphical multi-user system.}
4    runlevel4.target, multi-user.target   {Set up a non-graphical multi-user system.}
5    runlevel5.target, graphical.target    {Set up a graphical multi-user system.}
6    runlevel6.target, reboot.target       {Shut down and reboot the system.} 

基本的に完了したsystemctl set-default graphical.targetすべて。現在設定されている内容を確認systemctl set-default multi-user.targetできます。systemctl get-default

手動で起動すると動作するサービスがありますが、起動時に起動しません。

ExecStartExecStartで定義されたスクリプトを手動で実行すると機能しますが、システムサービスのコンテキストでは実行されないように、サービスファイルの構文またはそれに対応する構文を混乱させることは簡単です。本当にテストとデバッグが必要です。 「タイミング」の問題ではないようです。まず、手動で実行されていることを確認するなどの簡単な操作を実行してください/usr/bin/echo hello > /testfile。実行されてもシステムサービスで自動的に実行されない場合、これは時間の問題ではありません。その後、操作が停止するまで一度に1段階ずつ調整またはBefore調整するアクションを実行します。Requires

私のadministration.serviceファイルは/etc/systemd/system/次の場所にあります。

#!/bin/bash

[Unit]
Description=administration
After=default.target

[Service]
Type=idle
ExecStart=/root/scripts/administration.sh
TimeoutStartSec=0

[Install]
WantedBy=default.target

私の/root/scripts/administration.shファイルの一番上にroot.root with-rwx------ #!/bin/bash` があります。最初の行を混乱させると、サービスは実行されません。and has

systemctl list-unit-files | grep administration表示する内容を必ず確認してください。有効 {必要に応じて構文を調整してください}。

systemctl daemon-reloadadministration.serviceファイルが存在するが実行時に表示されない場合systemctl list-unit-files

/etc/systemd/system/ このカスタムサービスを作成するのに適した場所であれば、他の人が投稿するようにします。私が知っているのは、サービスがルート所有の場合は私に効果があり、基本的に管理者の場合は言葉になります。

昼寝をしながらコーディングしようとするのは良い考えではありません。問題は、After=その[Unit]部分ではなく、その[Service]部分にあるのが愚かであることです！