8.2 Debian. Падает ragent при подключении консолью администрирования 2 #591081

В форуме была встретилась похожая проблема c небольшими отличиями. Итак: Обновил платформу на 8.2.15.289 и она у меня перестала запускаться.  Немного покопав уперся в следующее: Запускаю ragent (из под рута или из под usr1cv82), рагент запускается. Пытаюсь подключиться консолью администрирования и ... Segmentation fault. -Файл с логами пустой. -Пробовал чистить /home/usr1cv82 и /tmp -config_server проходит без ошибок -После config_server делал chown usr1cv82:grp1cv82 /opt -R -у меня 32-bit система(64 нет вообще) -У меня нет ключа сервера. (Ограничение на 10 чел не убрали я надеюсь?)Пробовал выключать haspd(Etersoft) -До обновления  работала 8.2.14.528, пробовал доступную ныне 8.2.14.540 такая же проблема(segmentation failed). -ОС Дебиан 6 32 бита обновленная Как поставить диагноз?

сколько ж вас извращенцев развелось... Пользуются под(д)елками под ось, а потом жалуются...

2 вот когда ты принимал решение использовать 1С на линуксе, как ты себе рисовал как ты будешь справляться с проблемами, если они возникнут?

Как по делу то. Это оффтоп ребята. Не надо завидовать. На винде любой дурак поставит.

Как-как... Задвать на форуме вопросы... Ибо близлежащей гуры под рукой нет...

2 а на линуксе этот любой дурак побежит на форум спрашивать? Чувак - наш пойнт - разберись и доложи.. все будут тебе блогадарны, я нажму галочку и втоя ветка пойдет в базу знаний.

а в винде все работает как часы... видимо фуфло этот ваш линукс...

Поздравляю, ты близок к просветлению :-)

это не линь фуфло, а сервер 1с под линем

ты ещё скажи, что линь рулезьььь

OFF: к слову, о "галочках". Когда ставишь - потом проверяй результат. У тебя в паре веток были промахи ("галочка" на бессмысленном посте). Возможно, это движок сайта глюкал - но всё-таки лучше проверять).

FFFFFFFFFFFFFFUUUUUUUUUUUUUUUUCK! Почему такого количества бессмысленных комментов небыло в той теме? Создайте отдельную тему и там решайте кто рулез.

(6,8,9) чуваки - у вас с последнего линуксосрача действительно  появились какие-то НОВЫЕ аргументы, или мы сейчас будем слушать старые? 2 нет это не были промахи, я делал это сознательно.  другой вопрос почему.

повторенье - мать ученья...

Это был барабашка, определенно. Я запустил ragent от релиза 8.2.14.528 подключился telnet 127.0.0.1 1540 и Segmentation fault при тех же условиях не вылетел. После этой процедуры версия ragent от 8.2.15.289 работает нормально. (Сервер запускаеится и работает) Жаль что сервер 1с не OpenSource. P.S. Попробовал поставить продукт Posgre@etersoft 9.0.4. База создаваться в нем отказалась. (Как обычно отказывается, когда постгря не пропатчена). Зашёл на сайт 1С и увидел, что последняя версия постгри 9.0.3-3. Поставил официального дистрибутива - база создалась. Это такая шутка от Ethersoft?

наверное, у линь-сервера 1с тоже где-то должен лежать кэш?

Хмм... только если в памяти (сервак в течение всей процедуры не перезагружал). Всё остальное доступно только в /home/usr1cv82 ну и в /tmp

2 можешь написать еще сюда: у чуваков тоже вроде такое было и решения не было

А я уже туда написал, только в старой форме. Когда ещё недопер, что это SF. И на этом форуме было, тут даже ссылка есть. Если бы 1с сервер был OpenSource таких бы приколов небыло. (Если бы у бабушки были яйца...)

Барабашка вернулся! Теперь с Segmentation fault вылетает rmngr Отладка с gdb показала следующее: Program received signal SIGSEGV, Segmentation fault. 0xb3ee9f8b in ?? from /opt/1C/v8.2/i386/rtrsrvc.so Да, проблемы были: # ldd /opt/1C/v8.2/i386/rtrsrvc.so    linux-gate.so.1 =>  (0xb7896000)    stl82.so => not found    core82.so => not found    libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb6ed8000)    libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb6ebf000)    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6ea1000)    libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6e9d000)    libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6d57000)    /lib/ld-linux.so.2 (0xb7897000) Добавил путь: LD_LIBRARY_PATH=/opt/1C/v8.2/i386                                                                                       export LD_LIBRARY_PATH Стало так: # ldd /opt/1C/v8.2/i386/rtrsrvc.so    linux-gate.so.1 =>  (0xb7788000)    stl82.so => /opt/1C/v8.2/i386/stl82.so (0xb6de4000)    core82.so => /opt/1C/v8.2/i386/core82.so (0xb67fa000)    libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb67c8000)    libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb67af000)    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6791000)    libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb678d000)    libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6647000)    librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb663d000)    libicui18n.so.46 => /opt/1C/v8.2/i386/libicui18n.so.46 (0xb6463000)    libicuuc.so.46 => /opt/1C/v8.2/i386/libicuuc.so.46 (0xb6330000)    libicudata.so.46 => /opt/1C/v8.2/i386/libicudata.so.46 (0xb54b0000)    /lib/ld-linux.so.2 (0xb7789000)    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb53bb000) Проблема осталась: Program received signal SIGSEGV, Segmentation fault. 0xb3ee9f8b in ?? from /opt/1C/v8.2/i386/rtrsrvc.so Буду по очереди пробивать библиотеки.

Скопировал полностью линуксовый сервак на виртуальную машину - работает, ошибка сегментирования не вылетает. Я в шоке. У нас общее с тем чуваком, чья статья была ранее, у нас AMD Phenom. Я ещё в добавок воспользовался Core Unlocker, и превратил X2 в X4. Когда будет возможность перезагрузить ящик отключу эту функнию. Даже не знаю, что делать, благо 1с сервер на этой тачке в эксперементальных целях. Откатываться назад видимо, апдэйтить ядро и смотреть биос.

ну и ради прикола попробовать на Интеле.

Попробовал, правда на CentOS. 6.2 - на Xeon E7-4870(chipset E7500) и на AMD Phenom 9850, 5.7 - на Xeon 5420. И ОС и 1С и Postgres - x86_64. Устанавливается, работает.

Мой орган, которому я доверяю чувствует, что на данном серваке, на 64-х битном дистрибутиве платформа заработает. У меня на 64-битном проце 32х битная ось. Возможности проверить наверняка нет, так как сервер работает всё время.