Помилки при роботі з 1С-Бітрікс

1. Брак оперативної пам'яті.
2. Сервер не може стартувати через помилки в конфігурації.

Якщо після перенесення ви бачите на головній сторінці замість новин форму для авторизації і всі пункти меню позначаються як замка:

... і після авторизації все відображається правильно - перейдіть в адміністративну панель Бітрікс і пройдіть по шляху: Налаштування (Settings) → Налаштування продукту (System settings) → Сайти (Sites) → Список сайтів (List of sites), виберіть ваш сайт і перевірте значення поля «шлях до кореневої папці веб-сервера для цього сайту (Path to the web server root folder of this site)», швидше за все там вказано неправильний шлях.

Рекомендується залишити це поле порожнім якщо ви не використовуєте Многосайтовий на різних доменах.

Якщо у вас виникли складності, не описані тут, напишіть нам на [email protected]

За замовчуванням всі сервіси віртуальної машини VMBitrix працюють в кодуванні UTF-8. У порівнянні з кодуванням CP1251 (Windows-1251) UTF-8 надає великі можливості по зберіганню інформації на різних мовах, докладніше можна дізнатися в Wikipedia .

Якщо з яких-небудь причин ви не можете перейти на використання UTF-8 - виконайте вказаний запит самостійно.

Для цього перейдіть в адміністративний розділ Бітрікс і пройдіть по шляху Налаштування (Settings) → Інструменти (Tools) → SQL запит (SQL query), скопіюйте та вставте запит з повідомлення про помилку і виконайте його.

Цей запит змінює властивість використовується бази даних, не зачіпаючи самі дані, і, при необхідності, ви можете повернути старе значення назад.

Якщо у вас виникли складності, не описані тут, напишіть нам на [email protected]

При спробі оновити пошуковий індекс вашого сайту процес зависає (триває дуже довго і статус вже переіндексувати документів не оновлюється). Якщо виробляти переіндексацію по окремих модулів - зависання відбувається тільки при виборі модуля «Статичні файли».

Для вирішення проблеми необхідно змінити параметри mbstring в файлі /etc/php.ini:

mbstring.func_overload = 0 mbstring.internal_encoding = CP1251 і перезапустити web-сервер Apache щоб нові параметри вступили в силу: /etc/init.d/apache2 restart

Якщо у вас виникли складності, не описані тут, напишіть нам на [email protected]

The script encountered an error and will be aborted. To view extended error messages, enable this feature in .settings.php.

У новому ядрі Бітрікс, настройка параметрів проводиться в файлі bitrix / .settings.php (зверніть увагу, що ім'я файлу починається з крапки). Раніше, для цих завдань використовувався файл bitrix / php_interface / dbconn.php.

За замовчуванням, Бітрікс приховує будь-які повідомлення про помилки, так як це значно знижує рівень безпеки системи. Тому при виникненні будь-якої помилки замість неї буде відображатися вказане вище повідомлення.

Тому перш за все, необхідно увійти на сервер (по SSH або sFTP ) І відредагувати файл bitrix / .settings.php. У ньому слід знайти рядок:

'Debug' => false, і змінити значення параметра debug на true, тобто рядок повинна прийняти вигляд: 'debug' => true,

Після цього, при зверненні до сторінки з помилкою, ви побачите повне повідомлення про помилку. Після виправлення помилки, не забудьте повернути параметр debug в початкове значення.

Болле докладний опис всіх параметрів файлу .settings.php є на сайті розробника .

Якщо у вас виникли складності, не описані тут, напишіть нам на [email protected]

DB query error. Please try later.

Ця помилка абсолютно аналогічна описаній вище , Але виникає тільки в старому ядрі Бітрікс. Для включення виведення повного сообшенія про помилку увійдіть сервер (по SSH або sFTP ) І відредагуйте файл bitrix / php_interface / dbconn.php. У ньому знайдіть рядок:

$ DBDebug = false; і змініть значення змінної $ DBDebug на true, тобто рядок повинна прийняти вигляд: $ DBDebug = true;

Після цього, при зверненні до сторінки з помилкою, ви побачите повне повідомлення про помилку. Після виправлення помилки, не забудьте повернути параметр $ DBDebug в початкове значення.

Якщо у вас виникли складності, не описані тут, напишіть нам на [email protected]

Mysql connect error [localhost, 127.0.0.1]: Can not connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (2) (400)

Дана помилка означає, що сервер баз даних MySQL не доступний. Це може статися в ряді випадків і часто потрібен окремий аналіз ситуації для виявлення точної причини. Але в більшості випадків ця помилка виникає через наступних проблем:

1. Брак оперативної пам'яті.

   Якщо при розробці проекту не розраховувалася велике навантаження (з боку користувачів або обсягу оброблюваних даних), або при розробці була допущена помилка, або параметри MySQL і Apache не оптимальні для проекту, то при сплеску активності може виникнути переповнення оперативної пам'яті (RAM). В цьому випадку, операційна система, для підтримки власної безпеки, примусово завершує роботу самого об'ємного процесу (для web-серверів це як правило саме MySQL).

   В цьому випадку, в системному журналі / var / log / syslog і на консолі сервера (доступ до якої можна отримати в панелі управління vCenter ) Буде міститися повідомлення виду:

   kernel: Out of memory: Kill process 1543 (mysqld) score 146 or sacrifice child У цьому випадку, перезавантажте сервер, щоб звільнити пам'ять телефону і відновлення роботи всіх сервісів. Потім залучіть розробників для оптимізації скриптів і запитів до БД, для запобігання виникнення помилки в майбутньому. Або, якщо оптимізація є неможливою, збільшити тарифний план, тим самим збільшити обсяг доступної пам'яті.

2. Сервер не може стартувати через помилки в конфігурації.

   Як правило це може виникнути після правки конфігураційного файлу my.cnf або поновлення системи. В цьому випадку, слід відкинути редагування і перезапустити сервер або окремо MySQL.

Якщо у вас виникли складності, не описані тут, напишіть нам на [email protected]

MySQL Query Error: SELECT ... FROM ... [Got error 28 from storage engine]

Помилка може містити будь-який SELECT, INSERT або UPDATE запит, але при цьому обов'язково закінчується уточненням Got error 28 from storage engine. Причиною помилки є переповнення жорсткого диска (HDD)

В цьому випадку, увійдіть сервер по SSH і виконайте команду df -h:

# Df -h Filesystem Size Used Avail Use% Mounted on / dev / sda2 9.6G 9.2G 0 100% / tmpfs 250M 0 250M 0% / dev / shm / dev / sda1 118M 102M 9.1M 92% / boot Основний розділ, в прикладі / dev / sda2 (так як він найбільший, що видно по колонці Size, і точка монтування у нього - коренева директорія Mounted on /) використовується на 100%

Для відновлення роботи слід видалити більш непотрібні дані з диска або збільшити дисковий простір.

Якщо у вас виникли складності, не описані тут, напишіть нам на [email protected]

↑ повернутися до змісту