I already checked that the user has mesg y among other permissions, and whether they are logged by loginctl. I was unable to replicate this bug on Fedora, hence I suspect it has something to do with Rocky.
I run as root, and SELinux is disabled for all the tests below(sudo setenforce 0). Yet, I always get the below error:
[vtian@vbox ~]$ write vtian pts/0
write: vtian is not logged in on pts/0
[vtian@vbox ~]$ who | grep [p]ts/0
vtian pts/0 2025-06-24 17:55 (10.0.2.2)
If I write to vtian tty1 which is logged in server-side, there is no issues at all.
I have another question here which is answered, to make sure that it wasn’t an issue with my client gnome-terminal.
Prerequisites I have checked
- user is logged in
utmp(According towho,loginctl, andlast). - user tty is correct (
ttyreturnspts/0). - user can receive messages if writing directly to the fd
/dev/pts/0. - user is receiving messages (According to
who -Tandmesg). writehass+gpermission (setgid)
Write Version [Edit 1]
vtian@vbox ~]$ sudo rpm -qf $(which write)
util-linux-2.40.2-10.el10.x86_64
who and last and ls output [Edit 1]
[vtian@vbox ~]$ last | head -n 4
vtian pts/0 10.0.2.2 Mon Jun 23 16:18 still logged in
vtian tty1 Mon Jun 23 16:18 still logged in
reboot system boot 6.12.0-55.16.1.e Mon Jun 23 16:17 still running
vtian pts/0 10.0.2.2 Sat Jun 21 16:19 - 16:29 (00:09)
[vtian@vbox ~]$ last | head -n 5
vtian pts/0 10.0.2.2 Mon Jun 23 16:18 still logged in
vtian tty1 Mon Jun 23 16:18 still logged in
reboot system boot 6.12.0-55.16.1.e Mon Jun 23 16:17 still running
vtian pts/0 10.0.2.2 Sat Jun 21 16:19 - 16:29 (00:09)
vtian tty1 Sat Jun 21 16:18 - 16:29 (00:11)
[vtian@vbox ~]$ who -aT
system boot 2025-06-23 16:17
vtian + tty1 2025-06-23 16:18 00:01 4299
run-level 3 2025-06-23 16:17
vtian + pts/0 2025-06-23 16:18 . 4903 (10.0.2.2)
pts/1 2025-06-23 16:18 4939 id=ts/1 term=0 exit=0
[vtian@vbox ~]$ sudo ls -l $(which write)
-rwxr-sr-x. 1 root tty 24152 Feb 13 08:00 /usr/bin/write
Disk Mount Status [Edit 1]
My disk is using LVM. None of the LVs are mounted with nosuid. The only mounts with nosuid are /proc, as well as some stuff in /dev, /sys, and /run.
loginctl output [Edit 2]
I have just found out something really strange and reproducible.
Output for loginctl and sudo loginctl on vtian tty1, and loginctl on vtian pts/0 given the condition stated below.
[vtian@vbox ~]$ loginctl
SESSION UID USER SEAT LEADER CLASS TTY IDLE SINCE
2 1000 vtian - 3697 manager - no -
3 1000 vtian seat0 3149 user tty1 no -
6 1000 vtian - 3960 user pts/0 no -
3 sessions listed.
Output for sudo loginctl on pts/0
[vtian@vbox ~]$ sudo loginctl
[sudo] password for vtian:
SESSION UID USER SEAT LEADER CLASS TTY IDLE SINCE
2 1000 vtian - 3697 manager - no -
3 1000 vtian seat0 3149 user tty1 no -
6 1000 vtian - 3960 user - no -
3 sessions listed.
After I run sudo loginctl from vtian pts/0, vtian pts/0 is gone from logind for the rest of the session! If I run loginctl or sudo loginctl from vtian tty, I continue to get the above output! The only way to fix it is by restarting the ssh session.
Other Outputs [Edit 2]
vtian@vbox ~]$ sudo grep -e @include -e pam_systemd /etc/pam.d/{sshd,common*}
grep: /etc/pam.d/common*: No such file or directory
PAM Systemd Output [Edit 3]
[root@vbox vtian]# grep -r pam_systemd /etc/pam*
/etc/pam.d/runuser-l:-session optional pam_systemd.so
uname and distro info [Edit 4]
[root@vbox vtian]# uname -a
Linux vbox 6.12.0-55.16.1.el10_0.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Jun 10 18:27:04 UTC 2025 x86_64 GNU/Linux
[root@vbox vtian]# cat /etc/os-release
NAME="Rocky Linux"
VERSION="10.0 (Red Quartz)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="10.0"
PLATFORM_ID="platform:el10"
PRETTY_NAME="Rocky Linux 10.0 (Red Quartz)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:10::baseos"
HOME_URL="https://rockylinux.org/"
VENDOR_NAME="RESF"
VENDOR_URL="https://resf.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2035-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-10"
ROCKY_SUPPORT_PRODUCT_VERSION="10.0"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="10.0"
strace [Edit 5]
I don’t know how to interpret the strace data, but it looks to me like write does successfully iterate the vtian pts/0 session, but it seems to disregard it as not belonging to vtian pts/0
[root@vbox vtian]# strace -o /tmp/tracefile write vtian pts/0
write: vtian is not logged in on pts/0
[root@vbox vtian]# grep '/run/systemd/sessions/' /tmp/tracefile
openat(AT_FDCWD, "/run/systemd/sessions/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/run/systemd/sessions/1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/7", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/run/systemd/sessions/7", O_RDONLY|O_CLOEXEC) = 3
[root@vbox vtian]# loginctl list-sessions
SESSION UID USER SEAT LEADER CLASS TTY IDLE SINCE
1 0 root seat0 1249 user-early tty1 no -
2 0 root - 1799 manager-early - no -
6 1000 vtian - 2033 user pts/0 no -
7 1000 vtian - 2041 manager - no -
I know that this is a failed strace, as if it were successful, there would be an instruction like this after openat(AT_..., ../sessions/7" ...), as this is what it looks like when writing successfully to root tty1
openat(AT_FDCWD, "/run/systemd/sessions/1", O_RDONLY|O_CLOEXEC) = 3
...
newfstatat(AT_FDCWD, "/dev/tty1", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x4, 0x1), ...}, 0) = 0
...
openat(AT_FDCWD, "/dev/tty1", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
...
In addition, I don’t really know why /dev/pts/0 is invoked here when i’m writing to /dev/tty1
execve("/usr/bin/write", ["write", "root", "/dev/tty1"], 0x7ffc4f216350 /* 30 vars */) = 0
...
ioctl(0, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
ioctl(0, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
ioctl(0, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
newfstatat(AT_FDCWD, "/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}, 0) = 0
newfstatat(AT_FDCWD, "/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}, 0) = 0
getuid() = 0
getuid() = 0
...
I copied over all my outputs from this post I made which was updated over the course of weeks:
https://unix.stackexchange.com/questions/797237/unable-to-write-to-client-over-ssh