nxwin-3.[45].0-?-r14 -> NXClientCE-3.5.0-9-r15.? (Сколько ни болела, а начинает помирать.)

[dimbor]

Можно было сделать patch ПОСЛЕ моих действий с кодом, но я это не сделал специально из-за тебя, т.к. получится не patch, а diff и разгребать это будет, думаю, сложнее...

Все же для достижения просветления и всяческой нирваны пошел по длинному пути лечения горла. Для начала поставил задачу устойчивой сборки и пересборки под цигвином 1.7.14(0.260/5/3) оригинального кода !M. Извращался здесь. Потребовалось сделать несколько тривиальных и нетривиальных (nxesd) патчей, чтобы вообще собралось. В том числе твои CARD32. Без остального ты обошелся. У тебя точно gcc и g++ 4.5.3? Сумлевательно чо-то.

Дальше чудеса. Собралось, но теперь под XP без твоего сессионного патча имею устойчивое "Cannot initialize display service", т.е. оригинал не запускается. С патчем работает.

Пока не понял такую вещь. Раньше nxwin.exe при запуске мимо сессии вел себя как обычный x-сервер - вываливал черное окно и висел, пока не грохнешь. Сейчас - срубается.
Ладно, только он теперь в каталоге сессии свой winlog создает, но ничего туда не пишет. Все в .nx\temp\*\svclog из него валится. Совсем как у opennx. Меня лично это напрягает. Вроде от окружения (NX_TEMP) может зависить. Ты что-нить об этом знаешь?

Ладно, пока хватит - to be continued.

ЗЫ: cyggcc_s-1.dll и cygstdc++-6.dll теперь в обязаловке. Компиляторы под цыгвином пересобирать можно не буду?

[Djelf]

ЗЫ: cyggcc_s-1.dll и cygstdc++-6.dll теперь в обязаловке. Компиляторы под цыгвином пересобирать можно не буду?

Ну +1Мб... переживем...

>Потребовалось сделать несколько тривиальных и нетривиальных (nxesd) патчей
Тривиальные то ерунда, а к nxesd я даже не прикасался... мы его вроде никогда не пересобирали?

> Дальше чудеса. Собралось, но теперь под XP без твоего сессионного патча имею устойчивое "Cannot initialize display service", т.е. оригинал не запускается. С патчем работает.
На то и патч... nxwin через форк категорически перестал запускаеться.

> Пока не понял такую вещь. Раньше nxwin.exe при запуске мимо сессии вел себя как обычный x-сервер - вываливал черное окно и висел, пока не грохнешь. Сейчас - срубается.
На W7 64 сейчас посмотрел, срубается любой начиная с 3.3.0.6, новый без черного окна... Кажется, да, было... а надо?

> Ладно, только он теперь в каталоге сессии свой winlog создает, но ничего туда не пишет. Все в .nx\temp\*\svclog из него валится. Совсем как у opennx.
> Меня лично это напрягает. Вроде от окружения (NX_TEMP) может зависить. Ты что-нить об этом знаешь?
Упс! nxwin должен, судя по InitOutput.c: static void nxwinOpenLogFile(), пользоваться файлом %NX_TEMP%/winlog. NX_TEMP (я проверил) выставляется правильно...
Но nxwinOpenLogFile вызывается только их OsVendorInit, а OsVendorInit не вызывается вообще ниоткуда...
Похоже тут такая же история, как и с STORED_NXSERVER_VERSION т.е. nxclient OsVendorInit вызывает как-то по другому...

ну и ладно...

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

winwndproc.c
 if(message == stored_nxserver_version)
 {
    isToShowMessageBox = (BOOL)lParam;
+    OsVendorInit();
    return 1;
 }

и лог появится и под OpenNX .
В это место, потому что в коментах, в коде сказано, что лог должен быть переназначен после запуска nxwin, а сообщением STORED_NXSERVER_VERSION мы как после запуска nxwin его и пинаем.

[dimbor]

Тривиальные то ерунда, а к nxesd я даже не прикасался... мы его вроде никогда не пересобирали?

Пересобирал, как цигвин обновился. Он и так, говорят, не сильно работает, а с новыми библиотеками у него шансов нет вообще. А так может кто, кому будет нужно тра-ля-ля...
Пересобрался и ладно.

На W7 64 сейчас посмотрел, срубается любой начиная с 3.3.0.6, новый без черного окна... Кажется, да, было... а надо?

Ну не знаю. Он вроде под х-сервер косит со всеми опциями командной строки. Как-бы потом это не выползло в какой-нить бячке, которую будем долго и нудно.

Упс! nxwin должен, судя по InitOutput.c: static void nxwinOpenLogFile(), пользоваться файлом %NX_TEMP%/winlog. NX_TEMP (я проверил) выставляется правильно...
Но nxwinOpenLogFile вызывается только их OsVendorInit, а OsVendorInit не вызывается вообще ниоткуда...
Похоже тут такая же история, как и с STORED_NXSERVER_VERSION т.е. nxclient OsVendorInit вызывает как-то по другому...

Вызывается, иначе бы он не создавался нулевой длины. А вот потом stderr с него куда-то перенаправляется (кем-чем-как?).

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

winwndproc.c
 if(message == stored_nxserver_version)
 {
    isToShowMessageBox = (BOOL)lParam;
+    OsVendorInit();
    return 1;
 }

и лог появится и под OpenNX .
В это место, потому что в коментах, в коде сказано, что лог должен быть переназначен после запуска nxwin, а сообщением STORED_NXSERVER_VERSION мы как после запуска nxwin его и пинаем.

Так ты проверял или это только предположение?

[Djelf]

Так ты проверял или это только предположение?

А как же! Иначе бы и не писал.... Только вот в оригинальном OpenNX STORED_NXSERVER_VERSION не посылается, я Фрица я так и не убедил... есть в патче 03_win32exec.patch

[dimbor]

Опять запутался. Опенэныкс - вопрос второй. В оригинальном winlog вернуть так, как ты написал? Если да, то верну.

[Djelf]

Опять запутался. Опенэныкс - вопрос второй. В оригинальном winlog вернуть так, как ты написал? Если да, то верну.

Еще раз о STORED_NXSERVER_VERSION
!M то ли сделали тупенькую защиту от сторонних запускалок, то ли просто так им захотелось....
Без послыки WM_Message STORED_NXSERVER_VERSION NXWin клиент по кнопке завершения работы посылает сигнал завершения в Windows и мы видим 2 доступные конпки "Отменить/Закрыть", после посылки STORED_NXSERVER_VERSION nxwin передает сигнал завершения на nxserver и тогда мы получаем 3 конопки "Disconnect/Terminate/Cancel" т.е. чтоб работал Disconnect мы должны посылать сообщение в nxwin в обязательном порядке.
OsVendorInit из той же песни... только вызывается NXClient`ом неизвестным науке образом. Просто загоняем вызов OsVendorInit туда же, где идет инициализация стандартного поведения NXWin для закрытии окна. Вызывается это 1 раз после запуска nxwin, ничего нарушить даже теоретически не может, по коду: OsVendorInit вызывает nxwinOpenLogFile, а там идет перенаправление лог файла в %NX_TEMP%/winlog

Посылка STORED_NXSERVER_VERSION включена в патч для nxservice, т.е. с патченным и поведения закрытия окон и лог файл будут как в стандартном клиенте.

[dimbor]

Все понял: я твой старый nofork-patch использовал. Сейчас донакачу разницу.

[dimbor]

Вот как-то так. Пожалуйста, дальше не трамбуй несколько больших подвигов в один средний - карма супермена нарастает медленнее.

[dimbor]

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

winwndproc.c
 if(message == stored_nxserver_version)
 {
    isToShowMessageBox = (BOOL)lParam;
+    OsVendorInit();
    return 1;
 }

Оригинальный клиент. Увы, из svclog nxwin уходит, но winlog остается пустым. Плюс к этому по окончании сессии каталоги D-* и S-* не переименовываются в T-D-* и T-S-* как было раньше. Недопил однако.

Упс! nxwin должен, судя по InitOutput.c: static void nxwinOpenLogFile(), пользоваться файлом %NX_TEMP%/winlog. NX_TEMP (я проверил) выставляется правильно...
Но nxwinOpenLogFile вызывается только их OsVendorInit, а OsVendorInit не вызывается вообще ниоткуда...
Похоже тут такая же история, как и с STORED_NXSERVER_VERSION т.е. nxclient OsVendorInit вызывает как-то по другому...

Вызывается, иначе бы он не создавался нулевой длины. А вот потом stderr с него куда-то перенаправляется (кем-чем-как?).

Вопрос продолжает оставаться актуальным.

[Djelf]

Плюс к этому по окончании сессии каталоги D-* и S-* не переименовываются в T-D-* и T-S-* как было раньше. Недопил однако.

Увидел! Никогда не убирал галочку "Remove old session files"...
Скорее всего, где то hostname в строке генерации сессий не убрал... посмотрю...

Оригинальный клиент. Увы, из svclog nxwin уходит, но winlog остается пустым.
...
Вызывается, иначе бы он не создавался нулевой длины. А вот потом stderr с него куда-то перенаправляется (кем-чем-как?).

winlog создает nxservice, поэтому он всегда будет хотя бы нулевой, не знаю зачем, может им лень было это в nxwin прописывать создание файла... в нем кода побольше...
В вот с "Оригинальный клиент. " это что-то странноватое у тебя... ты уверен что используешь обе новые nxservice и nxwin?
Я все время запускаю из своего nxhelper (быстрее)... подумал он как то влияет, установил клиент, убрал хелпер, поменял библиотеки - winlog пустой, почесал репу, скомпилировал заново, заменил библиотеки -winlog не пустой... Значит те библиотеки что я менял до этого были из первой серии...

Может микро патчик для вывода в системный лог этих действий сделать?

P.S. в куче гита найдена крупица золота (с) Спасибо Denis Baranov!
собирается, (с тем же патчем на Cygwin 1.7) судя по загрузке процессора (я уже не понимаю как реально проверить скорость на клиенте при 100% загрузке теста на сервере) и по ощущениям, снижает нагрузку на nxssh на 5-10% Хотя это, наверное, все таки только желаемое ускорение, а не реальное

[dimbor]

В вот с "Оригинальный клиент. " это что-то странноватое у тебя... ты уверен что используешь обе новые nxservice и nxwin?

146%! В корневом fake-Makefile при install обновляется все, что собирается.
А вот библиотеки... Ты мне так про версии компиляторов и не ответил. Такое впечатление, что мы разные вещи собираем. Мне то больше патчить понадобилось, чтоб оно вообще заиграло. Попробую твоими библиотеками поиграться. Свою сборку могу выложить. Надо синхронизироваться как-то.

Может микро патчик для вывода в системный лог этих действий сделать?

С чем-то вроде #ifdef DEBUG почему бы и нет?

P.S. в куче гита найдена крупица золота (с) Спасибо Denis Baranov!
собирается, (с тем же патчем на Cygwin 1.7) судя по загрузке процессора (я уже не понимаю как реально проверить скорость на клиенте при 100% загрузке теста на сервере) и по ощущениям, снижает нагрузку на nxssh на 5-10%

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

[Djelf]

Надо синхронизироваться как-то.
...
Мы, эстонские программисты, и так ускорились по самое не могу. У стека задач может отвалиться дондышко.

ОК. Проверю сборку из твоего гита. У тебя на какой именно Win нету winlog? Тоже надо бы проверить...

Дык я так... написал чтоб не забыть что есть...

На самом деле, повторяю уже какой раз, не понятно как проверять..
Если у кого появится идея: как не нагружая сервер на 100%, проверить скорость клиента не молчите!

Сейчас тупо запускаю speedtest4 (с ползающими иконками в 1с 7.7) на тесте 100/1000, смотрю загрузку процессора и время на выполнение.
В принципе выжать удается не плохо... с 53с (Время ЦП) на оригинальном клиенте до 37с на замученном в усмерть клиенте... опции компиляции gcc не влияют вообще никак...кроме -fprofile-generate/-fprofile-use, они вроде работают... nxwin еще с ними не пытался мучать.
Но если 1С локально на тесте выдает минимум 0.33с, а в терминальном режиме удалось добиться минимума 0.42с - овчинка стоит выделки...

[Djelf]

winlog остается пустым.

Ну дур-дом... я не думал что строка отладки как-то влияет...

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

--- /home/addm/src/NXWIN_3.5.0-7/nxwin-dim/InitOutput.c
+++ /home/addm/src/NXWIN_3.5.0-7/nxwin-new/InitOutput.c
@@ -111,6 +111,8 @@
   const char *tempEnv = (char *) getenv("NX_TEMP");

   char *logPath = NULL;

+  fprintf(stderr, "Kick the log file to work winlog.\n");

   if (g_pfLog != NULL)
   {

по окончании сессии каталоги D-* и S-* не переименовываются в T-D-* и T-S-* как было раньше. Недопил однако.

С этим - хуже. Во первых, под W7 они и на родном клиенте очень плохо переименовываюся. Сначала поймал почти сразу, потом ловил раз 20... т.е. все равно не работает...
Переименование сессий делает nxservice, а nxwin напрямую его не вызывает. Видимо придется кусок кода из Service.cpp тащить в nxwin...

[dimbor]

ОК. Проверю сборку из твоего гита. У тебя на какой именно Win нету winlog? Тоже надо бы проверить...

Сборку то я выложу через несколько часов, да только оно получается все идентично твоей сборке (по крайней мере по размеру).
Нету лога под боевой ХР, которая оч давно не переставлялась и служила всему "курощению".
Так что, когда в stderr что-то сразу фигачить, потом все нормально?

[Djelf]

Так что, когда в stderr что-то сразу фигачить, потом все нормально?

Сам оболдел... Взял твою из гита - не работает! Стал по буквам проверять... а там я пытался что-то в лог писать, когда искал причину почему winlog не работает, но с работоспособностью это я не связывал...
Да, убераю строку - лог пустой, восстанавливую - лог есть, ерунда какая-то...

[dimbor]

Так будем разбираться, или зафигачим туда точку (".") и назовем это фичей?

[Djelf]

Так будем разбираться, или зафигачим туда точку (".") и назовем это фичей?

Не... пусть лучше для истории так останется сообщеним "Пинаем лог файл чтоб работал winlog", зато не забудем зачем оно

[dimbor]

Done. Я там колупаюсь потихонечку - повторяю, так сказать, пройденное. Давно надо было заняться, но пока не пнули...
Обнаружил очередную багу (нового цигвина?) - исторически использую программулю Ruslat95 для переключения языка под виндой по правому контролу. До сего момента в рутлесе тоже было все ок на эту тему. На новом клиенте - фиг! Зато почему-то работает стандартное виндовое Ctrl+Shift, хотя xkbdmap на сервере прописано rctrl_toggle. Чудо!

[Djelf]

Зато почему-то работает стандартное виндовое Ctrl+Shift, хотя xkbdmap на сервере прописано rctrl_toggle. Чудо!

Ой.... У меня на ubuntu 10.04 rctrl_toggle работает... но setxkbmap стал добавлять переключалки, вроде после запуска старые должны отключатся? Сейчас и ctr/shift и rctrl и caps заработали одновременно... странно... не помню чтоб так было... c setxkbmap вечно какие-то странные проблемы...

[Djelf]

А !M тоже иногда не спят... http://www.nomachine.com/news-read.php?idnews=371
Насчет Cairo я патчи в x2go видел... это тот случай, когда хвост кошки бежит впереди самой кошки (продукт за ++$ должен обновляться быстрее чем за 0$, IMHO)
А тут еще и сама кошка перегоняет свою тень, т.к. изменение библиотек уже заявлено но не выложено...
Понятно что выложат... в Win32 клиенте, судя по заявленным изменениям, они очень не велики. и это не удивлает.

[Djelf]

Очередное обновление NXClient до версии nxclient-3.5.0-9
Ничего интересного. Обновлен только NXWin до версии nxwin-3.5.0-4

То что там дальше написано

The following components were not updated since the previous 3.5.0 release:
nx-X11-compat-3.5.0-2

Это не верно. Т.к. nx-X11-compat доступен только в версии nx-X11-compat-3.5.0-1, а клиент определятся с "Render extension version 0.8".

[dimbor]

Сутки-трое так растянутся порою, ... до большого геморроя. Короче, тяжело в деревне без нагана. Догоняющему.
Окончил таки перекурочивать патчи, что вспомнил - выделил отдельно. Остальное - в куче. В том же гите, в той же ветке. Также добавил патч на nxssh. Собрал под цыгвином 1.7.15. Бинари, как водится, запаковал в архив NXClient_bin-3.5.0-7-nxwin-3.5.0-2-r14.5.rar. Тыц! Обозвано 14.5, т.к. адаптируется под новый цыгвин, да и плюшек от Djelf набралось порядочно. По идее должно получиться аналогичное уже выложенному, только оно не ёкнется через месяц, в смысле - будет продолжать скачиваться.
Присандалить инсталяшку (скрипт уже давно даден) опять не успел. Пока так. Зато обновиться до версии из предыдущего поста будет значительно проще.

c setxkbmap вечно какие-то странные проблемы...

Так точно! Это с ним новым проблемы, а я то уж на клиент/цигвин думал - на стареньких серверах переключает.

ЗЫ: У меня одного создалось впечатление, что мы тут в два лица сидим? Что сами готовим, то сами потребляем - замкнутый цикл. Но все сожрать не можем, поэтому большую часть приходится в помойку.

[dimbor]

А !M тоже иногда не спят... http://www.nomachine.com/news-read.php?idnews=371
Насчет Cairo я патчи в x2go видел... это тот случай, когда хвост кошки бежит впереди самой кошки (продукт за ++$ должен обновляться быстрее чем за 0$, IMHO)
А тут еще и сама кошка перегоняет свою тень, т.к. изменение библиотек уже заявлено но не выложено...
Понятно что выложат... в Win32 клиенте, судя по заявленным изменениям, они очень не велики. и это не удивлает.

Опять за кошку. Она может конечно и перегнала свои уши, но виндовому клиенту от этого не лучше. Исчезла отрисовка шрифтов. Совсем, любых. Исчезла только в сессиях вин-клиента. Под лин-клиентом все ок. Лечится откатом cairo на сервере с 1.12 до 1.10. То-есть ситуевина аналогична той-самой. Только ничего не крашится. Накат упомянутого патча ничего не дал. Это понятно - там про solid-pictures. Кстати без патча тоже ничего не крашилось. Может пикчи уменя недостаточно солидные?

В данный момент сижу-думаю тяжкую думку. Насколько же лень разбираться в этой cairo и выяснять ее связь с отрисовкой шрифтов. Хоть бы букварь кто подкинул штоль. А то если просто cairo отдифить, после многочасового гимора опять какой-нить грязный хак может выйти.

Upd: походу все сдались, или как?
Upd2: оно само рассосалось в версиях cairo >= 1.12-16

[dimbor]

NXClientCE-3.5.0-9-r15.0.exe

- то же самое, вид сбоку собрано под цигвином 1.7.35
- содержимое инсталятора аутентично оригинальному, потому как разобрано и собрано взад.
- новая nxcomp, которая там никуда не упирается, но пусть будет.

[dimbor]

NXClientCE-3.5.0-9-r15.1.exe

- cобрано под цигвином 2.0.0
- под рутлесом позиция окна приложения* сохраняется в реестре при закрытии и восстанавливается при открытии.

(*) /Чтобы не забыть./ При типичных условиях запуска этого самого приложения на сервере. Типичная Х-прога (мучался огнелис) при запуске рутлес решает, что DE с WM отсутствует и ставит свойству _NET_WM_STATE значения _NET_WM_STATE_MAXIMIZED_HORZ и _NET_WM_STATE_MAXIMIZED_VERT. Т.е. на сервере она как бы максимизирована, а у клиента на самом деле - нет. На наличии свойства и значений теперь строится идентификация корневых окон, позицию которых надо сохранять в реестр. Но вайн, например, ведет себя таким же образом, только если на сервере есть физически установленный DE.
А если его нет, свойство очищает. Окна становятся неотличимы от всяких диалогов, и сохраниться не могут. Зато тогда он работает со своим "реестром", и на выходе получается очень похожий результат.

[palexa]

windows-7 и NXClientCE-3.5.0-9-r15.1 (раньше на других клиентах это тоже было, просто не обратил внимания)

Есть постоянная проблема в том. что невозможно подключиться с первого раза, постоянная ошибка при подключении
Но подключение происходит после 2-3 попытки, детали здесь, скриншот прикрепляю

Spoiler

nfo: Display running with pid '4680' and handler '0x1603da'.

NXPROXY - Version 3.5.0

Copyright © 2001, 2011 NoMachine.
See http://www.nomachine.com/ for more information.

Info: Proxy running in client mode with pid '4528'.
Session: Starting session at 'Sat Sep 26 14:34:58 2015'.
Info: Connection with remote proxy completed.
Warning: Unrecognized session type 'unix-desktop'. Assuming agent session.
Info: Using LAN link parameters 1536/24/1/0.
Info: Using pack method 'adaptive-9' with session 'unix-desktop'.
Info: Not using NX delta compression.
Info: Not using ZLIB data compression.
Info: Not using ZLIB stream compression.
Info: Not using a persistent cache.
Info: Forwarding X11 connections to display ':0'.
Info: Forwarding auxiliary X11 connections to display ':0'.
Info: Forwarding multimedia connections to port '6000'.
Info: Listening to font server connections on port '12000'.
Session: Session started at 'Sat Sep 26 14:34:58 2015'.
Error: Connection with remote peer broken.
Error: Please check the state of your network and retry.
Session: Terminating session at 'Sat Sep 26 14:34:58 2015'.
Session: Session terminated at 'Sat Sep 26 14:34:58 2015'.

[dimbor]

- nxnode на сервере точно отсюда (размер 91711)?

- в /etc/nxserver/node.conf.d/01-auth.conf ENABLE_USERMODE_AUTHENTICATION отключена? А ENABLE_SLAVE_MODE? Что там стоит: ENABLE_SU_AUTHENTICATION или ENABLE_SSH_AUTHENTICATION? А если сменить, картина будет та же?

- И глянуть бы на клиенте winlog из каталога D-*. Там как раз и написано, как работает NXWin, и что ему может мешать.
А то, что было опубликовано, оно из каталога S-*, и в данном случае неинформативно.

- Еще может быть банально-нервная причина. Если закрыть окно приложения - "завершить сессию", и сразу же запускать ее снова, будет именно так. Потому что реально завершается она до 30 секунд. И в это время подключения к ней заканчиваются обломом. В x2go нагородили костылей вроде за эту бяку. В nx так же делать не хочется, хочется делать правильно. Дозреваю активно, т.к. нервные юзеры реально парят.

[palexa]

nxnode - заменил,
Клиент поставил OpenNXCE

Вроде пока этой проблемы не наблюдаю

[dimbor]

NXClientCE-3.5.0-9-r15.2.exe

• Вроде окончательно разобрался с начальным позиционированием рутлеса: Все сделано одновременно как можно ближе к ICCCM и freedesktop.org (ну с учетом предыдущих извращений). Для большинства приложений должно работать с сохранением позиции окон либо клиентом в реестре, либо иксами на сервере. /В первом случае максимизированное окно открывается таковым и восстанавливает позицию в сохраненную нормаль. Во втором же - окно открывается только растянутым под максимизированное, и тыкание кнопсы максимизации/восстановления визуальных результатов не дает./
• Включил в пакет дополнительные шрифты от номашин,. Посему пакет распух. По поводу возможного нарушения каких-то лицензий париться не стал. Я ж его не продаю, в самом-то деле.

[dimbor]

NXClientCE-3.5.0-9-r15.3.exe

• Кто про что, а я - опять про 1с. Платформа 8.2 отошла в прошлое - обновления типовых работать перестали. Пересадил всех терминальщиков под нативный клиент 8.3 и обнаружил, что попапы в рутлес nx-сессии там зело гадостно выскакивают, с рамкой и кнопками. Долгое курение всяческих свойств окон результата не дало - тама видимо на nxagent-е что-то режется опять. Разбираться лень, как обычно. Посему был вырожден очередной кривой хак именно для окон, зовущихся "1cv8". Вроде работает.