Вопросы Теги

Программы screen и tmux внезапно перестали прокручивать мышь в KDE Konsole

Чтобы увидеть, что на самом деле делает LXC, давайте создадим новый контейнер и проследим процесс его запуска черезstrace(1):

[root@localhost /]# lxc-create -n testcontainer -t debian
[root@localhost /]# strace -e trace=clone,chdir,mount,pivot_root,execve \
                           -f -o lxclog \
                           lxc-start -n testcontainer

Полученная трассировка записывается в lxclog файл, и здесь представлены наиболее важные ее части (многоточие добавлено мной, где опущены некоторые -несущественные вызовы):

14671 clone(child_stack=0x7fff9379eb80, flags=CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = 14677
<...>
14677 mount("/var/lib/lxc/testcontainer/rootfs", "/usr/lib64/lxc/rootfs", 0x7fe4c2d10eac, MS_BIND|MS_REC, NULL) = 0
<...>
14677 chdir("/usr/lib64/lxc/rootfs")    = 0
14677 pivot_root(".", "/usr/lib64/lxc/rootfs/lxc_putold") = 0
14677 chdir("/")
<...>
14677 execve("/sbin/init", ["/sbin/init"], [/* 1 var */]) = 0

Во-первых, новый процесс (PID 14677 )порождаетсяlxc-start(PID 14671 )с использованием clone(2)и помещается в новое пространство имен монтирования(CLONE_NEWNSфлаг ). Затем внутри этого нового пространства имен монтирования корневая файловая система контейнера(/var/lib/lxc/testcontainer/rootfs)привязывается -монтируется(MS_BINDфлаг )к /usr/lib64 /lxc/rootfs , который затем становится новым корнем. Наконец, когда инициализация контейнера завершена, процесс 14677 становится initконтейнера.

Здесь важно то, что корневой каталог пространства имен монтирования контейнера является привязкой монтирования каталога , принадлежащего корневой ФС хоста. Вот почему корневое монтирование контейнера по-прежнему имеет /dev/sda1 в качестве источника в выводе mount(8). Однако,также есть разница, которую не показывает mount(8)-, чтобы увидеть ее, попробуйте findmnt(8)внутри контейнера:

root@testcontainer:~# findmnt
TARGET                                SOURCE                     FSTYPE    OPTIONS
/                                     /dev/sda1[/var/lib/lxc/testcontainer/rootfs]

Сравните это с выводом findmnt(8)хост-системы:

[root@localhost /]# findmnt
TARGET                                SOURCE                    FSTYPE     OPTIONS
/                                     /dev/sda1

Обратите внимание, что исходный такой же, но внутри контейнера вы также видите исходный каталог монтирования привязки.

0
01.10.2020, 16:40
2 ответа

the scroll bar is solid and won't work

Вы переключились на альтернативный буфер экрана. Konsole — один из нескольких эмуляторов терминала, в котором альтернативный экранный буфер волшебным образом отличается от основного. Он волшебным образом не прокручивается и не имеет буфера прокрутки.

Переключитесь обратно с помощьюtput:

tput te
(имя терминальной информации для этой возможностиrmcup)или с помощью моего портативного settermинструмента:

setterm --altbuffer off
или просто выведите управляющую последовательность (RM частного режима DEC 1047 )от руки с printf.

Дополнительная литература

  • Джонатан де Бойн Поллард (2018 ).setterm. Направляющая ноша . Программное обеспечение.
-1
18.03.2021, 23:00

Я решил проблему, изменив локальную переменную окружения TERM. Я пробовал несколько вариантов этого при входе в удаленный сеанс через экран , но ни одна из стандартных эмуляций VT100 / xterm не имела никакого значения.

Проблема, по-видимому, связана с экраном , принимающим определение терминала сеанса консоли и создающим на лету другой TERMCAP. Решение состоит в том, чтобы изменить переменную среды TERM :" TERM=vt100 ssh -t user@host screen -RR " для сеанса. Полученный TERMCAP имеет правильное поведение полосы прокрутки.

Не уверен, что это имеет смысл, но мне помогло.

0
18.03.2021, 23:00

Теги

Похожие вопросы