Linux. Падает ragent при подключении консолью администрирования #509622

Имеем CentOS 5.5 amd64, сервер v8.2. Запускается нормально, но при попытке подключения вываливается ошибка - конечный хост выключен и из процессов пропадает ragent.

Изначально стоял и сервер 1С x86-64, к нему подключалось, создавались базы нормальноо, но как позже выяснилось ключ у нас для 32-битной 1С. Снес 64, поставил 32.

А логи он пишет? Как узнать-то почему падает? Кстати, без ключа сервер вообще не запускался. Установил HASP_SRM_LINUX_3.50_RedHat_RPM_Run-time_Installer, вставил ключ, теперь запускается, но падает.

Попробуйте удалить в каталоге пользователя /home/usr1cv82/.1cv82/1C/1Cv82 все,что там есть, перезапустить сервер приложений и заново создать центральный сервер консолью администрирования. Ну и информационные базы, рабочие процессы, если их несколько... В каталоге /tmp тоже желательно почистить все файлы и каталоги, имеющие отношение к серверу приложений 1С.

Пробовал. Снес сервер, удалил пользователя вместе с группой и домашней папкой, т.е. начисто и снова установил, права дал chown -R usr1cv82:grp1cv82 /home/usr1cv82 /opt/1C - все тоже самое. Создаю центральный сервер и при попытке зайти на него (на плюсик нажимаю) он валится. amd64 сервер встал вообще без плясок, тупо rpm -ivh * из папки с пакетами. Напрашивается вопрос: а этот i386 сервер 1С вообще работает на amd64 операционках?

а ты все 32битные либы поставил?

а то в 1с очень любят забыть пару-тройку зависимостей у RPM

да и вообще - неплохо бы запустить не как сервис, а просто как программу и посмотреть предсмертный вопль

[usr1cv82@srv1c ~]$ /opt/1C/v8.2/i386/ragent 1C:Enterprise 8.2 (8.2.12.87) Server Agent started. Ctrl+C to exit. При попытке коннекта пишет: "Ошибка сегментирования"

а какие нужны?

ставь все, или спроси у тех поддержки 1с

Наверное, не работает... Для i386 AMD64 не указывется, только Интел.

а какая немия ставить модули и приложения 32-х на 64-х ?

конечно, просто не логично указывать в требованиях для х86 софта x86-64 систему =) все знают, что у х86-64 есть режим обратной совместимости, тогда почему же не пашет? на этой же железяке еще СУБД будет и к тому же там 8 гигов мозгов и ксеоны 64-битные, поэтому 32-бита там не уместны тем временем пробежался по выданным либам rpm -qR 1C_Enterprise82-common-8.2.12-87 также и для сервера - все что требуется установлено в 2х экземплярах - для 32 (/lib) и для 64 (/lib64) скрипт /opt/1C/v8.2/i386/utils/config_server молчит, видимо на его взгляд все ок

На Intel Xeon и CentOS 5.5 x86_64 32-разрядый сервер приложений работает несколько месяцев. Устанавливался тоже без проблем. Стоит последняя версия - 8.2.12.87. Сейчас не поленился и установил платформу 1С( ту же) на комп с 4-х ядерным AMD Phenom (ОС такая же). Центральный сервер и информационные базы создаются, ничего не падает. Ключ тоже 32-х разрядный. Мое предположение в было неверным...Я имел ввиду, что в требованиях для 32х сервера приложений AMD процессоры не указаны вообще, а для 64-х указаны...

натрави ldd последовательно на все файлы 1совские выполняемые файлы, оно покажет, каких либ не хватает

Может быть попробовать сделать chown -R root:root /opt/1C и так запустить?

всеж разьясните великий смысл установки 32-х компонент при доступности 64-х

ключ от 64битного сервера стоит в 2 раза борльше, чО.

вот теперь понятно но тогда не просче 2 сервера воткнуть ?

не помогло (( [root@srv1c i386]# ls -lF |grep '*' | grep -v '.so' -rwxr-xr-x 1 root root    34652 Сен 16 16:38 ragent* -rwxr-xr-x 1 root root    34652 Сен 16 16:38 rmngr* -rwxr-xr-x 1 root root    34648 Сен 16 16:38 rphost* [root@srv1c i386]# ldd ragent

Попробуй запустить ragent -debug У меня на опытном компе ругался на отсутствие libfreetype, но все равно работал и сервер и базы создавались. Результат вывода ldd такой же.

[usr1cv82@srv1c ~]$ /opt/1C/v8.2/i386/ragent -debug 1C:Enterprise 8.2 (8.2.12.87) Server Agent (debug) started. Ctrl+C to exit. Ошибка сегментирования собственно, так же как

странно ldconfig, хотя вряд ли...

прописывал /opt/1C/v8.2/i386 и в LD_LIBRARY_PATH, и в ld.so.conf ибо на некоторые .so выдавал такое [root@srv1c i386]# ldd rserver.so [root@srv1c i386]# locate stl82.so /opt/1C/v8.2/i386/stl82.so [root@srv1c i386]# locate core82.so /opt/1C/v8.2/i386/core82.so и после прописки путей все= not found

снес 32, поставил 64 [root@srv1c 1C-amd64]# ldd /opt/1C/v8.2/x86_64/rtrsrvc.so but it's working! wtf? но все же почему у меня такого нет? stl82.so (0xf7b19000) core82.so (0xf7625000)

посоветовали прогнать через отладчик, имеем [usr1cv82@srv1c ~]$ gdb /opt/1C/v8.2/i386/ragent GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <; This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.  Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <;... Reading symbols from /opt/1C/v8.2/i386/ragent...(no debugging symbols found)...done. Starting program: /opt/1C/v8.2/i386/ragent [Thread debugging using libthread_db enabled] [New Thread 0xf5cdeb90 (LWP 10430)] 1C:Enterprise 8.2 (8.2.10.82) Server Agent started. Ctrl+C to exit. [New Thread 0xf4b72b90 (LWP 10431)] [New Thread 0xf4171b90 (LWP 10432)] [New Thread 0xf3770b90 (LWP 10447)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf3770b90 (LWP 10447)] 0xf4e5ddb8 in ?? from /opt/1C/v8.2/i386/rtrsrvc.so (gdb) quit A debugging session is active.        Inferior 1 [process 10427] will be killed. Quit anyway? (y or n) y вижу знакомую ошибку, вижу модуль, что дальше - хз

если сравнить и с , то получается, что у тебя 32х версия платформы использует тот же набор библиотек, что и 64х версия (с учетом разрядности),вернее, lld так думает , правда, непонятно почему. Попробуй после сноса 64х версии запустить ldconfig для обновления /etc/ld.so.cache, а потом установить 32х версию. И потом у тебя стартует только Server Agent, а Cluster Manager и рабочий процесс - нет. root:i386> ./ragent 1C:Enterprise 8.2 (8.2.12.87) Server Agent started. Ctrl+C to exit. 1C:Enterprise 8.2 (8.2.12.87) Cluster Manager started. Ctrl+C to exit. 1C:Enterprise 8.2 (8.2.12.87) Working Process started. Ctrl+C to exit. 1C:Enterprise 8.2 (8.2.12.87) Working Process terminated. 1C:Enterprise 8.2 (8.2.12.87) Server Agent finished.

кластер и рабочий процесс не созданы поэтому rmngr и rphost не стартуют, но если я закину в ~usr1cv82 сбэкапленную папку с конфигами, где все это создано, то после Server Agent сразу вываливается ОшСег, без попытки подключения. Видимо валится при попытке запуска rmngr. Сделал такую весчь: т.е. часть модулей закэшировалось, а часть нет.. норма ли это? может система эти файлы вообще за модули не считает :) можете проделать тоже самое у себя и закешируются ли они у вас? но все зависимости от того, прописан ли путь в ld.so.conf или нет, модули stl82.so и core82.so видятся, ибо, имхо, они же в одном каталоге [root@srv1c i386]# ldd rmngr я уж не знаю, туда ли я копаю вообще

не просче не парясь завиуртализировать 32-х разрядную систему под это ?

так я вообще до виндов скачусь =) да и коллега-то сообщает, что у него все тип-топ =)

сейчас попробую или переустановить существующую...

да, то же самое

закладка

Вчера вечером взял пару пива и развернул всю эту кухню дома на ноуте - все взлетело четко и без ошибок. Наблюдения: - В вы были правы, должны стартовать 3 процесса. На ноуте так и было, а на работе только ragent. - Поднялось все без ключа и его драйвера. На работе выдернул ключ и сервер не стартовал пока не положил хасп (aksusbd). Но все же пока не стоит доверять в полной мере тому, что происходит на сервере :) - если rm -rf /home/usr1cv82/.1Cv82 то после рестарта сервиса содержимое каталога заново создается. Это srvribrg.lst (с текстом "локальный кластер" и т.д.), conn8211.pfl, каталог reg_1541 и еще что-то. На работе же создается только srvribrg.lst и то практически пустой. И дело не в правах - от рута тоже самое. Далее пытался провоцировать на ошибки: ставил 64 (тоже пашет исправно), сносил ее, удалял пользователя, ставил снова 32, в общем всяко-разно - и никаких ошибок. Разница в железе, установленных пакетах (эту я подровнял удалив часть на сервере) и установленной DB2 на сервере, которая тоже сейчас пойдет под снос. Т.о. дело идет к переустановке и сабж может так и остаться загадкой :)

В /root/.1cv82 тоже создается и там при старте агента тоже создаются файлы. Попробуй еще rpm -q --provides 1C_Enterprise82-server-8.2.12-87, ну и для common пакета... Может после сноса 64х версии запустить ребилд базы rpm, хотя не знаю, поможет ли...

--provides показывает возможности пакета (с)man. Но мне он показал файлы, которые он установил. Я тут припоминаю, что изначально у меня был только 1Совский диск, там только x86 версии и ставил я эту ее, ведь тогда еще я не подозревал, что существует и x86_64. Вроде как 32битная у меня сразу не поперла, точно помню какие-то ошибки были, а когда полез за обновлениями увидел 64, подумал ну и отлично, и слил ее. Поэтому думаю, что 64битная не могла так нагадить, да и на ноуте после нее все нормально.

+ на ноуте было также как

Значит, пакеты ни при чем, видимо что-то с системой случилось после неудачной установки 32х версии

Переустановка системы не помогла - все тоже самое :)

Хм... То есть, на полностью переустановленную систему сразу была поставлена 32х версия без ошибок при инсталляции? А состав железа можно подробнее озвучить? Сам случай интересный...

Ну ошибка была при установке пакета сервера - постинтсалл-скрипт не смог запустить сервер. Intel Server System SR2600URBRP LSI SAS 9211-8i (4 винта в 10 рейде и 1 так - на нем система) 4 планки по 2 гига DDR3 PC-10600 2 ксеона E5506 Сейчас курю ман по опциям биоса

Такое иногда бывало, но потом, при рестарте, запускалось нормально. Может имеет смысл обновить биос до последней версии

- обновление биос не помогло - отключение тоже не помогло

Пробовал на разных материнских платах с Intel 5000P chipset и Intel Xeon 5355 и 5420, вся память - DDR2 667 МГц, платы от SuperMicro. Как вариант для эксперимента - поставить 32-х разрядную CentOS. А систему обновляли? Там со времени выхода релиза уже несколько раз ядра обновлялись...

Ставил ванильное ядро на 64х разрядную, ставил 32х разрядный centos и на нем собирал последнее ядро - все тоже самое. А вот на дебяне сервер завелся.

Не то чтобы похожий случай, но все же... Получается, что это результат работы CentOS именно с этой материнской платой, или с памятью DDR3(или процессором Xeon 55XX), или их совокупность так влияет. Сегодня, кстати, обновил CentOS - опять обновили glibc и ядро...