Bug 29986

ssh клиент с какими параметрами запущен?

(В ответ на комментарий №1)
> ssh клиент с какими параметрами запущен?
Ой, да, vnc же.

А другие программы там из-под _root_ показывают? qtconfig-qt4 и Konqueror, например.

просто правой кнопкой - консоль, затем su - , затем acc
все!

Насчет других программ - точно не все, на некоторых - такая же проблема
указанные:
 конкверор - работает из под пользователя, из под root нет!
 
вот из под рута:
[root@srv ~]# qtconfig-qt4
X Error: BadAccess (attempt to access private resource denied) 10
  Extension:    130 (MIT-SHM)
  Minor opcode: 1 (X_ShmAttach)
  Resource id:  0x11c
X Error: BadShmSeg (invalid shared segment parameter) 128
  Extension:    130 (MIT-SHM)
  Minor opcode: 5 (X_ShmCreatePixmap)
  Resource id:  0x168
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x4e00012
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x4e00012

qtconfig-qt4 так себя ведет и локально тоже или только удаленно?

локально - не могу проверить ибо сильно далеко, просто вчера был там и заметил, что удаленно не работает, попробовал локально заработало, настроил время и забыл. Сегодня полез ан нет.
Проверю qtconfig-qt4 локально только завтра!

А удалённо qtconfig-qt4 как работает ?

версия xorg-server какая, кстати?

qtconfig-qt4 пользователем нормально, рутом просто окно, вывод в консоли я уже показывал!

xorg-server-common-1.14.5-alt3

(В ответ на комментарий №10)
> qtconfig-qt4 пользователем нормально, рутом просто окно
Попробуйте удалить /root/.config/Trolltech.conf
если не поможет, заполните /root/.config/Trolltech.conf содержимым:
[Qt]
style=Windows

Ни удаление, ни добаление 
> [Qt]
> style=Windows
Ни к чему не привело!

Даже попробовал, подставить Trolltech.conf от пользователя которым запускается!
В результате ничего не меняется!
Локально на сервере все работает!

Наблюдаю это на всех серверах на P7 в пределах доступности! Все обновлены максимум неделю назад!

(В ответ на комментарий №12)
> Ни к чему не привело!
Все те жа ошибки про  BadAccess и BadShmSeg ?
Настраивайте X-ы, VNC, NX и Windows тогда.

P.S.
Или пользуйтесь alterator через http.

Через SSH тоже работает.

> Настраивайте X-ы, VNC, NX и Windows тогда.
А что настраивать-то? Мне не совсем понятно кто виноват вообще.
Может я баг не на тот компонент повесил, но делал по рекомендации Черепанова.
Через http не все модули доступны :(
 
Так NX через ssh  и подключается!

Тогда на nx. GTK-приложения запускаются?

(В ответ на комментарий №17)
> Так NX через ssh  и подключается!
У меня X-клиент на машине с acc работает через SSH c X-сервером на компьютере админа.

  ssh -X nxserv.strterm
  su -
  acc
В таком виде и у меня работает!

В удаленном рабочем столе все что не требует рутового логина работает.
Как только требует gksu или просто из консоли su -
Qt4 окна с пустым содержимым.
Теперь собственно вопрос кто виноват? Почему раньше работало?

и это, почему компонент nx?
Под vnc сессией - тоже не работает.
ИМХО виноват Qt4, ибо такая же картина наблюдается на чисто установленном кентавре сервере, в умолчальном DE (не помню кто там, самый простейший), без всякого NX только VNC рабочий стол, на котором админятся виртуалки (виртуалбокс)

При rdp на машину в VirtualBox работает.

А почему это не баг?
И при чем здесь rdp в виртуальную машину.
Ставим сервер Cetaurus 7.0.4, 
Далее ставим:
  apt-get install tigervnc-server
настраиваем сервер в /etc/sysconfig/vncservers затем задаем пароль:
  su -l user
  vncpasswd
Стартуем 
  service vncserver start
Подключаемся любым vnc клиентом и запускаем acc
Видим отсутствие элементов внутри окна.
Повторяем это, только настраиваем nxserver (который работает из коробки)
подключаемся nxclient, запускаем acc и видим пустое окно.
Локально, на сервере запускаем startx затем acc - видим все модули альтертаора на месте.
Ставим x11vnc, запускаем, подключаемся удаленно к локальному рабочему столу через vnc, запускаем acc видим все модули на месте.
ИТОГ : если мы хотим запустить acc на удаленной openvz машине - иного выхода как через ssh -X - нету!
Я не поленился и попробовал все эо и на сизифе - результат аналогичный!
Если я не прав и это фича - то чья и зачем?

аналогичным образом не работает dolphin и krusader из под root

vnc:/ через krdc у меня тоже работает.
Перевесьте на tigervnc-server, если хотите. Его и nx не пробовал.

Так KRDC (точнее KRFB) не создают виртуального рабочего стола, а подключается к существующему экземпляру xorg, так действительно работает. 
Если считаете, что надо перевесить на vnc сервер, я не против, только дело-то скорее всего не в нем!

Я пробовал vnc и к qemu и к krfb. Это у меня работает.

я воспроизвёл эту проблему, похоже всё-таки виноват tigervnc-server. 

Какое-то из новомодных расширениё не работает. Надо обновить попробовать пакет.

В плане Qt можно попробовать, разве что, запускать
QT_GRAPHICSSYSTEM=native программа

попробовал под рутом QT_GRAPHICSSYSTEM=native acc - работает
т.е. - с высокой долей вероятности поможет обновление tigervnc-server.

А как быть с nx ?
И почему одна и та же проблема воспроизводится и в nx и в tigervnc?
> QT_GRAPHICSSYSTEM=native программа
действительно работает и под nx и под vnc

это обход!!!

с NX тоже самое. xorg и qt убежали сильно вперёд.

Кому интересно: 
http://blogs.fsfe.org/micuintus/2010/09/03/how-to-drastically-boost-up-your-kde-4-performance-by-using-the-qt-raster-rendering-engine/

а тут есть примеры настройки для всего KDE.
http://apachelog.wordpress.com/2010/09/05/qt-graphics-system-kcm/

Честно говоря не совсем понятно, почему оно работает под пользователем, и не работает под рутом. Какие-то нюансы работы с shared memory при X-сервере, запущенном под пользователем - честно говоря вникать в это не очень хочется.

Обновление tigervnc всё-таки может исправить ситуацию.

И тогда еще один вопрос, а где задать переменную  QT_GRAPHICSSYSTEM
по умолчанию для всех. 
К делу не относится, но 1с-ка запущенная с  QT_GRAPHICSSYSTEM=native - интерфейс живее раза в 2 !!!

(В ответ на комментарий №34)
> QT_GRAPHICSSYSTEM=native - интерфейс живее раза в 2 !!!
По сети всё, что слинковано с Qt будет живее так. Локально живее с QT_GRAPHICSSYSTEM=raster, что у всех по умолчанию. В KDE4 отдельная настройка есть в `kcmshell4 kwincompositing` во вкладке "Дополнительно".

(В ответ на комментарий №34)
> И тогда еще один вопрос, а где задать переменную  
> QT_GRAPHICSSYSTEM по умолчанию для всех. 
/etc/profile.d/

*** Bug 30477 has been marked as a duplicate of this bug. ***

Cennaurus 7.0.4
Добавляем /etc/profile.d/qt.sh такого содержания
export QT_GRAPHICSSYSTEM=native
проверяем от пользователя
[admin@alttest ~]$ env| grep QT
QT_GRAPHICSSYSTEM=native
Через NX acc не работает ни с какой QT_GRAPHICSSYSTEM, ни native ни raster. Через ssh -X работает с любой.

Работает такой вариант (понятно, только для пользователя из группы wheel):
$ su -
# QT_GRAPHICSSYSTEM=native acc

Используйте
/root/.bashrc
и
gksu -lu root acc

> /root/.bashrc
Да, логично. Давайте подумаем, не тянет ли это на патч. Что-то вроде 
- export USERNAME ENV PATH
+ export USERNAME ENV PATH QT_GRAPHICSSYSTEM=native

> gksu -lu root acc
Проверил, для acc годится. Предлагаю на FAQ: "Особенности работы в терминальном доступе".

(В ответ на комментарий №41)
> > /root/.bashrc
> Да, логично. Давайте подумаем, не тянет ли это на патч.
Не тянет.

> Предлагаю на FAQ: "Особенности работы в терминальном
> доступе".
По любому туда. Это справедливо для любого Qt4-приложения, т.к., как-минимум, ускорит его работу.

Для информации:

У меня такая же проблема с firefox через ssh -Y из-под xorg-server-1.14.5-alt3 -- https://bugzilla.altlinux.org/show_bug.cgi?id=32370 . Правда, некоторые запуски успешны, а многие падают.

Не знаю кто повлиял, но в p8 и в сизифе больше не наблюдается