Console not responding if kills Xorg started from it

Russian_Man · Apr 19, 2023

Hi All!

I have such situation, my Son works on my FreeBSD PC after school in such way:
He logins with his own user/password on console, after that startx and use games. And if I remotely throught ssh kills his Xorg, console becomes unresponsible. It incorrectly reacts on a keyboard (prints various symbols and escape sequences) and not reacts on <CR>, Alt+Fn ...
So only way to works - remotely restart slim to switch on X, and after that I can switch to any console, but failed console still becomes broken. If I switch to it, againg only solution - restart slim remotely.

How can I fix console after such situation?
I'm try to remotely restart:
/etc/rc.d/syscons restart
but that not helps.

The more sharp question: How to repair unresponsible console if I can login remotely through ssh?

zirias@ · Apr 19, 2023

SomeRussianDude said:
And if I remotely throught ssh kills his Xorg, console becomes unresponsible.

This sounds kind of rude, maybe there's a better way to interact with your son?

*scnr*

SomeRussianDude said:
It incorrectly reacts on a keyboard (prints various symbols and escape sequences) and not reacts on <CR>, Alt+Fn ...

This however sounds like it doesn't even switch back to the virtual console from which X was started?

SomeRussianDude said:
The more sharp question: How to repair unresponsible console if I can login remotely through ssh?

Although I have no idea, have you tried reset(1)? E.g. something like reset xterm >/dev/ttyv1?

Russian_Man · Apr 19, 2023

zirias@ said:
This sounds kind of rude, maybe there's a better way to interact with your son? *scnr*

Maybe, but since I don't want to give him games more than 30min and I'm on work - I have to use such way. I'm just too lazy to come up with something yet

zirias@ said:
Although I have no idea, have you tried reset(1)? E.g. something like reset xterm >/dev/ttyv1?

reset - I know and use, but when I on a terminal which have issues, don't think about redirecting. Try it and write here about results!

Thanks!

Russian_Man · Apr 20, 2023

zirias@ said:
Although I have no idea, have you tried reset(1)? E.g. something like reset xterm >/dev/ttyv1?

Sadly, reset not helps. Maybe there is any other solution? Because in a mature system like FreeBSD must not be situation, when console unrecoverable hangs after incorrect (why incorrect?) X kill.
Maybe photo of screen help to diagnose problem.
uname -a

Code:

FreeBSD BSD-RYZEN 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 GENERIC amd64

kldstat

Code:

Id Refs Address                Size Name
 1  150 0xffffffff80200000  1f30470 kernel
 2    1 0xffffffff82132000     a158 cryptodev.ko
 3    1 0xffffffff8213d000   5b93a8 zfs.ko
 4    1 0xffffffff826f7000    ff650 if_re.ko
 5    1 0xffffffff827f7000     a320 ng_ubt.ko
 6    3 0xffffffff82802000    12e90 ng_hci.ko
 7    3 0xffffffff82815000     4250 ng_bluetooth.ko
 8    6 0xffffffff8281a000    16d68 netgraph.ko
 9    1 0xffffffff82831000     6cf8 uplcom.ko
10    2 0xffffffff82838000     a7a8 ucom.ko
11    1 0xffffffff82e10000     3530 fdescfs.ko
12    1 0xffffffff82e14000     639c linprocfs.ko
13    4 0xffffffff82e1b000    10ab0 linux_common.ko
14    1 0xffffffff82e2c000     3284 linsysfs.ko
15    3 0xffffffff82e30000    590f0 vboxdrv.ko
16    2 0xffffffff82e8a000     4240 vboxnetflt.ko
17    1 0xffffffff82e8f000     31c8 ng_ether.ko
18    1 0xffffffff82e93000     55e0 vboxnetadp.ko
19    1 0xffffffff83000000   418220 amdgpu.ko
20    2 0xffffffff82e99000    739e0 drm.ko
21    3 0xffffffff82f0d000     5220 linuxkpi_gplv2.ko
22    4 0xffffffff82f13000     62d8 dmabuf.ko
23    1 0xffffffff82f1a000     c758 ttm.ko
24    1 0xffffffff82f27000     64d8 amdgpu_green_sardine_sdma_bin.ko
25    1 0xffffffff82f2e000    2c2d8 amdgpu_green_sardine_asd_bin.ko
26    1 0xffffffff82f5b000    16fd8 amdgpu_green_sardine_pfp_bin.ko
27    1 0xffffffff82f72000    12fd8 amdgpu_green_sardine_me_bin.ko
28    1 0xffffffff82f85000     afd8 amdgpu_green_sardine_ce_bin.ko
29    1 0xffffffff82f90000     bcd0 amdgpu_green_sardine_rlc_bin.ko
30    1 0xffffffff82f9c000    437e8 amdgpu_green_sardine_mec_bin.ko
31    1 0xffffffff83419000    437e8 amdgpu_green_sardine_mec2_bin.ko
32    1 0xffffffff82fe0000    1fb60 amdgpu_green_sardine_dmcub_bin.ko
33    1 0xffffffff8345d000    64298 amdgpu_green_sardine_vcn_bin.ko
34    1 0xffffffff834c2000    11cd8 fusefs.ko
35    1 0xffffffff834d4000     3378 acpi_wmi.ko
36    1 0xffffffff834d8000     3218 intpm.ko
37    1 0xffffffff834dc000     2180 smbus.ko
38    1 0xffffffff834df000     2340 uhid.ko
39    1 0xffffffff834e2000     4350 ums.ko
40    1 0xffffffff834e7000     4cfc geom_uzip.ko
41    1 0xffffffff834ec000     3380 usbhid.ko
42    1 0xffffffff834f0000     31f8 hidbus.ko
43    1 0xffffffff834f4000    38070 linux.ko
44    1 0xffffffff8352d000    32208 linux64.ko
45    1 0xffffffff83560000     2260 pty.ko
46    1 0xffffffff83563000     5af8 autofs.ko
47    1 0xffffffff83569000     2a08 mac_ntpd.ko

Also there is some GFX related messages in dmesg:
dmesg

Code:

[drm] Fence fallback timer expired on ring gfx
drmn0: 0xfffff8007312a800 pin failed
[drm ERROR :dm_plane_helper_prepare_fb] Failed to pin framebuffer with error -12
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
drmn0: 0xfffff80285d5f000 pin failed
[drm ERROR :dm_plane_helper_prepare_fb] Failed to pin framebuffer with error -12
drmn0: 0xfffff8033615dc00 pin failed
[drm ERROR :dm_plane_helper_prepare_fb] Failed to pin framebuffer with error -12
[drm] Fence fallback timer expired on ring sdma0
pid 12517 (kalzium), jid 0, uid 1001: exited on signal 11 (core dumped)
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
pid 18296 (VirtualBox), jid 0, uid 1001: exited on signal 10 (core dumped)
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx

W.hâ/t · Apr 20, 2023

Why not just watch the time he spends on it? If he respects the +-30min then It's fine, if he doesn't just lock him out for a week.

Russian_Man · Apr 20, 2023

W.hâ/t said:
Why not just watch the time he spends on it? If he respects the +-30min then It's fine, if he doesn't just lock him out for a week.

Thanks for proposition, but it is not related to original question

Question about broken console, not about children. My mistake was to mention the son and the games. Now offers automatically go offtopic.

The merit of the child is that with his help, a problem with the system console was found out.

zirias@ · Apr 20, 2023

Maybe it's a result of the same virtual console used as the system console (where e.g. kernel output goes) and as a virtual terminal. That's just a guess of course. You can change the virtual console used as the system console. I personally don't bother and just avoid to ever log in on ttyv1 (it did cause problems for me, although I now don't remember which ones).

Russian_Man · Apr 20, 2023

zirias@ said:
Maybe it's a result of the same virtual console used as the system console (where e.g. kernel output goes) and as a virtual terminal. That's just a guess of course. You can change the virtual console used as the system console. I personally don't bother and just avoid to ever log in on ttyv1 (it did cause problems for me, although I now don't remember which ones).

System console are ttyv0, I'm not change it in /etc/ttys. And it worked (CTRL+ALT+F1), on screenshot died console ttyv1 (CTRL+ALT+F2). I'm try to find step by step actions which trigger that problem, maybe this will be helpful.

zirias@ · Apr 20, 2023

Reading icewm was killed by signal 9 is troubling as well. 9 is SIGKILL, so the process can't act on it, it's just terminated.

In fact, hard to say what goes wrong on the VT, but X certainly isn't meant to be killed while used by some X session. Try to at least kill the initial client instead, this gives a chance to clean up and the X server will exit as soon as the last client quits.

_al · Apr 20, 2023

Something related to output to your terminal - sleepqueue(9)

yuripv79 · Apr 20, 2023

_al said:
Something related to output to your terminal - sleepqueue(9)

That is just kernel stacks printed on SIGINFO (^T), unrelated to console state.

T-Daemon · Apr 20, 2023

Not an answer to the threads topic, a suggestion on how to, instead of killing Xorg brutally for the user, log out from Icewm gracefully.

x11-wm/icewm comes with icesh(1), a utility to interact with Icewm, from which a log out can be initialized.

For that the logout confirmation must be unset first: Settings -> Preferences -> A... - L... -> ConfirmLogout, then, after ssh into the users account, execute env DISPLAY=:0.0 icesh logout

Or use a terminal emulator: urxvt -e icesh logout. Here x11/rxvt-unicode doesn't require a DISPLAY environment.

If you prefer x11/xterm: env DISPLAY=:0.0 xterm -e icesh logout

ralphbsz · Apr 20, 2023

Educated guess: The console is not actually hung or broken. Instead it is being used by a process, perhaps by one that is trying to log in or process keyboard input. Normally, there is a process using getty for each of the virtual consoles (there are typically multiple), and that process deals with keyboard input and displaying things. If you look using ps (for example with switches auxww), you should see something like "root ... /usr/libexec/getty Pc ttyv0", one for each virtual console.

What I think happened is that when the OP attempted to kill X, they did so incompletely, and some process is still attached to the virtual terminal, and mishandling keyboard input. Perhaps because that process was never intended to run after someone tries to shut down X in a strange manner.

To debug this, look for processes that could have the offending ttyvX open, for example using fuse or ps.

Russian_Man · Apr 21, 2023

T-Daemon said:
Not an answer to the threads topic, a suggestion on how to, instead of killing Xorg brutally for the user, log out from Icewm gracefully.

x11-wm/icewm comes with icesh(1), a utility to interact with Icewm, from which a log out can be initialized.

For that the logout confirmation must be unset first: Settings -> Preferences -> A... - L... -> ConfirmLogout, then, after ssh into the users account, execute env DISPLAY=:0.0 icesh logout

Or use a terminal emulator: urxvt -e icesh logout. Here x11/rxvt-unicode doesn't require a DISPLAY environment.

If you prefer x11/xterm: env DISPLAY=:0.0 xterm -e icesh logout

As they say in Russia: "Live forever - learn forever!", many thanks T-Daemon! I will use that way.

ralphbsz said:
If you look using ps (for example with switches auxww), you should see something like "root ... /usr/libexec/getty Pc ttyv0", one for each virtual console.

ralphbsz, thanks for information that add some more deep understanding system working!
But none of processes seems to uses "broken" tty. I'm shutdown all X sessions (only slim exists), and there are all existed process. user2 - are user from which was started X session on a "broken" console. user1 - my user. Showed in output -csh from user2 - is a normal shell which works, on a ttyv2.
ps -auxww

Code:

USER         PID  %CPU %MEM    VSZ    RSS TT  STAT STARTED             TIME COMMAND
root          11 600,0  0,0      0     96  -  RNL   6апр.23    103985:31,90 [idle]
root           0   0,0  0,0      0   2688  -  DLs   6апр.23        58:03,40 [kernel]
root           1   0,0  0,0  11800   1156  -  ILs   6апр.23         0:00,08 /sbin/init
root           2   0,0  0,0      0     96  -  DL    6апр.23         0:00,00 [KTLS]
root           3   0,0  0,0      0    112  -  DL    6апр.23         0:00,00 [crypto]
root           4   0,0  0,0      0     48  -  DL    6апр.23         0:33,98 [cam]
root           5   0,0  0,0      0   1904  -  DL    6апр.23         2:32,31 [zfskern]
root           6   0,0  0,0      0     16  -  DL    6апр.23         2:02,05 [rand_harvestq]
root           7   0,0  0,0      0     48  -  DL    6апр.23         3:21,58 [pagedaemon]
root           8   0,0  0,0      0     16  -  DL    6апр.23         0:00,00 [vmdaemon]
root           9   0,0  0,0      0    112  -  DL    6апр.23         0:26,68 [bufdaemon]
root          10   0,0  0,0      0     16  -  DL    6апр.23         0:00,00 [audit]
root          12   0,0  0,0      0    352  -  WL    6апр.23       494:09,19 [intr]
root          13   0,0  0,0      0     96  -  DL    6апр.23         0:00,00 [ng_queue]
root          14   0,0  0,0      0     48  -  DL    6апр.23         0:00,05 [geom]
root          15   0,0  0,0      0     16  -  DL    6апр.23         0:00,00 [sequencer 00]
root          16   0,0  0,0      0    240  -  DL    6апр.23         1:09,72 [usb]
root          17   0,0  0,0      0     16  -  DL    6апр.23         0:07,20 [syncer]
root          18   0,0  0,0      0     16  -  DL    6апр.23         0:04,60 [vnlru]
root         120   0,0  0,0  12740   2124  -  Is    6апр.23         0:00,00 adjkerntz -i
root         176   0,0  0,0      0     16  -  DL    6апр.23         0:00,00 [Timer]
root         177   0,0  0,0      0     16  -  DL    6апр.23         0:00,00 [Timer]
root         193   0,0  0,0  12884   2268  -  Is    6апр.23         0:00,00 /usr/sbin/autounmountd
root         626   0,0  0,0  13108   2400  -  Is    6апр.23         4:07,61 /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid
root         639   0,0  0,0  11468   1532  -  Is    6апр.23         0:00,51 /sbin/devd
root         887   0,0  0,0  12896   2748  -  Ss    6апр.23         0:02,16 /usr/sbin/syslogd -ss
root         925   0,0  0,0  12884   2228  -  Is    6апр.23         0:00,00 /usr/sbin/automountd
root         943   0,0  0,0  12828   2584  -  Ss    6апр.23         0:00,83 /usr/sbin/rpcbind
root         945   0,0  0,0 279044   2508  -  Ss    6апр.23         0:00,67 /usr/sbin/rpc.statd
root         953   0,0  0,0  16952   2488  -  Ss    6апр.23         0:01,54 /usr/sbin/rpc.lockd
messagebus   966   0,0  0,0  14288   4284  -  Is    6апр.23         0:00,20 /usr/local/bin/dbus-daemon --system
root         976   0,0  0,0  12844   2272  -  Ss    6апр.23         1:08,99 /usr/sbin/powerd
ntpd        1003   0,0  0,0  22472   5664  -  Ss    6апр.23         0:35,44 /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f /var/db/ntp/ntpd.drift
root        1050   0,0  0,1  21104   8320  -  Is    6апр.23         0:00,49 sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups (sshd)
root        1054   0,0  0,0  12940   2588  -  Is    6апр.23         0:03,28 /usr/sbin/cron -s
root        1121   0,0  0,1  27384  16436  -  Ss    6апр.23         0:13,72 screen (screen-4.9.0)
root        1265   0,0  0,1 117860  14600  -  I     6апр.23         0:00,38 /usr/local/sbin/console-kit-daemon --no-daemon
polkitd     1267   0,0  0,1  37348   8736  -  I     6апр.23         0:00,13 /usr/local/lib/polkit-1/polkitd --no-debug
root       14966   0,0  0,1  91340  22816  -  I    10апр.23         0:00,05 /usr/local/bin/bsdisks --no-debug --syslog-output
root       44001   0,0  0,1  21544   9952  -  Is   09:06            0:00,02 sshd: user1 [priv] (sshd)
user1      44004   0,0  0,1  21544   9980  -  S    09:06            0:00,17 sshd: user1@pts/3 (sshd)
root       47043   0,0  0,3  56800  39004  -  Is   08:47            0:00,12 /usr/local/bin/slim -d
root       47045   0,0  0,8 260564 130988  -  I    08:47            0:00,15 /usr/local/libexec/Xorg -nolisten tcp vt09 -auth /var/run/slim.auth
root        1097   0,0  0,0  12872   2308 v0  Is+   6апр.23         0:00,00 /usr/libexec/getty Pc ttyv0
root       42199   0,0  0,0  12872   2312 v1  Is+  ср20             0:00,00 /usr/libexec/getty Pc ttyv1
root       44314   0,0  0,0  13712   3192 v2  Is   11:05            0:00,01 login [pam] (login)
user2      44315   0,0  0,0  14036   4092 v2  I+   11:05            0:00,01 -csh (csh)
root       38677   0,0  0,0  12872   2312 v3  Is+  вт15             0:00,00 /usr/libexec/getty Pc ttyv3
root       38676   0,0  0,0  12872   2312 v4  Is+  вт15             0:00,00 /usr/libexec/getty Pc ttyv4
root       38674   0,0  0,0  12872   2312 v5  Is+  вт15             0:00,00 /usr/libexec/getty Pc ttyv5
root       38673   0,0  0,0  12872   2312 v6  Is+  вт15             0:00,00 /usr/libexec/getty Pc ttyv6
root       38971   0,0  0,0  13172   2724 v7  Ts+  вт18             0:00,01 login
user1       1122   0,0  0,0  14036   4092  1  Is    6апр.23         0:00,04 -/bin/csh
root        1126   0,0  0,0  13688   3132  1  I     6апр.23         0:00,01 su
root        1127   0,0  0,0  16596   5044  1  S     6апр.23         0:00,18 _su (csh)
root       47052   0,0  0,0  13508   3160  1  R+   08:47            0:00,00 ps -auxww
root       47053   0,0  0,0  13408   2896  1  R+   08:47            0:00,00 more
user1      15042   0,0  0,0  14036   4312  5  Is+  10апр.23         0:00,02 -/bin/csh
user1       7283   0,0  0,0  14036   4368  2  Is+   8апр.23         0:00,02 -/bin/csh
user1       5193   0,0  0,0  16596   4424  4  Is+   7апр.23         0:00,03 -/bin/csh
user1      44005   0,0  0,0  14036   4148  3  Is   09:06            0:00,01 -csh (csh)
user1      46904   0,0  0,0  14072   3604  3  S+   08:34            0:00,03 screen -rd (screen-4.9.0)
user1      45506   0,0  0,0  16596   4500  6  Is   22:02            0:00,05 -/bin/csh
user1      45517   0,0  0,1  27640  12116  6  I+   22:03            0:00,29 vim a.pas
user1      45520   0,0  0,0  14036   4280  7  Is+  22:06            0:00,05 -/bin/csh

ralphbsz · Apr 21, 2023

X is still running (process Xorg), and there is no getty for ttyv2. But there is slim, which is one of the X login managers. Could it be that you're looking at the console ttyv2, but slim isn't working correctly?