私は、vSphereでホストされているこのボックスubuntu 16.04ボックスを、過去半年間毎日毎日使用しています。 WindowsからPuTTY/kittyで接続しています。今日、私は この質問 のようなメッセージに迎えられました。
何が原因なのかわかりません。メッセージは次のとおりです。
_Authenticating with public key "imported-openssh-key"
Server refused to allocate pty
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
0 packages can be updated.
0 updates are security updates.
_
印刷時にフォーマットを保持しました。
この回答 問題は解決しますが、再起動するたびにコマンドを入力する必要があります。
_mount devpts /dev/pts -t devpts
_
link に示されているようにfstab行を追加しても、元の質問の回答の1つで指定されていても何も変更されないようです。
正直なところ、今までこのデバイスをマウントする必要がなかった理由がわかりませんが、突然機能しなくなり、このマウントが必要になりました。
手動で再起動するたびにこれをマウントする必要がないように、この問題を修正する適切な方法は何ですか?あなたが要求するかもしれないログまたは他の診断を提供して幸せです。
更新
したがって、最初はボックスを再構築することで問題に対処しましたが、今度はそれが再び発生し、私が管理している他のマシンでも発生し始めました。
フォローするには フィリッペの答え 。
gzip -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout init | grep devpts
を実行すると
_mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true
_
gzip -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout scripts/init-bottom/udev | grep move
を実行すると
_# move the /dev tmpfs to the rootfs
mount -n -o move /dev ${rootmnt}/dev
_
「デバッグ」スイッチを指定して実行すると、 この出力 が得られます。
問題の根本原因を見つけるために他にできることはありますか?
Sudo update-initramfs -c -k $(uname -r)
で再生成しても、再起動後に目に見える変化はありませんでした。
これは、devptsを手動でマウントする前後にmtabで確認できるものです。
_>Sudo cat /etc/mtab | grep devpts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
>Sudo mount devpts /dev/pts -t devpts
>Sudo cat /etc/mtab | grep devpts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
_
/ dev/ptsファイルシステムは通常、Ubuntuのinitrd(別名initramfs)によってマウントされます。
Initramfsは、カーネルの起動時にメモリにロードされる小さなファイルシステムであり、基本をセットアップし、実際のルートをマウントするために必要なカーネルドライバーをロードした後、システムを実際のルートファイルシステムに切り替えるようにセットアップします。
/ bootの下にあるinitrd.img- *という名前で、最後の部分がカーネルのバージョンと一致しています。
これは、xzで圧縮されたcpioアーカイブです。
次のコマンドを使用して、マウント時に最初に実行される「init」スクリプトの内部を確認できます。末尾の「grep」は、devptsをマウントする行を調べます。
$ xz -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout init | grep devpts
mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true
そのdevptsは実際にはinitramfsのルートにマウントされているため、後で切り替える前に実際のルートに移動する別の手順があります。あなたはここでそれを見ることができます:
$ xz -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout scripts/init-bottom/udev | grep move
# move the /dev tmpfs to the rootfs
mount -n -o move /dev ${rootmnt}/dev
Initrdのコンテンツ全体を抽出する場合は、次を使用できます。
# First go to an empty directory
$ mkdir -p /tmp/extract_initrd
$ cd /tmp/extract_initrd
$ xz -dc /boot/initrd.img-$(uname -r) | cpio -id
そして、その木を探索します...
Initramfsに問題があると思われる場合は、update-initramfs
コマンドを使用して、次のように再生成してみてください。
$ Sudo update-initramfs -c -k $(uname -r)
このコマンドの出力にエラーがないか注意してください。何か問題が発生している可能性があります。
別の可能性は、initrdでデバッグログを有効にすることです。これを行うには、カーネルコマンドラインに「デバッグ」を追加して再起動します。次に、システムの起動後にファイル/run/initramfs/initramfs.debugを確認します。このファイルには、initrdスクリプトによって出力されるメッセージが含まれています。 initramfsデバッグの詳細については こちら を参照してください。
「サーバーがptyの割り当てを拒否しました」というメッセージが表示されたときは、はるかに単純な問題でした。私のSSHサーバーの 'PermitTTY'オプションが 'no'に設定されていました。 (OpenSSHの最新バージョンでは、「yes」がデフォルトであるため、通常、その行はコメント化されています。手動で「no」に設定されていない限り、問題ありません。)
お気に入りのエディターを使用して、sshd_configファイルを再確認します。
Sudo nano /etc/ssh/sshd_config
「PermitTTY」行がないか、コメントアウトされているか、手動で「yes」に設定されていることを確認してから、SSHサーバーを再起動します。
Sudo service sshd restart
それで十分かもしれません。
https://serverfault.com/a/934030/33095 でも同様の問題がありました
権限は予想とは異なりましたが、次の方法で修正できました。
Sudo mount -o remount /dev/pts
Sudo grep devpts /proc/mounts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0