SystemdとTerminalの起動プログラムの違いは？

私は、このプログラム間の違いが何であるかについて興味があります。 systemctlで有効にした場合はsystemdで開始しましたが、/etc/rc.localで開始した場合はまたはCLIを介して。

たとえば、私は最近、ラズベリーパイにshairport-syncを使用していました。最初に、sudosystemctl対応のshairport-syncを使用してshairport-syncを開始するように設定しました。

その後、shairport-sync内の機能を使用しました接続するデバイスの前にスクリプトを実行し、デバイスに投稿します。

驚いたことに、shairport-syncによって実行されたときのスクリプト killしませんでした arecord またはaplay

ただし、ターミナルを介してスクリプトを実行すると、スクリプトが実行され、arecordが強制終了されました。およびaplay 。

さらに混乱させるために、私はshairport-syncを殺しましたターミナル経由で起動して、何が起こっているのかを確認しました。そうすると、デバイスが接続してarecordを強制終了したときに、スクリプトが期待どおりに機能しました。およびaplay 。そこで、修正としてshairport-syncを無効にしました sysmtectlで /etc/rc.localで実行するように設定しますクイックフィックスとして。 reboot後期待どおりに機能しました。

これにより、systemdの一部として実行されるプログラムにはいくつかの違いがあると私は信じています。および/etc/rc.localを介して起動したときに実行されるプログラムまたはCLI。

なぜこれが起こるのですか？これは実行レベルが異なるためですか？いくつかの黒魔術？

デバイスがshairport-syncに接続するときに実行されるスクリプト次のとおりです。shairportstart.sh

#!/bin/sh
/usr/bin/sudo /bin/pkill arecord
if [ $(date +%H) -ge "18" -o $(date +%H) -le "7" ]; then
        /usr/bin/amixer set Speaker 40%
else
        /usr/bin/amixer set Speaker 100%
fi
/home/pi/shScripts/shairportfade.sh&

exit 0

フェードスクリプトは次のとおりです。shairportfade.sh

#!/bin/sh
/usr/bin/amixer set Speaker 30-
for (( i=0; i<30; i++))
do  
    /usr/bin/amixer set Speaker 1+
done
exit 0

デバイスがshairport-syncに切断されたときに実行されるスクリプト次のとおりです。shairportend.sh

#!/bin/sh
/usr/bin/amixer set Speaker 70%
/usr/bin/arecord -D plughw:1 -f dat | /usr/bin/aplay -D plughw:1 -f dat&
exit 0

/var/log/syslogで次のエラーが見つかりました shairport-syncが最初にsystemdの一部として実行された場合のみ。 shairport-syncの場合 CLIまたは/etc/rc.localから実行されましたエラーはありませんでした。

Jan 24 00:38:45 raspberrypi shairport-sync[617]: sudo: no tty present and no askpass program specified

唯一の違いはshairport-syncの方法であることに注意してくださいデバイスがshairport-syncを接続または切断したときに最初に開始されます実行を継続します。

承認された回答：

「systemdでは物事の動作が異なるのはなぜですか？」のバリエーションよくある質問です。

systemdからではなくCLIから何かが実行されるときはいつでも、違いを説明する可能性のいくつかの広いカテゴリーがあります。

さまざまな環境変数 。 systemd man systemd.execで渡す環境変数を文書化します生成されたプロセスの環境変数のセクション。違いを自分で調べたい場合は、systemd-run /path/to/binaryを使用できます。、systemdサービスによって実行されるため、一時的なスコープでアプリを実行します。次のような出力が得られます：Running as unit: run-u160.service 。次に、journalctl -u run-u160.serviceを実行できます。出力を確認します。アプリを変更して、受け取った環境変数をダンプし、CLIの実行をsystemdの実行と比較します。アプリが便利に変更されていない場合は、systemd-run envを使用できます。渡される環境変数を確認し、結果のジャーナルログを確認します。 X11 GUIアプリを起動しようとしている場合は、DISPLAY 環境変数を設定する必要があります。その場合は、systemdの代わりにデスクトップ環境の「自動起動」機能を使用することを検討してください。
リソースの制限 。 man systemd.resource-controlを参照してくださいリソース消費を制限する可能性のある構成値の場合。 systemctl show your-unit-unit.serviceを使用します開始しようとしているサービスに影響を与える完全な構成値を確認します。
非対話型シェル 。あなたのbash CLI環境はインタラクティブログインシェルです。 .bashrcのようなソースファイルがありますそのsystemd していません。これらのスクリプトは、環境変数の設定に加えて、SSHエージェントを接続してSSHアクションにログインを必要としないなど、他の多くのことを実行できます。ログインシェルと非ログインシェルの違いも参照してください。
TTYなし 。インタラクティブセッションは、sudoなどの一部のプログラムが使用するTTYに接続されています。およびssh パスワードの入力を求めるときに期待します。 sudo：ttyが存在せず、askpassプログラムが指定されていない
相対パスと絶対パス 。シェルでの相対的なバイナリ動作ですが、man systemd.serviceに記載されています。、ExecStart=の最初の引数バイナリへの絶対パスである必要があります。
制限されたコマンドライン構文 。シェルCLIは多くのメタ文字をサポートしますが、systemd コマンドライン構文が非常に制限されています。必要に応じて、systemdを使用してシェル構文を複製できる場合があります。シェルを介してコマンドを明示的に実行する：ExecStart=/bin/bash -c '/my/bash $(syntax) >/goes-here.txt'

これは、システムがリソース制御を備えた一貫した環境でコードを実行する機能です。これは、ハードウェアを圧倒することなく、長期的に再現性のある安定した結果を得るのに役立ちます。

関連：このプロセスSTATは何を示していますか？