Куда вписывать значение переменной XLOCAL ?

Никуда, зачем тебе эта переменная?

Какая-то документация говорит, что эту переменную надо вписывать в файл ~/.xinitrc

Куда угодно, можно в тот же .profile. Это же просто переменная окружения. А зачем она тебе?

Я сначала думал, что можно в

[SeatDefaults]
display-setup-script=command

но потом почитал https://www.freedesktop.org/wiki/Software/LightDM/CommonConfiguration/ а там написано

display-setup-script is run after the X server starts but before the user session / greeter is run.

То есть, это уже поздно…

Я думал, что если я посмотрю на скрипт lightdm.service, то смогу понять, как запускается xorg-server, но нет
вот его текст - https://github.com/canonical/lightdm/blob/main/debian/lightdm.service
там запускается
/usr/sbin/lightdm
а он бинарник
$ file /usr/sbin/lightdm

/usr/sbin/lightdm: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped

Можно было бы установить переменную окружения при помощи systemd (примерно так - https://serverfault.com/questions/413397/how-to-set-environment-variable-in-s... ), но это логически неправильно, так как эта переменная будет доступна в процессе lightdm, а не в процессе xorg-server, это нарушает какие-то там принципы секретности и может быть в будущем использовано для атаки хакерами.

Куда угодно

А мне кажется, бегло глядя на этот кусок:
https://github.com/canonical/lightdm/blob/653809c387c0a4e4d96f7999db3106d8997...
что для процесса Xorg создаётся «чистое» окружение, и где бы переменные не устанавливались, они туда не попадут...

Ты главное объясни зачем тебе эта переменная. Зачем её xorg-у сувать? Он никак её вроде бы не использует.

Вот что пишет ChatGPT:

Переменная XLOCAL является общей для среды X Window System и используется для установки локальных конфигурационных параметров, таких как кодировка символов и язык.

Информация об этой переменной есть в документации Arch Linux и в исходном коде X-сервера xorg.

в файле xc/programs/Xserver/os/utils.c она используется для установки режима локализации LC_TYPE (кодировки символов) через вызов setlocale() который изменяет локаль текущей сессии.

Говорят, что последняя версия релизилась последний раз в 2012-м году: https://www.x.org/releases/X11R7.7/ её исходники тут: https://www.x.org/releases/X11R7.7/src/xserver/

./hw/xfree86/man/Xorg.man:.I XLOCAL
./hw/xfree86/man/Xorg.man-globally.  If you use startx(1) or xinit(1), the definition should be
./hw/xfree86/man/Xorg.man-at the top of your

А документация на opennet пишет другое: https://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=Xorg&category=1 «For operating systems that support local connections other than Unix Domain sockets (SVR3 and SVR4), there is a compiled-in list specifying the order in which local connections should be attempted. This list can be overridden by the XLOCAL environment variable»

Значение XLOCAL по-умолчанию - «/tmp/.X11-unit/X», но его можно изменить перед запуском xorg

Использование локального сокета не является обязательным, можно использовать сокеты TCP/IP или UNIX.

https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BA%D0%B5%D1%82_%D0%B4%D0%BE%D0%BC%D0%B5%D0%BD%D0%B0_Unix

В общем, я прогрепал не только код сервера, но и коды клиентских библиотек libx11 и libxcb и не нашел упоминания имени XLOCAL.

Сказал об этом ChatGPT, он ответил «ох, я был неправ, ищи теперь в X11R6, а не в R7». Но я решил что хватит. Нет, значит нет.

главное объясни зачем тебе эта переменная. Зачем её xorg-у сувать?

Ты пометку сделал «этому пользователю»? Просто напоминаю.

Ну так вот, эта переменная мне больше не нужна, но я так до сих пор и не выяснил, как сконнектить библиотеку libx11 с xorg-сервер через файловый дескриптор, без использования сокетов TCP/IP.

через файловый дескриптор, без использования сокетов TCP/IP

Интересное противопоставление. А с сокетами процесс работает не через файловый дескриптор?

Вобще, с 2015 года у Xorg-сервера по умолчанию ″-nolisten tcp″ и чтобы он примал по tcp, нужно специально указывать опцию командной строки.

Если в переменной окружения DISPLAY не прописан ip-адрес, то клиент сам пытается сначала подключится по локальному пути (абстракный сокет, unix-сокет), а только потом по tcp-ip. Если у вас это не так, значит вы что-то качественно сломали в своей системе.

Я не понимаю, что такое «пространства имён сокетов» (в смысле UNIX-сокетов, а не TCP/IP-сокетов). Поэтому я не могу воспользоваться этой фичей.

значит вы что-то качественно сломали в своей системе

Ещё не успел, но зато это моё глубинное желание.

./hw/xfree86/man/Xorg.man

здесь ключевое слово xfree86 — это X-сервер, который был до Xorg, так-что ChatGPT должен был вас послать не к другому релизу, а к другому X-серверу.

Не знаю, была ли в XFree86 реализована переменная среды LOCAL или они её просто в man добавили, но в Xorg её, похоже, просто притащили копированием man'а и вобще не пытались реализовать. В 2015 году из man страницы Xorg описание этой переменной перенесли в man страницу X, которая живёт независимо от xserver, в пакете xorg-docs https://www.x.org/releases/individual/doc/ .

как сконнектить библиотеку libx11 с xorg-сервер через файловый дескриптор, без использования сокетов TCP/IP.

1. Запустить Xorg на 0 дисплее.
2. export DISPLAY=:0
3. Всё.

lightdm сам выставляет эту переменную, поэтому тебе даже делать ничего не надо, по умолчанию Xorg использует файловый дескриптор и не использует TCP/IP во имя безопасности.

Ещё не успел, но зато это моё глубинное желание.

Красавчик!

Я не совсем понимаю, про какие пространства имён вы пишете, дайте ссылку на источник.

Так, X-сервер создаёт именованый unix-сокет ″/tmp/.X11-unix/X0″ (для дисплея 0). И, ЕМНИП, путь ″/tmp/.X11-unix/″ прибит гвоздями, и клиент пытается подключится к этому сокету (как бы открыть этот файл). Если клиент и сервер будут запущены так, что это путь указывает на разных файлы (chroot), то они не соединятся.

Но есть абстракные UNIX сокеты, имя которых не отображается в файл на файловой системе, а существует только в ядре. И оно едино для всех процессов, не важно в каком chroot они запущены. И в этом абстрактном простространстве имён X-сервер тоже может создать сокет, отображаемый в выводе ″lsof -U″ как ″@/tmp/.X11-unix/X0″.

про какие пространства имён вы пишете

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%81%D1%82%D1%80%D0%B0%D0%BD%D1%81%D1%82%D0%B2%D0%BE_%D0%B8%D0%BC%D1%91%D0%BD_(Linux)#%D0%9C%D0%B5%D0%B6%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BD%D0%BE%D0%B5_%D0%B2%D0%B7%D0%B0%D0%B8%D0%BC%D0%BE%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B5_(IPC)

«Каждое пространство имён IPC имеет свой собственный набор идентификаторов System V IPC»

«System V IPC включает в себя семафоры, разделяемую память и очереди сообщений»

Эти очереди сообщений - это NamedPipes или нет?

https://www.knowledgepowerhouse.com/what-are-the-different-kinds-of-namespaces-available-in-a-container/1228 «This namespace covers shared memory, semaphores, named pipes»

Эти очереди сообщений - это NamedPipes или нет?

Нет, «именованые каналы» это совсем не очереди сообщений. С каналами (pipe) работают как с файлами (read(), write()), и, если они именованые, они привязаны к файлу, поэтому относятся к mount namespace.

В ″man ipc_namespaces″, что, ИМХО, авторитетнее справки по докеру, нет NamedPipes, там:

IPC namespaces isolate certain IPC resources, namely, System V IPC objects and POSIX message queues.

Очереди сообщений, что System V, что POSIX, это совсем не файлы/pipe'ы. И для создания очереди, записи туда сообщения и чтения сообщения совсем другие сисколы, причём ещё разные для System V и POSIX. У очереди есть идентификатор, но он не связан с файлом на ФС, он существует в отдельном пространстве имён.

На всякий случай, именованые каналы — это не именованые UNIX-сокеты, хотя похожи наличием файла на ФС.

https://superuser.com/questions/502875/linux-named-sockets-howto

A Unix/Linux socket file is basically a two-way FIFO. Since sockets were originally created as a way to manage network communications, it is possible to manipulate them using the send() and recv() system calls. However, in the Unix spirit of “everything is a file”, you can also use write() and read().

В общем, ничего непонятно.

Я хочу добиться того, чтобы с одной стороны (на хосте) работал xorg-сервер и часть DE, а с другой стороны (в lxc-контейнере) работала прикладная программа, специально туда собранная со всеми её зависимостями. И сделать это без использования сетевого стека.

В вашей ссылке начало хорошее, а потом неправильно:

You need to use socketpair() or socket() to create named sockets.

socketpair() создаёт пару соединённых неименованых сокетов, socket() создаёт один неименованый сокет. А чтобы он стал именованым (pathname socket), его нужно прибиндить == bind().

У вас для контейнера и основной системы путь ″/tmp/.X11-unix/X0″ — разные файлы. И именно для этого в Линуксе были придуманы абстрактные Unix-сокеты, которые как именованые, но живут в своём пространстве имён, а не на файловой системе.

Начинайте с изучения вывода ″netstat -x -l -p″, если там есть абстрактный unix-сокет у X-сервера, то всё должно работать.

Если нет, то либо смотрите опции X-сервера, чтобы он появился, либо делайте /tmp/X11-unix отдельной ФС и монтируйте в контейнер, либо запускайте в основной системе socat, чтобы он «проксировал» unix-сокет «X0» контейнера в основную систему...

А, да, передача в контейнер куки (Xauthority) это отдельная задача. Можете для начала на X-сервере разрешить всем подключаться (см. команду xhost).

У вас для контейнера и основной системы путь ″/tmp/.X11-unix/X0″ — разные файлы.

А я смонтирую раздел в основную систему и в контейнер (по пути /tmp/.X11-unix). И файл будет одинаковый.

делайте /tmp/X11-unix отдельной ФС и монтируйте в контейнер

так уже пробовал, но не заработало. Но я думаю, что не по этому, а потому что я что-то ещё не настроил.

передача в контейнер куки (Xauthority) это отдельная задача. Можете для начала на X-сервере разрешить всем подключаться (см. команду xhost)

У меня ещё на клиентской стороне сразу не работало. Возможно DISPLAY не находило, но точно не помню.

либо запускайте в основной системе socat, чтобы он «проксировал» unix-сокет «X0» контейнера в основную систему…

Это будет «через сетевой стек», и не считается (удовлетворительным решением)

Вот как socat что-то спроксирует? Через какой механизм? Что мещает воспользоваться этим механизмом сразу?

И именно для этого в Линуксе были придуманы абстрактные Unix-сокеты, которые как именованые, но живут в своём пространстве имён, а не на файловой системе.

Нет, я думаю, что они были придуманы совсем не для этого, потому что не существовало ещё lxc когда их придумывали.

Начинайте с изучения вывода ″netstat -x -l -p″, если там есть абстрактный unix-сокет у X-сервера, то всё должно работать.

Это не поможет мне. Потому что я не увижу есть там или нет и не пойму абстрактный он или не абстрактный.

Мне бы помогла книга про сокеты и только про них, без ничего лишнего и без ошибок (если уж они на stackoverflow, то кому верить).

И чтобы там не было сетевых сокетов. Потому что «это другое».

потому что не существовало ещё lxc когда их придумывали.

Но chroot то существовал всегда :) А абстрактные unix-сокеты появились в 2.1.15.

не пойму абстрактный он или не абстрактный.

Я писал выше, чем они отличаются в выводе lsof и других утилит.

И чтобы там не было сетевых сокетов. Потому что «это другое».

Ну не знаю, это что-то из начала 1980-х должно быть, какая-нибудь документация по Unix System III.

Я писал выше, чем они отличаются в выводе lsof и других утилит.

Насколько я запомнил - символом @ в самом начале имени.

Правильно. Тогда зачем вы написали это:

Потому что я не увижу есть там или нет и не пойму абстрактный он или не абстрактный.

ИМХО, эта тема себя исчерпала.

Чтобы тема себя исчерпала, надо чтобы у меня заработал задумываемый сетап. А для этого надо этим заниматься.

и есть у меня подозрение, что он как-то связан с sysvinit а не с systemd

Ни с тем,ни с другим не связан никак. Это иксовый файл,к инитам отношения не имеет.