マウント後に/ dev / ptsを修正するにはどうすればよいですか？
私はこの質問と同じ間違いをしました： Debian chrootがホスト上のPTTYをブロックしています
「devpts」ファイルシステムをchroot内にマウントしましたが、urxvtでptysを作成できなくなりました。奇妙なことに、xtermはまだ可能です。/dev/ptsを再マウントしても、問題は修正されません。
再起動せずにシステムを通常どおりに動作させるにはどうすればよいですか？
@mikeservのコメントのおかげで、私はそれを復活させる方法を見つけました。
私はこれをLinux4.0.7でのみテストしたので、はるかに古いバージョンまたははるかに新しいバージョンでは機能しない可能性があります。
mount/dev/pts -o remount、gid = 5、mode = 620
devptsオプションを使用せずにchrootファイルシステムをnewinstanceにマウントすると、同じptyを含む/dev/ptsの同じ「インスタンス」がマウントされました。マニュアルページによると、gid引数を渡さないと、新しいptyが生成されたプロセスと同じgidで作成されます。どうやらこの（欠如した）マウントオプションはdevptsインスタンス全体に影響を与えるので、元の/dev/ptsはもはやptyをttyグループに再割り当てしていません。 xtermがそうではないのに、なぜurxvtがそのptyをそのグループに含める必要があるのか私はまだ知りません。
これに関するいくつかのメモ：
/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が機能しない）、このオプションを使用する場合はそれらを再起動する必要があります。