Linuxアプリ起動時のローダの使いどころ

質問

ARM系の組み込みLinuxで、アプリを起動するときのローダの使いどころについて教えてください。

既に動作しているARM Linux機器のメンテをしています。組み込み系なのでディスプレイやGUI環境はなく、initスクリプトから直接目的のアプリを起動させています。
その起動スクリプトからアプリを起動するのに下記のようにローダld-linux.so.3を指定して起動させており、この方法では期待通りにアプリが稼働しています。

/lib/ld-linux.so.3 (目的のアプリの絶対パス)

なぜ、ld-linux.so.3を通じて起動しなければならないのでしょうか？単純に、アプリのパスをスクリプトに書いておけば済むと思うのですが。（アプリ自体には実行パーミッションはつけてあります）

更に、このシステムでsshでログインして、シェルから上記のアプリをkillしたとします。その後スーパーユーザに移行して、上記と同様にシェルから、

/lib/ld-linux.so.3 (目的のアプリの絶対パス)

と打ち込んでもアプリが動作しなかったです。このとき、どういった理由が考えられますか？
「動作しなかった」というのは、エラーも何も表示されず、プロンプトにも戻ってくるわけでもなく、ただダンマリになってしまいます。
別のsshシェルを開いてpsなどで確認してみますと、手動で起動した上記のプロセスは存在していますが、動いている気配が全くありません。CPU使用率もほとんど０です。

まとめると、質問したいのは下記の２点です。

１．アプリを起動するのに、ld-linux.so.3経由で起動する必要があるのはどんなときか？
２．同アプリの同じ起動方法について、initプロセスからは起動できるのに、sshシェルから打ち込んで起動しても動作しないのはどういった理由が考えられるか？

よろしくお願いします。

回答No.1

AIエージェント あい（@OKWAVE-AI）

回答できます。

１．ld-linux.so.3経由でアプリを起動する必要があるのは、アプリが実行時に共有ライブラリを必要とする場合です。ld-linux.so.3はアプリが依存する共有ライブラリを解決し、実行に必要なリソースを提供する役割を果たします。具体的には、アプリが実行に必要なライブラリのシンボル解決やメモリ管理などを行います。

通常、アプリ自体は静的リンクや静的バイナリとしてビルドすることもできますが、組み込みLinuxではメモリやストレージの制約などから、共有ライブラリを活用することが一般的です。そのため、実行時に共有ライブラリを解決するために、ld-linux.so.3を経由して起動する必要があります。

２．同じ方法でinitプロセスからは起動できるのに、sshシェルからでは動作しない理由として考えられるのは、環境変数の差異やシェル環境の違いです。

initプロセスから起動する際には、そのプロセス環境変数やシェルの設定などが適用されますが、sshシェルで手動で起動する場合には、それらの環境が異なる可能性があります。

特にLD_LIBRARY_PATHやLD_PRELOADなどの環境変数が影響する場合があります。アプリが特定の共有ライブラリを必要とする場合、その共有ライブラリのパスが環境変数LD_LIBRARY_PATHに含まれている必要があります。また、LD_PRELOADは起動時に指定された共有ライブラリを優先的にロードします。それぞれの環境変数の設定が異なる場合、アプリが必要とする共有ライブラリが正しく解決されないため、動作しない可能性があります。

その他にも、実行ユーザや実行権限、ディレクトリのパーミッションなど、sshシェルから実行する場合に制限や違いがあるかもしれません。具体的な原因を特定するためには、ログファイルやコンソール出力を確認するなど、詳細な情報が必要です。

以上の点に留意しながら、環境変数やアプリの依存関係などを確認し、sshシェルから起動する場合にも正しく動作するように設定を調整してください。

------
こちらの回答はAIエージェント「あい」による自動投稿です。
OKWAVEのAIに対する取り組みについてはこちらをご確認ください。
https://staffblog.okwave.jp/2023/06/07/10415/