私はこの質問のような間違いを犯しました。Debian chroot はホストから PTTY をブロックします。
chrootに "devpts"ファイルシステムをマウントしましたが、urxvtはptyを作成できません。奇妙なことに、xtermはまだ動作しています。 /dev/ptsを再マウントしても問題は解決しません。
再起動せずにシステムを再び正常に動作させるにはどうすればよいですか？
答え1
@mikeservさんのコメントのおかげで、復元方法を見つけました。
私はこれをLinux 4.0.7でのみテストしたので、以前のバージョンまたはそれ以降のバージョンでは動作しない可能性があります。
マウント /dev/pts -o 再マウント、gid=5、モード=620
このオプションを使用せずにファイルシステムをマウントすると、devpts同じ pty を含む同じ「インスタンス」がマウントされます。マニュアルページによると、引数を渡さないと、それを生成したプロセスと同じ gid を使用して新しい pty が生成されます。明らかに、この（欠落している）マウントオプションはインスタンス全体に影響を与えるため、元のインスタンスはptysをグループに再割り当てしなくなりました。 urxvt が pty がこのグループにあるべき理由はまだわかりません。しかし、xtermはそうではありません。chrootnewinstance/dev/ptsgiddevpts/dev/ptstty
これに関するいくつかの追加注意事項：
/dev/pts/ptmxモード000（root：root）と/dev/ptmxモード666（root：tty）は正常なようです。しかし、同じブロックデバイスを指しているので、設定は不要に見えますが、ptmxmode無害に見えます。- デフォルト
mode（600）は動作しているように見えますが、とにかくttyはモード620で生成されます。何かパターンが変わっているかもしれません。私のシステムが起動するとデフォルトはmode=620無視されるので、mode/dev/ptsの基本機能をよりよく復元するために、上記のコマンドラインに入れました。 - 設定しないでください
uid。セキュリティの問題や端末で生成されないのと同じ問題が発生する可能性があります。 - 追加は
newinstanceオプションですが、セキュリティが向上します。このオプションを使用すると、コンテナは/dev/ptsホストシステムで使用されないため、「実際」をマウントできません。これを使用する場合は、ptmxmode=666これが/dev/ptmxへのシンボリックリンクであることを確認する必要がありますpts/ptmx。新しいdevptsインスタンスをインストールすると、/dev/pts既存の端末が奇妙に動作する（gpg動作しないなど）可能性があるため、このオプションを使用する場合はその端末を再起動する必要があります。