システムランチャーとターミナルランチャーの違い

/etc/rc.localCLIを介さずにsystemctlを介してアクティブ化するときにsystemdを使用して実行する場合、これらのプログラムの違いは何ですか？

たとえば、私は最近Raspberry Piでhairport-syncを使用しました。最初は、sudo systemctlenabled hairport-syncを介して起動するようにhairport-syncを設定しました。

後で機能の1つを使用してshairport-syncスクリプトを事前に実行し、接続されたデバイスに公開しました。

驚くべきことに、スクリプトshairport-syncはkill arecordaplay

ところで、端末を介してスクリプトを実行すると、スクリプトが実行され終了しarecordますaplay。

自分自身をさらに混乱させるために、ターミナルを介して終了してshairport-sync開始し、何が起こっているのかを確認しました。これにより、デバイスが接続されシャットダウンされると、期待どおりにスクリプトがarecord実行されますaplay。そのため、修正でこれを無効にし、クイックshairport-sync修正で実行するように設定しましたsysmtectl。/etc/rc.localその後はreboot期待通りに働きました。

systemdこれにより、スタンドアロンで実行されるプログラムとCLIを介して実行されるプログラムの間にわずかな違いがあると信じていました。/etc/rc.local

なぜこれが起こるのですか？ランレベルが違うからですか？闇の魔法？

デバイスが接続されたときに実行されるスクリプトは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/sysloghairport-syncがCLIで最初に実行されたときにsystemd.whenとして実行されたか、エラーがない場合にのみ適用されます。shairport-sync/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。