Старый друг - лучше новых двух (тут трется воскресший freenx-server)

[Djelf]

У меня больше 15 сессий на 1с 7.7, но pid`s все равно будут использоваться при завершении работы, тут скорость не критична.
А что там за бардак? Пара пидов ну и все, а все остальное логи. Они нужны...

[dimbor]

15 сессий под одним линуксовым логином? Мсье знает толк. Там для dbf есть конечно условие на одного юзера и группу, но оно на уровне внутрилинуксового монтирования самба-шар с один-эсными базами великолепно распедаливается.

[Djelf]

Почему под одним? Под разными конечно. FreeNX мультисессии от одного пользователя не сильно любит.
У меня не 100500 баз, как у тебя, а всего две на 7.7, одна боевая, а вторая это ежедневная копия, для тех кто хочет побаловаться.
На другом сервере много всяких баз на 1С 8.3, но он пока на xrdp (на нем твой FreeNX тоже тестирую, потому что задержка ~60мс), но что забавно, подтормаживание на xrdp не сравнимо с тормозами самой платформы 1С 8.3 на любом железе, поэтому, по ощущению, работать что так, что сяк, одинаково некомфортно

[dimbor]

Подумал я тут еще и понял собственную неправоту. Да, табличка с пидами не нужна - они за пределами контролирующей их функции не юзаются пока кроме одного-двух. Но механизм пригодится для таблицы с шарами. Без нее-то точно никак.

А вот скажи, если будет в ней TEXT PRIMARY KEY с именем шары/принтера, WITHOUT ROWID даст что-то кроме понтов и обратной несовместимости?

Добавлено (08:55):

Бардак не в пидах, в директории scripts с файлами mmport, cupsport, mport, smbport. Этих точно надо в базу.

[Djelf]

Что тебе даст WITHOUT ROWID? 100 байт экономии на 10 сессий и невозможность запустится на ubuntu 12.04
Это сделано для громадных таблиц key/value, тут оно не требуется.
А TEXT PRIMARY KEY там зачем? id сессии и этого хватит.

[dimbor]

А вот при запуске нескольких одинаковых сессий от одного пользователя и особенно их рандомного завершения происходит мультишара. Т.е. шара/принтер не гибнет, а перецепляется на порт соседней сессии при ее наличии.
Сейчас данные для переподключения живут в мутном каталоге shares_priv, а будут - в этой табличке. Так что шары - общее достояние юзера, а не какой-то сессии. Но я тебя понял. Авось и без PRIMARY KEY оно в четырех строчках не заблудится.

[Djelf]

Хм, однако проблема нарисовалась. Из суспенда сессия поднимается почти минуту.
На этот раз это не прокачка кривой иконки, т.к. через соединение на localhost тоже воспроизводится.

Spoiler

[12.03 16:48:14.586:8142/8142] NX> 103 Welcome to: server2 user: addm
[12.03 16:48:14.593:8142/8142] NX> 105[12.03 16:48:14.758:8142/8142] listsession --user="addm" --status="suspended,running" --geometry="1920x1080x32+render" --type="unix-application"
NX> 127 Sessions list of user 'addm' for reconnect:

Display Type Session ID Options Depth Screen Status Session Name
------- ---------------- -------------------------------- -------- ----- -------------- ----------- ------------------------------
2000 unix-application 2291EF6AA23051B7DAE9C07224570554 -RD--PSA 32 1914x1011 Suspended server2


NX> 148 Server capacity: not reached for user: addm
[12.03 16:48:14.953:8142/8142] NX> 105[12.03 16:48:16.839] [12.03 16:48:16.843] restoresession --virtualdesktop="1" --application="startxfce4" --link="adsl" --backingstore="1" --encryption="1" --cache="8M" --images="32M" --shmem="1" --shpix="1" --strict="0" --composite="1" --media="0" --session="server2" --type="unix-application" --geometry="1914x1011" --client="winnt" --keyboard="pc102/en_US" --id="2291EF6AA23051B7DAE9C07224570554" --virtualdesktop="1" --resize="1"

NX> 1000 NXNODE - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.23)
[12.03 16:48:17.057:8142/8395] server_nxnode_echo: NX> 1000 NXNODE - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.23)
NX> 1005 Session status: suspended
-------------------------------- ТУТ ЭТА БЯКА --------------------------------
[12.03 16:48:17.082:8142/8395] server_nxnode_echo: NX> 1005 Session status: suspended
NX> 1009 Session status: resuming
NX> 1009 Session status: resuming
[12.03 16:49:01.013:7421/7517] [12.03 16:49:01.013:8142/8395] server_nxnode_echo: NX> 1009 Session status: resuming
-------------------------------- ТУТ ЭТА БЯКА --------------------------------
server_nxnode_echo: NX> 1009 Session status: resuming
NX> 700 Session id: server2-2000-2291EF6AA23051B7DAE9C07224570554
NX> 705 Session display: 2000
NX> 703 Session type: unix-application
NX> 701 Proxy cookie: 542520667100faa394d8aaed160e51da
NX> 702 Proxy IP: 192.168.0.50
NX> 706 Agent cookie: 542520667100faa394d8aaed160e51da
NX> 704 Session cache: unix-application
NX> 707 SSL tunneling: 1
NX> 710 Session status: running
NX> 1002 Commit
NX> 1006 Session status: running
NX> 700 Session id: server2-2000-2291EF6AA23051B7DAE9C07224570554
NX> 705 Session display: 2000
NX> 703 Session type: unix-application
NX> 701 Proxy cookie: d126e224d788343a0d994a0b12b4c61c
NX> 702 Proxy IP: 127.0.0.1
NX> 706 Agent cookie: d126e224d788343a0d994a0b12b4c61c
NX> 704 Session cache: unix-application
NX> 707 SSL tunneling: 1
NX> 710 Session status: running
NX> 1002 Commit
NX> 1006 Session status: running
[12.03 16:49:01.021:7421/7517] server_nxnode_echo: NX> 700 Session id: server2-2000-2291EF6AA23051B7DAE9C07224570554
[12.03 16:49:01.022:8142/8395] server_nxnode_echo: NX> 700 Session id: server2-2000-2291EF6AA23051B7DAE9C07224570554
[12.03 16:49:01.025:7421/7517] server_nxnode_echo: NX> 705 Session display: 2000
[12.03 16:49:01.026:8142/8395] server_nxnode_echo: NX> 705 Session display: 2000
[12.03 16:49:01.029:7421/7517] server_nxnode_echo: NX> 703 Session type: unix-application
[12.03 16:49:01.029:8142/8395] server_nxnode_echo: NX> 703 Session type: unix-application
[12.03 16:49:01.032:7421/7517] server_nxnode_echo: NX> 701 Proxy cookie: 542520667100faa394d8aaed160e51da
[12.03 16:49:01.033:8142/8395] server_nxnode_echo: NX> 701 Proxy cookie: d126e224d788343a0d994a0b12b4c61c
[12.03 16:49:01.036:7421/7517] [12.03 16:49:01.036:8142/8395] server_nxnode_echo: NX> 702 Proxy IP: 192.168.0.50
server_nxnode_echo: NX> 702 Proxy IP: 127.0.0.1

Пока можно плюнуть/подождать пока ты пиды в sqlite не засунешь.
Может после этого само уйдет...

А вот еще конфетка на закуску: поведение nxserver стало зависить от каталога, где вызвана команда.

Spoiler

root@addm-VirtualBox:/home/addm/.nx/C-addm-VirtualBox-3001-2CC20729A4EE253506BFE8D9728DB5B0# nxserver --list
shell-init: ошибка определения текущего каталога: getcwd: нет доступа к родительским каталогам: Нет такого файла или каталога
sh: 0: getcwd() failed: No such file or directory
sh: 0: getcwd() failed: No such file or directory
NX> 100 NXSERVER - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.23)
NX> 127 Sessions list:

Server Display Username Remote IP Session ID
------ ------- --------------- --------------- --------------------------------
127.0.0.1 3001 addm - 636941D054513306891D9BC5D914AF89
NX> 999 Bye
root@addm-VirtualBox:/home/addm/.nx/C-addm-VirtualBox-3001-2CC20729A4EE253506BFE8D9728DB5B0#
root@addm-VirtualBox:/home#
root@addm-VirtualBox:/home#
root@addm-VirtualBox:/home#
root@addm-VirtualBox:/home# nxserver --list
NX> 100 NXSERVER - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.23)
NX> 127 Sessions list:

Server Display Username Remote IP Session ID
------ ------- --------------- --------------- --------------------------------
127.0.0.1 3001 addm - 636941D054513306891D9BC5D914AF89
NX> 999 Bye

[dimbor]

А вот еще конфетка на закуску: поведение nxserver стало зависить от каталога, где вызвана команда.

Тут кондитер из тебя получился так себе.

freenx прикуп не знает и в Сочи жить не будет. Но его поведение в данной ситуации достойно похвалы. Что-то мне подсказывает, что ты зашел шеллом в каталог работающей сессии 2CC20729A4EE253506BFE8D9728DB5B0. Потом ее завершил и запустил еще одну. А потом возжелал получить список, находясь в несуществующем каталоге. Он в T-C-... уже переименован. Ну или в F-C-.., как повезло.

А вот при restore тупит, да. Тоже все откладываю разбирательство. Тешу себя мыслью, что раньше тупизна была незаметна на общем фоне.

[dimbor]

Собсно, начал разбираться с restore. Детектив с элементами сумасшедшинки. Столько было приложено усилий и всяких грязных трюков для достижения мизерного выхлопа. Это как если тапки с ноги на ногу переодевать при помощи подъемного крана. Все сошло с ума, и мы все умрем. Это точно.

А если без лирики: 1) Сможешь на пальцах объяснить физический смысл 701 Proxy cookie и 706 Agent cookie? Оно одинаковое, генерируется фриэныксом, засовывается в агент и отсылается клиенту. Сейчас при restore - перегенерится новое. С именем файла кэша (да и session_id) не совпадает. Может быть связано? А если старое юзать?

2) Опять про 703 Session type и 704 Session cache - агенту то я поставлю тип 'agent' в соответствии с инструкциями. А клиенту что отсылать в этих строчках? Врать как раньше? Тема сисек все еще не раскрыта.

[Djelf]

1. Agent cookie в NX-libs вообще не используется. Видимо это наследие прошлого.
Читай ключи nxproxy. Возможно нужно передавать старый cookie, но я не уверен.

Spoiler

cookie=s Используйте предоставленный cookie для аутентификации на удаленном прокси. Тот же файл cookie используется в качестве фальшивого значения, используемого для авторизации X. Поддельный cookie-файл заменяется на стороне X-сервера реальным cookie-файлом, который будет использоваться для отображения, чтобы реальный cookie-файл не перемещался по сети. Если прокси-cookie не используется, любой хост сможет подключиться к прокси-серверу. Смотрите также параметр «accept».

accept=s Имя или IP-адрес хоста, который может подключаться к прокси.

connect=s Имя или IP-адрес хоста, к которому будет подключаться прокси.

2. Как я и писал как то выше, если подменять unix-application на agent или proxy, то кэш сессии должен сохраняться/восстанавливаться даже при закрытии/открытии новой сессии.

[dimbor]

1. Agent cookie в NX-libs вообще не используется. Видимо это наследие прошлого.
Читай ключи nxproxy. Возможно нужно передавать старый cookie, но я не уверен.

Походу правильно ты не уверен. Агент - странный товарищ. Пинается снаружи HUP-ом, что при suspend, что при restore. На то, что ему позволяет различать эти пинки, в кандидатах имеется только эта новая ненадкусанная печенька. Ну не счетный триггер же там оборудован? Лезть в код агента смотреть - активно лень. Тем более, обладание этим сокровенным знанием ничего в дальнейших действиях не меняет.

[Djelf]

Лезть в код агента смотреть - активно лень. Тем более, обладание этим сокровенным знанием ничего в дальнейших действиях не меняет.

Не в агента, а nx-libs/nxcomp/src/Loop.c там много чего интересного есть, ибо nxcomp встроен в nxagent, а не наоборот.
И, несмотря на то что там 15к строк (отформатировали бы в AStyle, раз в 5 меньше было бы), загадочного там мало, все в принципе по полочкам разложено.
Даже просто пролистать, для общего развития и понимания того, что оно внутри там делает, и это стоит сделать
Можно, конечно, управлять автомобилем не зная как и почему он едет, но чинить его так нельзя...

[dimbor]

Даже просто пролистать, для общего развития и понимания того, что оно внутри там делает, и это стоит сделать
Можно, конечно, управлять автомобилем не зная как и почему он едет, но чинить его так нельзя...

Ага. Главное не впасть в другую крайность. У всех советских детей наверное был во дворе великий автомобильный спец дядя Вася. Чья масляная жопа торчала из под капота его ласточки годами. А ехавшей эту машину не видел вообще никто.

Переписал монитор в nxnode по смыслу. Убрал дублированное общение его экземпляров с экземплярами nxserver при восстановлении сеанса. Помогло несильно - больше четырех секунд у меня на рутлесе. Но по крайней мере, как-бы доказана непричастность фриэныкса. Если раскаментишь nxlog в 1181 строке nxnode, увидишь расклад по времени вывода агента при восстановлении с момента HUP до "Session resumed at".

Ну что, намасливать задницу и лезть под капот?

ЗЫ: Еще там раньше при восстановлении этот лог агента (session) принудительно приводился в нечитаемое состояние. Вот интересно, зачем?

[Djelf]

Это я лопухнулся У меня в этой сессии висела шара без пароля (по пользователю), которая не подключалась
При восстановлении, видимо подключение шары происходит не параллельно, что и приводит к задержке.

Специально в Loop.c можно и не залезать, но когда будет время и необходимость отвлечься (на-подумать) от FreeNX заглянуть все же стоит.

Возможно так себя вел оригинальный NXServer, а FreeNX просто повторял поведение. Вопрос зачем видимо так и останется открытым...

[dimbor]

При восстановлении, видимо подключение шары происходит не параллельно, что и приводит к задержке.

Параллельно. Зуб даю. Видимо задержка была с поднятием порта, ну или в созвездиях что-то не так было.

[Djelf]

Так я не один же раз пробовал.
Убираю шару - и подключение, и восстановление примерно одинаково.
Восстанавливаю кривую шару (да, знаю что кривую шару, но и смысл тестирования в подаче кривых значений) - подключение как обычно, восстановление +40-60с.

[dimbor]

Терпение. До шар доберусь вскорости и все там сломаю

[Djelf]

Я почти случайно это сделал, я не виноват, я тестил
Но я с самого начала просто выдавал ярлык на серверную шару, а про то что можно шарить локальные каталоги и принтеры, тактично умалчивал.
Сколько лет уже это работает? Да до хрена, уже... Но никто не полез в настройки и не догадался что так можно
Может у тебя кто-то более продвинутый затесался и "пропалил контору"...

P.S. Я считаю, и буду считать, и меня не переубедить уже, что локальные шары через nx, это зло!
Шара на сервер через впн работает на порядок быстрее и стабильнее. Но это только мое ИМХО.
Кстати и шары через RDP тоже уже не айс. Ломанули сервер через RDP, подкинули шифратор, я полез, и пока прибил гадину, он успел и у меня порезвится. Теперь только диск в ram перенаправляю...

[Djelf]

Еще косячёк нашелся.
В некоторых случаях сессию не удается завершить.
Воспроизвести можно так: в patch.conf прописываем для kde и гнома - startxfc4, запускаем сессию с кде, отключаем сессию, подключаем, но уже как гном. В этом случае nxclient выводит окно со списком сессий, но завершить сессию кде не удается.
Это просто воспроизведение ситуации, такое еще в каких то случаях бывает, но таким образом воспроизводится четко.
При этом в логе видно, что запрос на завершение сессия верный и отправляется по ее id.

Spoiler

[16.03 14:49:17.967:31117/31117] NX> 105[16.03 14:49:18.333:17776/17776] listsession --user="addm" --status="suspended,running" --geometry="1920x1080x32+render" --type="unix-kde"
NX> 127 Sessions list of user 'addm' for reconnect:

Display Type Session ID Options Depth Screen Status Session Name
------- ---------------- -------------------------------- -------- ----- -------------- ----------- ------------------------------
3000 unix-gnome 533CE05199D967C0522CAC93A5B9B288 -RD--PSA 32 1914x1011 Suspended server2-wg


NX> 148 Server capacity: not reached for user: addm
[16.03 14:49:18.374:17776/17776] NX> 105[16.03 14:49:20.765:17776/17776] terminate --sessionid="533CE05199D967C0522CAC93A5B9B288"
NX> 1000 NXNODE - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.23)
NX> 716 Terminating session 533CE05199D967C0522CAC93A5B9B288 on user request.
NX> 1001 Bye.
[16.03 14:49:20.959:17776/17776] NX> 105[16.03 14:49:21.974:31117/31117] listsession --user="addm" --status="suspended,running" --geometry="1920x1080x32+render" --type="unix-kde"
NX> 127 Sessions list of user 'addm' for reconnect:

Display Type Session ID Options Depth Screen Status Session Name
------- ---------------- -------------------------------- -------- ----- -------------- ----------- ------------------------------
3000 unix-gnome 533CE05199D967C0522CAC93A5B9B288 -RD--PSA 32 1914x1011 Suspended server2-wg

[dimbor]

И сие безобразие с вываливанием окошка с сессиями происходит при включенном автореконекте?

Код: Выделить всё

[16.03 14:49:18.374:17776/17776] NX> 105[16.03 14:49:20.765:17776/17776] terminate --sessionid="533CE05199D967C0522CAC93A5B9B288"
NX> 1000 NXNODE - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.23)
NX> 716 Terminating session 533CE05199D967C0522CAC93A5B9B288 on user request.
NX> 1001 Bye.
[16.03 14:49:20.959:17776/17776] NX> 105[16.03 14:49:21.974:31117/31117] listsession --user="addm" --status="suspended,running" --geometry="1920x1080x32+render" --type="unix-kde"

А в отквоченный период времени в nxnode-*.log чтой-нибудь происходит? Интересуюсь, т.к. de у меня только на убунту есть, а обновлять там фриэныкс пока не хочется. Я его в качестве образцового использую при извращениях с исправляемым. Т.ч. записываю пока твою предъяву в туду-фиксми.

Добавлено (16:39):

Могу пока предположить, что она все же грохается, только nxserver статус Finished ей за каким-то не ставит.

[Djelf]

И сие безобразие с вываливанием окошка с сессиями происходит при включенном автореконекте?

А в отквоченный период времени в nxnode-*.log чтой-нибудь происходит? Интересуюсь, т.к. de у меня только на убунту есть, а обновлять там фриэныкс пока не хочется. Я его в качестве образцового использую при извращениях с исправляемым. Т.ч. записываю пока твою предъяву в туду-фиксми.

Конечно вываливается, именно этого я и хотел воспроизвести, потому что оно периодически при каких то неясных ситуациях появляется.
Здесь важно именно то что сессия не убивается при запросе от клиента!
Я вообще не понимаю зачем там флаг автореконнекта, когда решение об этом принимает клиент.

Точно, nxnode-*.log то я и не посмотрел.
Каталог то не "server2--027EA84152E1662F92B3323E09A76BBC", а "server2-3000-027EA84152E1662F92B3323E09A76BBC".

Spoiler

16:40:52.327: /usr/bin/nxnode (3009): run nxnode with PARAMS:"--terminate"; CMDLINE='&session_id=027EA84152E1662F92B3323E09A76BBC&display='
16:40:52.341: node_terminate_session (3009/3009): Start terminating session "server2--027EA84152E1662F92B3323E09A76BBC" with status ""
16:40:52.342: node_terminate_session (3009/3009): Session directory not found.

И самое поганое в этой ситуации, что и новую сессию не открыть, хотя к старой подсоединится можно, хоть это хорошо.

Spoiler

NX> 148 Server capacity: not reached for user: addm
NX> 105 startsession --link="adsl" --backingstore="1" --encryption="1" --cache="8M" --images="32M" --shmem="1" --shpix="1" --strict="0" --composite="1" --media="0" --session="server2-wg" --type="unix-kde" --geometry="1914x1011" --client="winnt" --keyboard="pc102/en_US" --screeninfo="1914x1011x32+render"

NX> 1000 NXNODE - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.23)
NX> 500 Error: Fatal - Missing parameter session id.
NX> 280 Exiting on signal: 15

При этом на сервере поднимается старая сессия, но клиент ее не видит, а после вылета клиента сессия остается в статусе открыта (может потом по ssh вылетит, не дожидался).
Ага, а вот это происходит видимо уже из-за автореконнекта. Наверное клиент говорит - дай новую сессию, а сервер такой "нет! жуй старую".

Ты же вроде разворачивал виртуалку на 16.04, стер уже?

[dimbor]

Каталог то не "server2--027EA84152E1662F92B3323E09A76BBC"

Это мой косяк, в nxserver предположительно. Дисплей с какого-то не передается. Постараюсь поправить вскорости.

а Ты же вроде разворачивал виртуалку на 16.04, стер уже?

Так она то и образцовая. Не люблю de на терм. серверах примерно как ты - шары на клиентах ;)

[Djelf]

Так она то и образцовая. Не люблю de на терм. серверах примерно как ты - шары на клиентах

Тогда сделай две сессии с разными названиями и запускай там xterm.
nxclient`у для вывода списка сессий нужно отличие в сессии в суспенде и заказанной сессии.

Ну и в случае autoreconnect IMHO нужно подменять startsession на restoresession с указанием старых параметров.
В конфиге про это ничего нет, но такое поведение логично:
1. Если заказанная сессия совпадает с суспендом, клиент сам заказывает ее поднятие, в не зависимости от флага autoreconnect, окно выбора сессии не показывается.
2. Если заказанная сессия НЕ совпадает с суспендом, клиент позволяет выбрать поднятие сессии, в не зависимости от флага autoreconnect.
3. Если заказанная сессия НЕ совпадает с суспендом, но пользователь начинает новую сессию, тогда в ЗАВИСИМОСТИ от флага autoreconnect либо создается новая сессия, как указал пользователь (при autoreconnect=0), либо (при autoreconnect=1) поднимается старая, в не зависимости от того что выбрал пользователь.
Это единственная доступная, в моем понимании, логика работы флага autoreconnect.

[dimbor]

Если перед строкой 1303 в nxserver:

Код: Выделить всё

in_params+="&display=$display"

Вставить строчки:

Код: Выделить всё

[ -z "$display" ] && \
   display=$(q_vals_str_get "sess" "session_id='$session_id'" "display")

Должно помочь. Но это не точно.
Телеграфируй.

Добавлено (21:07):

Выше, в restoresession*) тоже такую фигню надо добавить. Кто ж знал, что клиент в разных режимах разный состав параметров присылает. И усе будет работать, как прописал доктор.

[Djelf]

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

Это же было очевидно...
Для запуска пустой сессии ее id возвращает сервер, а для убивания/восстановления ее указывает клиент по ответу сервера.
Как иначе это бы вообще работало?

Фиксы, в сообщение выше, эти баги исправили.
Подожду твоего следующего комплекта патчей в гит и если ничего критичного не найду, возможно уже поставлю на продакшн.
Отсутствие возможности убивания сессии этому препятствовало (мне влом по 10 раз в день рубить залипшие сессии юзверей).
Про несоответствие имени сессии при старте и что оно приводит к "странному окну для юзверей" не сразу удалось догадаться
Ну, 21й век, а набор Эллочки Людоедки из 20 английских слов, выучить ну никак нельзя... Позорище

[dimbor]

Фиксы, в сообщение выше, эти баги исправили.

А еще скилл "закат солнца наощупь" апнулся.

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

Это же было очевидно...

Это я написал совсем не то, о чем подумал. Так бывает. Думал в тот момент, что клиент серверный display не присылает, а terminate с командной строки обрабатывается в другом месте. Так-что оно раньше и не тестировалось.

Ну, 21й век, а набор Эллочки Людоедки из 20 английских слов, выучить ну никак нельзя... Позорище

"Там какое-то окошко английское выскочило. Я его закрыла, и все сломалось." - от этой симптоматики не избавляет даже больше одного высшего образования в анамнезе. Проверено.

Добавлено (19:29):

Запузырил в гит. Обрати внимание, еще конфиг изменился. Убрал пока перебор протухших башевских профилей при старте. Это будет в nxsetup. Потом.

[Djelf]

Вылетает при восстановлении сессии
Поднимается но сразу же падает.

Spoiler

sshlog на клиенте
NX> 718 Session restore succeded
Connection to 192.168.0.50 closed by remote host.

nxserver.log ubuntu 16.04
[18.03 12:27:29.003:13265/13364] server_nxnode_echo >&1: NX> 1000 NXNODE - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.23)
/usr/bin/nxnode: строка 1242: ~/.profile: Нет такого файла или каталога
NX> 1009 Session status: starting
NX> 700 Session id: server2-3003-A5BF81A6282A3F8AEEB77EF58D647A0D

nxserver.log ubuntu 19.04
NX> 1000 NXNODE - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.23)
[18.03 12:59:12.866:22093/22344] server_nxnode_echo >&1: NX> 1000 NXNODE - Version 3.5.0-0.2-CE OS (GPL, using backend: 3.5.99.23)
/usr/bin/nxnode: строка 1242: ~/.profile: Отказано в доступе
NX> 1009 Session status: resuming

nxnode
12:57:32.771: node_stop_services (20797/20875): call reconnect_pa
12:57:32.773: node_stop_services (20797/20875): end
12:59:12.887: /usr/bin/nxnode (22348): run nxnode with PARAMS:"--resumesession"; CMDLINE='&virtualdesktop=1&application=startxfce4&link=adsl&backingstore=1&encryption=1&cache=16M&images=64M&shmem=1&shpix=1&strict=0&composite=1&media=0&session=192.168.10.229&type=unix-application&geometry=1914x1011&client=winnt&keyboard=pc102/en_US&session_id=A63E3D3FAAA43C37BE5D548E8ED98CF4&virtualdesktop=1&resize=1&display=3001&clientproto=3.5.0&login_method=SU&user=addm&userip=192.168.10.215&display=3001&status=Suspended'
12:59:12.906: startsession (22348/22348): starting with args "restore"
12:59:12.915: startsession (22348/22348): generate "/home/addm/.nx/C-addm-VirtualBox-3001-A63E3D3FAAA43C37BE5D548E8ED98CF4/options"
12:59:12.917: startsession (22348/22348): restore session
12:59:12.919: node_start_monitor (22348/22415): starting
12:59:12.921: startsession (22348/22348): call 'node_suspend_session "addm-VirtualBox-3001-A63E3D3FAAA43C37BE5D548E8ED98CF4"'
12:59:12.922: node_suspend_session (22348/22348): starting
12:59:12.924: node_suspend_session (22348/22348): node_agent_pid='20883' Killing...
12:59:12.926: node_suspend_session (22348/22348): end (HUP)
12:59:17.417: node_start_monitor (22348/22415): end
12:59:17.445: startsession (22348/22348): end

[dimbor]

А поставь в 08-bash.conf SOURCE_USER_PROFILE="$HOME/.profile"
Походу тильда ему не нравится.

[Djelf]

Ну так то ругаться на profile перестало, но все равно не поднимается.

[dimbor]

И у меня на сраную тильду ругается, но сессию восстанавливает.
В логах больше ничего пока не видно.