Scribble at 2021-02-22 18:47:38 Last modified: 2021-02-22 19:16:34

一昨日から音声の配信サーバを担当する側の Raspberry Pi Zero W について、ひとまずスタンダードな組み合わせとして ALSA + PulseAudio を採用してセットアップの手順を・・・繰り返している。実際、これまでに10回近くは # apt remove --purge pulseaudio を繰り返しており、そのうちの２回は microSD カードを引き抜いて Raspberry Pi OS Lite そのものを入れ直していたりする。クリーン・インストールした状態からの手順を記録しないと、多くの人に参考となるドキュメントにはならないからだ。

そもそも、PulseAudio は公式サイトのドキュメントが手抜きと言っていいような分量で、man ページか、ArchLinux のサイトで掲載されているページを見たほうがいいくらいだ（Debian のサイトの解説も貧弱だ）。しかし、それらですら解説で想定しているパターンが限定的と言ってよく、pulseaudio のプロセスを公式では system-wide で動かすべきではないとされているにもかかわらず、サーバとして動かすのだからという理由で、誰も彼もが当然のように systemd に登録する手順を世界規模のコピペで共有しているありさまだ。しかし、それは仕方のないことだろうと思う。

実際、これまでに何度か pulseaudio のセットアップをやり直してみて分かるのは、たとえばユーザ・セッションのデーモンとしてプロセスを起動するように、一般ユーザ（典型は pi）の cron に "@reboot pulseaudio -D" などと書いても、実はすぐにプロセスが落ちてしまう。これでは危なくて常時稼働を前提にしたサーバのプロセスとして信用できない。しかるに system-wide で systemd に任せて起動してしまえと思いたくなるのもわかる。

この事情を更に説明すると、皮肉なことに、ユーザ・セッションのデーモンとして起動した pulseaudio のプロセスが落ちるのは、実は systemd の仕様だったりするから困るのだ。つまり、サーバとして起動したと思って Teraterm で ssh アクセスしていた僕自身が ssh のセッションを切ってログアウトすると、現在の systemd はログアウトしたユーザのユーザ・セッションを全て kill してしまうのである。よって、headless で Raspberry Pi OS Lite へアクセスしているユーザのプロセスは、そのユーザがアクセスしているあいだはセッションを維持するけれど、ログアウトしてしまえばセッションが切られてしまうため、ssh で入った状態も維持しなくてはいけない（ssh でアクセスしていないなら、headless で OS を起動しても pulseaudio を起動するべきユーザが存在しないので、そもそもプロセスが立ち上がらない）。こんなチキンレースをやっているわけにはいかないからこそ、たいていの人は system-wide なプロセスとして pulseaudio を起動するプランを選択せざるをえないのだ。

よって、上記のようなスレッドで説明されている手順は公式ドキュメントの典型的なコピペにすぎず、自分でサーバとしてセットアップしたり運用した経験のない陸水練の連中が書く回答である。そもそも system-wide での運用について欠点があるとは言っても、公式サイトに掲載されているのは "In most desktop use cases" であって、headless での運用（「サーバ」なのだから、こちらの方が標準的な環境だと思うのだが）にも当てはまるような欠点ではない。セキュリティについては気になるものの、そもそも pulseaudio を実行できるユーザがクラックされている時点で、無線 LAN に入られており、しかも Raspberry Pi OS のアカウントも奪われているのだから、論外だろう。