Failed to open PTY: No Such Device

[contactopublico]

After using chroot....

sudo mount /dev/sda2 /media/mount2
sudo mount --rbind /dev /media/mount2/dev
sudo mount --bind /proc /media/mount2/proc
sudo mount --bind /sys /media/mount2/sys ;
sudo mount --bind /run /media/mount2/run
sudo chroot /media/mount2

and after unmounting the target volume subsequent launching of terminal fails with the following message:

Failed to open PTY: No Such Device

Is there a way to program/bash script to test for PTY and regenerate/recreate PTY device; alternatively to manually recreate PTY from terminal, or is the only recourse to reboot?

[sublogic]

So the problem occurs after you exit the chroot ?

What does mount | grep pts say ?

Is there a /dev/pts directory at this point ? Is there a /dev/pts/ptmx in it ?

If not, maybe (not tested)

[contactopublico]

The issue occurs after the chroot volume target is unmounted, but not immediately upon cloing the terminal window.

Launching a terminal session:

There was an error creating the child process for this terminal
Failed to open PTY: No such device

There is a /dev/pts directory with no contents.

Can not run 'mount | grep pts' due to terminal error message when launching terminal.
Error message with blinking cursor.

Can not run 'mount -t devpts devpts /dev/pts' due to error message when launching terminal.
Blinking cursor, terminal window not responive to keyboard input.

[grknight]

[kimchi_sg]

[contactopublico]

The situation occurs with multiple chroot sessrions accessing target volumes.

Whan unmount a target choot volume, previously a message would appear in terminal window indicating 'out of PTY' (before using rbind).

Neverless when the chroot terminals are closed, and as long as I do not umount one of the target volumes the issue does not appear, and I can open and use additroinal terminal windows.

However, as soon as I unmount just one of the target volumes the terminal error appears and terminal no longer accepts nor executes keyboad commands, only a blinking cursor with an errror message as previously indicated.

I noticed on a fresh reboot that there were only three items in /dev/pts, characher devices and ptmx.

Is the solution to generate additional character devices for each terminal chroot session?

Thank yoiu for your replies.

[Hu]

This sounds to me like you are somehow unmounting the host's /dev/pts when you try to unmount the chroot's /dev/pts. If so, then the solution is not to unmount the host's /dev/pts. Please show us exactly how you produce this scenario. Also show the output of findmnt -o+PROPAGATION immediately before you unmount the chroot's bind mounts.

[contactopublico]

Chroot is initiated from terminal, Chroot target volumes are mounted to designated mount poinrts.

Hu, Administrator from prior commenrt>>This sounds to me like you are somehow unmounting the host's /dev/pts when you try to unmount the chroot's /dev/pts. If so, then the solution is not to unmount the host's /dev/pts.

Exactly, the host /dev/pts is automatically unmounting when chroot /dev/pts volume is unmounted. Why is the host /dev/pts not retained?

Can the host /dev/pts be regenerated from terminal?

findmnt -o+PROPAGATION

TARGET SOURCE FSTYPE OPTIONS PROPAGATION
/ /dev/sda3
│ ext2 rw,relatime shared
├─/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime shared
│ ├─/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegat shared
│ ├─/sys/firmware/efi/efivars
│ │ efivarfs
│ │ efivarfs rw,nosuid,nodev,noexec,relatime shared
│ ├─/sys/kernel/debug debugfs debugfs rw,nosuid,nodev,noexec,relatime shared
│ ├─/sys/kernel/tracing tracefs tracefs rw,nosuid,nodev,noexec,relatime shared
│ └─/sys/fs/fuse/connections fusectl fusectl rw,nosuid,nodev,noexec,relatime shared
├─/proc proc proc rw,nosuid,nodev,noexec,relatime shared
│ └─/proc/sys/fs/binfmt_misc systemd-1
│ autofs rw,relatime,fd=33,pgrp=1,timeout=0,minpro shared
├─/dev udev devtmpfs rw,nosuid,relatime,size=6055360k,nr_inode shared
│ ├─/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620, shared
│ ├─/dev/shm tmpfs tmpfs rw,nosuid,nodev shared
│ ├─/dev/hugepages hugetlbfs
│ │ hugetlbfs rw,nosuid,nodev,relatime,pagesize=2M shared
│ └─/dev/mqueue mqueue mqueue rw,nosuid,nodev,noexec,relatime shared
├─/run tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size=1214 shared
│ ├─/run/credentials/systemd-journald.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/user/1000 tmpfs tmpfs rw,nosuid,nodev,relatime,size=1214100k,nr shared
│ ├─/run/credentials/systemd-tmpfiles-setup-dev-early.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-sysctl.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-udev-load-credentials.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-tmpfiles-setup-dev.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-tmpfiles-setup.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-resolved.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-networkd.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ ├─/run/credentials/systemd-vconsole-setup.service
│ │ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
│ └─/run/credentials/getty@tty1.service
│ tmpfs tmpfs ro,nosuid,nodev,noexec,relatime,nosymfoll shared
├─/tmp tmpfs tmpfs rw,nosuid,nodev,size=6070516k,nr_inodes=1 shared
├─/media/mount4 /dev/sda4
│ │ ext2 rw,relatime shared
│ ├─/media/loop4/dev udev devtmpfs rw,nosuid,relatime,size=6055360k,nr_inode shared
│ │ ├─/media/loop4/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620, shared
│ │ ├─/media/loop4/dev/shm tmpfs tmpfs rw,nosuid,nodev shared
│ │ ├─/media/loop4/dev/hugepages
│ │ │ hugetlbfs
│ │ │ hugetlbfs rw,nosuid,nodev,relatime,pagesize=2M shared
│ │ └─/media/loop4/dev/mqueue
│ │ mqueue mqueue rw,nosuid,nodev,noexec,relatime shared
│ ├─/media/loop4/proc proc proc rw,nosuid,nodev,noexec,relatime shared
│ ├─/media/loop4/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime shared
│ └─/media/loop4/run tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size=1214 shared
├─/media/mount5 /dev/sda5
│ │ ext2 rw,relatime shared
│ ├─/media/loop5/dev udev devtmpfs rw,nosuid,relatime,size=6055360k,nr_inode shared
│ ├─/media/loop5/proc proc proc rw,nosuid,nodev,noexec,relatime shared
│ ├─/media/loop5/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime shared
│ └─/media/loop5/run tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size=1214 shared
└─/media/archive /dev/sda2
fuseblk rw,nosuid,nodev,relatime,user_id=0,group_ shared

[pingtoo]

contactopublico,

[Hu]

[contactopublico]

Hu, Administrator wrote:

"Please show us exactly how you produce this scenario."

In response to detailing exactly how chroot is invoked, you would not be able to exactly reproduce the sequence on your system unless you designate the same mount points, and utilized a volume at sda4 into which a chroot could be executed.

Chroot for a selected volume is invoked via alias from terminal within the host environment, executing a bash script to effect the designaged commands, using designated mount points.

Such a script would typically contain these types of commands:

sudo mount /dev/sda4 /media/mount4 ;
sudo mount --rbind /dev /media/mount4/dev ;
sudo mount --bind /proc /media/mount4/proc ;
sudo mount --bind /sys /media/mount4/sys ;
sudo mount --bind /run /media/mount4/run
sudo chroot /media/mount4

You would be able to replicate those commans line by line at the command prompt, the same as done by bash script, if you created the mount point and had a volume to chroot into at sda4.

After complettion of the desired tasks in chroot the terminal window is closed and the volume unmounted in file manager.

Until a chrooted volume is unmounted the host system /dev/pts remains, but once a chroot volume is unmounted the host /dev/pts terminates and it is no longer possible to utilize terminal, unless rebooted, as previously explained.

/dev/pts can not be regenerated from a non-runctioning terminal.

What I am seeking, is a method of unmounting a chroot volume and preserving the host /dev/pts/ and PTY for the host terminal.

It is not enough to suggest to not umount chroot volumes as the chroot session should not continue indefinately, nor would it be acceptable to reboot a server after every chroot session.

Therefore, in light of your previous post:

Something - probably systemd, since it is known to cause this problem - has made many of your mounts shared (overriding the kernel default of private), in the shared subtree sense. This causes mounts to propagate forward and backward. As described in Documentation/filesystems/sharedsubtree.rst, mounts in one bind are propagated to the other, as are unmounts, so unmounting in the chroot also unmounts outside it.

Consequently, is this a systemd bug that should to be reported to the maintainer?

[contactopublico]

Pingtoo wrote:

Actually this is common mistake when doing chroot, especially in scripted fashion

Did you after exist chroot, did umount /dev for example to match the mount /dev prior to chroot?

I am not certain what specific steps you refer to in your post.

If you are referencing a specific sequence of steps to unmount the chroot volume (including /dev) that will preserve the host /dev/pts and PTY for the host system terminal, please specify exactly what syntax and order of commands to utilize from the host terminal.

Thank you.

[pingtoo]

contactopublico,

I am refer to after you exist chroot, did you execute some umount commands? and could one of them be umount /dev?

I recently just finish a chroot script, did the umount, but not realize I was outside of chroot, so the execution unmounted the outer stuff. luck me I was doing inside a container, so no harms done.

[contactopublico]

Pingtoo wrote:

I am refer to after you exist chroot, did you execute some umount commands? and could one of them be umount /dev?

Once done with chroot operations, I typically close the terminal window, and this does not unmount host /dev/pts.

Once the chroot volume is umounted via clicking in file manager, /dev/pts is umounted on the host system.

I am not using a command line to unmount chroot volumes because after the first umount PTY is lost and terminal no longer functions.

Is this a systemd bug that should be reported to the maintainer?

[grknight]

[contactopublico]

Thank you grnight for your reply.

Planning to test the "--make-slave" parameter to verify if this resolves the issue.

[pingtoo]

[Hu]

[contactopublico]

For the benefit of any future readers inquiring regarding this issue, and In order to address any remaining questions that have not previously been answered with sufficient granularity:

After closing the chroot terminal, unmouning of the chroot volume is done via caja file manager by simply clicking the umount icon visible next to the chroot volume in the left pane of he file manager.

Previously, after the chroot unmount any newly launched mate-terminal session would display a red message band in the mate-terminal window indicating...

[grknight]