chroot内でsystemdサービスを開始する
Initスクリプト（またはopenrc）を使えば、私はいつも別のインストールルートからサービスを実行することができます。
しかしchroot /somepath/to_root /usr/bin/systemctl start someserviceを実行すると、次のようになります。
Running in chroot, ignoring request.
Systemdにサービスの実行を強制する方法はありますか？
更新：
私のホストシステムがinitスクリプトやopenrcを走らせると言うのを忘れていましたが、決してsystemdしていません。
数年後、ほとんどのSystemdの実際的な問題に対する解決策は1つしかないことを認めなければなりません。エラーはSystemd自体であるため
UpstartやOpenrcのようなものに直面したことのない問題があったので、Systemdには本当にうんざりしています。
- Cgroupsのサポートを必要とするカーネルの強制（オプションにする代わりに、構成ファイル内でデフォルトで有効化）RAMが24Mbのみの組み込みシステムでもおよび書き込み可能なストレージなし。
- モジュラーであるという主張にもかかわらず、実行時に依存性の地獄はそれを強力な神のオブジェクトにします：単一のreiser4 rootfsでブートしたいですか？多くのプログラムが
systemd-udevdを必要とするため、これは不可能です。systemd-initを必要とするsystemd-bootパッケージは、grub2と同時にインストールすることも、reiser4パーティションからカーネルイメージを読み取ることもできません。 - Bluetoothダイヤルアップ経由でインターネットに接続したいですか？ samsung Java me電話で動作しない場合は、
networkdにより、以前は手動で動作していたスクリプトとコマンドラインソフトウェアを実行できません。 - 最大の問題は、独自のLinuxディストリビューションを構築および保守する場合です。systemdinitモジュール自体には非常に多くの依存関係があるため、異なるインストールパッケージを使用して他のinitシステムを選択することはできません。
- システムでchrootできない場合、またはlibdb4.8からアップグレードした場合（少なくとも、最悪の場合、Microsoftはxml形式のログファイルを持っています）、ログを表示するには幸運です。
唯一のソリューション：
Systemdは問題を解決するために必要以上に複雑です：ossv4の代わりにalsaのようなしたがって、systemdを使用するものがある場合は、すべてのデータを消去してください。
dd if=/dev/urandom of=/dev/dm−0 bs=1M
openrcを使用したGentooのようなSysV Initの問題を解決しながら、まったく使用しないものをインストールします。
私の質問についてsystemdはWindows®レジストリのようなものを作成します：その一部がめちゃくちゃになったら、それは終わりです。
Systemdのディストリビューション（Arch Linux、OpenSUSE、Fedora）でよく知られている問題。
Systemdはsysvinitに代わるもので、これに対して1つの大きな利点があります。 sysvinitでは、サービスの開始を要求すると、スクリプトを呼び出す人の実行コンテキストを継承します。これには、環境変数、ulimitsなどが含まれます。 Systemdはこれとは逆にデーモンを通知することでこれを改善します。デーモンは、はっきりと定義された健全な一定の環境でサービスを開始します。もちろん、サービスのパフォーマンスは予測がはるかに簡単です。
これは、chroot内からsystemctlを呼び出すときに、chroot内にいることが無関係であることを意味します。継承される環境は、現在の環境ではなく、依然としてPID 1の環境です。しかし、これはさらに悪いことに、通信ソケットは/ run/systemdの中に置かれているので、chrootのプロセスはinitシステムと通信することすらできません。
それでは、どのようにしてsystemdディストリビューションでchroot'ingをするのですか？
あなたがしたいのがLinuxコンテナだけであれば、 このArch Wikiページ で30秒以内にLinuxコンテナを設定する方法がわかります。
systemd-nspawnに感謝します。代わりにあなたが本当にchroot環境が欲しいなら、 この美しくて明瞭なWebページ は二つの実用的な解決策をあなたに提供するでしょう（二番目のものはの修正版です）。 1）で提供されたもの.
systemdは "services"を無視するだけなので、デーモンコマンドを手動で実行するだけです。
だから代わりに
service sshd start
私が使う
/usr/sbin/sshd -D &
いいえ。サービスはsystemct（直接起動要求のみを送信）ではなくsystemd（pid 1）によって実行されます。また、systemdはchrootの外部で実行されるため、サービスも実行されます。
技術的にはこれを実装することは可能かもしれませんが（systemctlをどうにかしてそのルートをsystemdに渡すことによって）、フルコンテナ（systemd-nspawn /somepath/to_root）を作成するためのツールがすでにあるので起こりにくいです。あなたはいつでも メーリングリスト に連絡することができます。
かつてchrootのネットワーク設定を使用してレスキューモードでネットワークを立ち上げようとしたこの問題に直面しました。最後にこれは私のために働く：
service --skip-redirect <service> restart
または
SYSTEMCTL_SKIP_REDIRECT=_ /etc/init.d/<service> restart
ソケットアクティベーションを使用してinetdスタイルのサービスを起動する場合は、inetdスタイルの起動ターゲットとしてchrootとバイナリの両方を指定した設定ファイルを使用して、stunnelを起動することを検討してください。
SELINUXの問題があるかもしれないことに注意してください。 Oracle Linux 7.1システムでは、stunnelが読み込む必要があるすべてのファイルに対して "chcon -v --type = stunnel_etc_t"を実行する必要がありました。
ソケットのクライアント側でTLS暗号化を使用する必要があります（つまり、設定に "client = yes"を含む別のスタネル）。これについてもっと詳しく知りたいのであれば教えてください。