-
Offline
DronS
Недавно здесь
- Регистрация:
- 07.10.2018
- Сообщения:
- 3
- Симпатии:
- 0
- Пол:
- Мужской
Уважаемые специалисты помогите!
Сначала шаблон развалился, вычитал на форуме, что ДжумСоциал частенько такое творит, снёс его, так как ставил чисто для ознакомления, заодно снес Автодиспетчер, не помогло. Думаю, раз работал три дня назад, залью старую базу, запросил, залил, и получил Error: Failed to start application: Table ‘andr81m0_st.#__session’ doesn’t exist
Не хватает какой-то строки в таблицах. Я специалист по уровню подготовки немногим более ноля, решил и файлы трёхдневной давности восстановить. Запросил, залил, но результат тот же. Помогите, подскажите, наставьте на путь истинный
Последние логи, если это что-то дает:Последнее редактирование модератором: 12.01.2020
-
Offline
OlegK
Russian Joomla! Team
Команда форума
⇒ Профи ⇐- Регистрация:
- 17.01.2011
- Сообщения:
- 7 813
- Симпатии:
- 768
- Пол:
- Мужской
Не подключена база данных или удалена таблица сессий. Можно попробовать прописать в конфиге ДЖумла, файл для хранения сессий, а не БД.
-
Offline
DronS
Недавно здесь
- Регистрация:
- 07.10.2018
- Сообщения:
- 3
- Симпатии:
- 0
- Пол:
- Мужской
Тут сложность еще в том, что и административная часть не запускается..
-
Offline
OlegK
Russian Joomla! Team
Команда форума
⇒ Профи ⇐- Регистрация:
- 17.01.2011
- Сообщения:
- 7 813
- Симпатии:
- 768
- Пол:
- Мужской
Доступ к БД в файле конфига, а не через адаминку Джумла. .
-
Offline
DronS
Недавно здесь
- Регистрация:
- 07.10.2018
- Сообщения:
- 3
- Симпатии:
- 0
- Пол:
- Мужской
-
Offline
OlegK
Russian Joomla! Team
Команда форума
⇒ Профи ⇐- Регистрация:
- 17.01.2011
- Сообщения:
- 7 813
- Симпатии:
- 768
- Пол:
- Мужской
В файле configuration.php проверь данные доступа к базе данных.
-
Offline
Asylum
Местный
=> Cпециалист <=- Регистрация:
- 09.02.2007
- Сообщения:
- 2 744
- Симпатии:
- 160
- Пол:
- Мужской
У вас там русским по белому написано Error: Failed to start application: Table ‘andr81m0_st.#__session’ doesn’t exist
Таблицы ‘andr81m0_st.#__session не существует
Создайте новую таблицу, можно взять из дистрибутива
-
Offline
vasmed
Недавно здесь
- Регистрация:
- 27.12.2019
- Сообщения:
- 1
- Симпатии:
- 0
- Пол:
- Мужской
У меня была ошибка «Error: Failed to start application: Failed to start the session», при попытке открыть страницу сайта на joomla.
Возникла после клонирования файлов и базы на другой сервер и обновления joomla до последней версии. Началась с того, что я заметил, что в админке в настройках базы данных указан адрес старого хоста. Когда я изменил его на новый, то сохранить настройки не удалось. Попробовал изменить хост в файле configuration.php, но тут то было. Была та же ошибка. Менял хост на ‘localhost’, но видимо наложилось, что я обновлялся и старая база на localhost не подцепилась, либо были какие-то еще проблемы, в общем, ошибка осталась. Пол дня проверял все подряд (PHP, mysql, apache). Потом скачал полный дистрибутив новой Joomla 3.9.14. Разархивировал его, установил. Сайт на новой joomle заработал. Взял конфигурационный файл из нее, закинул его в клонированную базу и изменил некоторые параметры на нужные. (Кстати заметил что в новом установленном конфиге $host = ‘localhost’). И ура! Сайт заработал.
Поделиться этой страницей
Содержание
- The Joomla! Forum™
- PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
- PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
- Re: Server moved — Joomla not workind anymore under PHP 7.4
- Re: Server moved — Joomla not workind anymore under PHP 7.4
- Re: Server moved — Joomla not workind anymore under PHP 7.4
- Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
- Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
- Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
- Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
- Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
- Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
- The Joomla! Forum™
- Error: Failed to start application: Failed to start the session because headers have already been sent by /public_html/l Topic is solved
- Re: Failed to start the session because headers have already been sent by «/home/sites/4b/3/30112786da/public_html/index
- Re: Failed to start the session because headers have already been sent by «/home/sites/4b/3/30112786da/public_html/index
- Re: Failed to start the session because headers have already been sent by «/home/sites/4b/3/30112786da/public_html/index
- Re: Failed to start the session because headers have already been sent by «/home/sites/4b/3/30112786da/public_html/index
- Re: Failed to start the session because headers have already been sent by «/home/sites/4b/3/30112786da/public_html/index
- Re: Failed to start the session because headers have already been sent by «/home/sites/4b/3/30112786da/public_html/index
- Error: Failed to start application: Failed to start the session because headers have already been sent by /public_html/l
The Joomla! Forum™
PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
Post by chtrede » Mon Nov 29, 2021 11:39 am
Hi there,
I moved my Joomla installation 3.10.3 to a new server. On that machine the installation does not run anymore under PHP 7.4, but only under PHP 7.3.
As an error message I get
[code]Warning: session_start(): Failed to read session data: user (path: /var/cpanel/php/sessions/ea-php74) in /home/yyyyyy/public_html/libraries/joomla/session/handler/native.php on line 260
Error: Failed to start application: Failed to start the session[/code]
Re: Server moved — Joomla not workind anymore under PHP 7.4
Post by pe7er » Mon Nov 29, 2021 3:36 pm
How did you move your website to another server?
Did you use Akeeba Backup to backup and kickstart to restore it?
It seems that your website is not able to get the session data from the database.
Are your database settings correct (in configuration.php) ?
btw: Using PHP7.3 is not a good idea because on 6 Dec 2021 the support for PHP 7.3 security patches ends, see:
https://www.php.net/supported-versions.php
Re: Server moved — Joomla not workind anymore under PHP 7.4
Post by abernyte » Mon Nov 29, 2021 4:30 pm
Re: Server moved — Joomla not workind anymore under PHP 7.4
Post by Per Yngve Berg » Mon Nov 29, 2021 5:33 pm
Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
Post by sozzled » Mon Nov 29, 2021 5:54 pm
See viewtopic.php?t=982009. The problem can be caused by any number of a dozen reasons. As @abernyte says, it could be caused by not enabling the MySQLi PHP extension (if the file configuration.php specifies mysqli as the database connection method); as @Per says, it could be caused if save.session.path is not defined; as @pe7er says, it could be caused if the configuration.php file settings are misconfigured.
The problem can also be caused if some of the «optional» technical requirements for J! 3. x are not met; errors will result if you are using the database to save sessions and the _sessions table is full.
I have been researching this «‘Error: Failed to start application: Failed to start the session» problem over the past three to four weeks in preparing an article. I can’t tell you where to find this article—that would be self-promotion and that’s against the forum rules—but I’ve summarised the various common (and some not-so-common) reasons. I am following this topic to see if we’ve found another cause for the error and, if we have, I will add it to my list.
Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
Post by dorsa » Sun Aug 28, 2022 4:52 am
I have hosted web application develop using joomla in ubuntu 20 and use mysql as database. one i hosted and viewed in the web browser it show me Error: Failed to start application: Failed to start the session
i have used php 7.4, mysql Ver 8.0.27, apache Apache/2.4.41 (Ubuntu)
Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
Post by sozzled » Sun Aug 28, 2022 5:05 am
Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
Post by Per Yngve Berg » Sun Aug 28, 2022 6:23 am
If set to ‘database’, then change it. This is the preffered method with php 7 and above.
If still show Session error, the save.session_path on the server is not writable.
If you get a database connect error, the you have a problem connecting to the database.
save.session_path is set in php.ini
Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
Post by sozzled » Sun Aug 28, 2022 6:31 am
Re: PHP 7.4: ‘Error: Failed to start application: Failed to start the session’
Post by Per Yngve Berg » Sun Aug 28, 2022 6:53 am
Corrected. It’s now ‘none’ for J3 instead of ‘filesystem’
Источник
The Joomla! Forum™
Error: Failed to start application: Failed to start the session because headers have already been sent by /public_html/l Topic is solved
Post by jonBuckner1 » Tue Jun 04, 2019 4:38 pm
Are there any more tips for this.
This drama is mine now
I have changed from uikit to astroid and altered stuff in db (only tables relating to seblod)
I was on php v7.1.29, read that it was near end of life, so thought cool, I will go to 7.3 (after asking on Forum if was ok to do so), and now can only use 7.0
Warning: array_key_exists() expects parameter 2 to be array, null given in
/public_html/libraries/cms.php on line 74
Error: Failed to start application: Failed to start the session because headers have already been sent by /public_html/libraries/cms.php» at line 74.
Hopefully someone could suggest a few places to look
Post by Webdongle » Tue Jun 04, 2019 5:11 pm
Post by Per Yngve Berg » Tue Jun 04, 2019 5:17 pm
Post by jonBuckner1 » Tue Jun 04, 2019 5:35 pm
wow, quick response. Thanks folks.
I edited the css classes within the db in the table:
#__cck_core_fields
#__cck_core_search
#__cck_sore_type
I am very comfortable editing these, in fact do it all the time (for years) as a shortcut
Post by jonBuckner1 » Tue Jun 04, 2019 5:44 pm
Post by jonBuckner1 » Tue Jun 04, 2019 5:47 pm
Error: Failed to start application: Failed to start the session because headers have already been sent by /public_html/l
Post by jonBuckner1 » Tue Jun 04, 2019 5:51 pm
My error message was:
Warning: array_key_exists() expects parameter 2 to be array, null given in
/public_html/libraries/cms.php on line 74
Error: Failed to start application: Failed to start the session because headers have already been sent by /public_html/libraries/cms.php» at line 74.
I had increased max_input_vars from 1000 to 3000 using php.ini file
I had upgraded php from 7.1 to 7.3.
System threw up errors.
I went back to 7.1 and saw some errors, but Siteground suggested I use 5.6 and as a result I only receive a few errors.
I must have done something.
Basic Environment :: wrote: Joomla! Instance :: Joomla! 3.9.6-Stable (Amani) 7-May-2019
Joomla! Platform :: Joomla Platform 13.1.0-Stable (Curiosity) 24-Apr-2013
Joomla! Configured :: Yes | Writable ( 644 ) | Owner: —protected— . (uid: 1/gid: 1) | Group: —protected— (gid: 1) | Valid For: 3.9
Configuration Options :: Offline: false | SEF: true | SEF Suffix: false | SEF ReWrite: true | .htaccess/web.config: Yes | GZip: true | Cache: false | CacheTime: 2000 | CacheHandler: file | CachePlatformPrefix: false | FTP Layer: false | Proxy: false | LiveSite: | Session lifetime: 15 | Session handler: none | Shared sessions: false | SSL: 2 | Error Reporting: default | Site Debug: false | Language Debug: false | Default Access: 1 | Unicode Slugs: false | dbConnection Type: mysqli | PHP Supports J! 3.9.6: Yes | Database Supports J! 3.9.6: Yes | Database Credentials Present: Yes |
Host Configuration :: OS: Linux | OS Version: 3.12.18-clouder0 | Technology: x86_64 | Web Server: Apache | Encoding: gzip, deflate, br | Doc Root: —protected— | System TMP Writable: Yes | Free Disk Space : 649.28 GiB |
PHP Configuration :: Version: 7.0.33 | PHP API: cgi-fcgi | Session Path Writable: No | Display Errors: 1 | Error Reporting: | Log Errors To: | Last Known Error: | Register Globals: | Magic Quotes: | Safe Mode: | Open Base: | Uploads: 1 | Max. Upload Size: 128M | Max. POST Size: 128M | Max. Input Time: 120 | Max. Execution Time: 120 | Memory Limit: 768M
Database Configuration :: Version: 5.6.40-84.0-log (Client:5.5.32) | Host: —protected— ( —protected— ) | default Collation: utf8_general_ci ( default Character Set: utf8) | Database Size: 116.14 MiB | #of Tables: 144
Detailed Environment :: wrote: PHP Extensions :: Core (7.0.33) | date (7.0.33) | libxml (7.0.33) | openssl (7.0.33) | pcre (7.0.33) | sqlite3 (7.0.33) | zlib (7.0.33) | bcmath (7.0.33) | bz2 (7.0.33) | calendar (7.0.33) | ctype (7.0.33) | curl (7.0.33) | dba (7.0.33) | dom (20031129) | enchant (7.0.33) | hash (1.0) | fileinfo (1.0.5) | filter (7.0.33) | ftp (7.0.33) | gd (7.0.33) | gettext (7.0.33) | gmp (7.0.33) | SPL (7.0.33) | iconv (7.0.33) | session (7.0.33) | intl (1.1.0) | json (1.4.0) | ldap (7.0.33) | mbstring (7.0.33) | mcrypt (7.0.33) | standard (7.0.33) | mysqli (7.0.33) | pcntl (7.0.33) | mysqlnd (mysqlnd 5.0.12-dev — 20150407 — $Id: b5c5906d452ec590732a93b051f3827e02749b83 $) | PDO (7.0.33) | pdo_mysql (7.0.33) | pdo_pgsql (7.0.33) | pdo_sqlite (7.0.33) | pgsql (7.0.33) | Phar (2.0.2) | posix (7.0.33) | pspell (7.0.33) | readline (7.0.33) | Reflection (7.0.33) | imap (7.0.33) | shmop (7.0.33) | SimpleXML (7.0.33) | soap (7.0.33) | sockets (7.0.33) | exif (7.0.33) | sysvmsg (7.0.33) | sysvsem (7.0.33) | tidy (7.0.33) | tokenizer (7.0.33) | wddx (7.0.33) | xml (7.0.33) | xmlreader (7.0.33) | xmlrpc (7.0.33) | xmlwriter (7.0.33) | xsl (7.0.33) | zip (1.13.5) | cgi-fcgi () | memcached (3.0.4) | Zend OPcache (7.0.33) | Zend Engine (3.0.0) |
Potential Missing Extensions ::
Switch User Environment (Experimental) :: PHP CGI: Yes | Server SU: Yes | PHP SU: Yes | Custom SU (LiteSpeed/Cloud/Grid): Yes
Potential Ownership Issues: No
Folder Permissions :: wrote: Core Folders :: images/ (755) | components/ (755) | modules/ (755) | plugins/ (755) | language/ (755) | templates/ (755) | cache/ (755) | logs/ (755) | tmp/ (755) | administrator/components/ (755) | administrator/modules/ (755) | administrator/language/ (755) | administrator/templates/ (755) | administrator/logs/ (755) |
Extensions Discovered :: wrote: Components :: SITE ::
Core :: com_wrapper (3.0.0) 1 | com_mailto (3.0.0) 1 |
3rd Party::
Components :: ADMIN ::
Core :: com_cache (3.0.0) 1 | com_actionlogs (3.9.0) 1 | com_media (3.0.0) 1 | com_config (3.0.0) 1 | com_messages (3.0.0) 1 | com_redirect (3.0.0) 1 | com_templates (3.0.0) 1 | com_languages (3.0.0) 1 | com_contenthistory (3.2.0) 1 | com_postinstall (3.2.0) 1 | com_joomlaupdate (3.6.2) 1 | com_associations (3.7.0) 1 | com_installer (3.0.0) 1 | com_menus (3.0.0) 1 | com_checkin (3.0.0) 1 | com_tags (3.1.0) 1 | com_categories (3.0.0) 1 | com_finder (3.0.0) 1 | com_login (3.0.0) 1 | com_newsfeeds (3.0.0) 1 | com_fields (3.7.0) 1 | com_users (3.0.0) 1 | com_banners (3.0.0) 1 | com_ajax (3.2.0) 1 | com_content (3.0.0) 1 | com_search (3.0.0) 1 | com_privacy (3.9.0) 1 | com_modules (3.0.0) 1 | com_plugins (3.0.0) 1 | com_cpanel (3.0.0) 1 | com_admin (3.0.0) 1 |
3rd Party:: JCH Optimize (5.2.3) 1 | Akeeba (6.5.1) 1 | plg_cck_storage_location_%name% (%version%) ? | plg_cck_field_restriction_%name% (%version%) ? | plg_cck_ecommerce_payment_%name% (%version%) ? | plg_cck_ecommerce_shipping_%name% (%version%) ? | plg_cck_field_validation_%name% (%version%) ? | plg_cck_field_%name% (%version%) ? | plg_cck_field_live_%name% (%version%) ? | plg_cck_field_link_%name% (%version%) ? | plg_cck_field_typo_%name% (%version%) ? | com_cck_developer (1.4.1) 1 | JMap (4.3.5) 1 | com_cck_importer (1.11.2) 1 | com_cck_updater (1.4.3) 1 | Dump (2012-10-31) 1 | mod_cck_menu (3.0.0) 1 | com_cck (3.17.4) 1 | com_cck_exporter (1.9.4) 1 | COM_LOGINASUSER (3.3.2) 1 |
Modules :: SITE ::
Core :: mod_languages (3.5.0) 1 | mod_whosonline (3.0.0) 1 | mod_footer (3.0.0) 1 | mod_users_latest (3.0.0) 1 | mod_login (3.0.0) 1 | mod_articles_news (3.0.0) 1 | mod_tags_similar (3.1.0) 1 | mod_finder (3.0.0) 1 | mod_custom (3.0.0) 1 | mod_articles_latest (3.0.0) 1 | mod_banners (3.0.0) 1 | mod_feed (3.0.0) 1 | mod_tags_popular (3.1.0) 1 | mod_search (3.0.0) 1 | mod_wrapper (3.0.0) 1 | mod_articles_category (3.0.0) 1 | mod_menu (3.0.0) 1 | mod_random_image (3.0.0) 1 | mod_stats (3.0.0) 1 | mod_syndicate (3.0.0) 1 | mod_related_items (3.0.0) 1 | mod_articles_popular (3.0.0) 1 | mod_articles_archive (3.0.0) 1 | mod_articles_categories (3.0.0) 1 | mod_breadcrumbs (3.0.0) 1 |
3rd Party:: mod_cck_form (3.17.4) 1 | mod_cck_search (3.17.4) 1 | mod_cck_list (3.17.4) 1 | JSitemap module (4.3.5) 1 | mod_cck_breadcrumbs (3.17.4) 1 |
Modules :: ADMIN ::
Core :: mod_stats_admin (3.0.0) 1 | mod_popular (3.0.0) 1 | mod_submenu (3.0.0) 1 | mod_latestactions (3.9.0) 1 | mod_login (3.0.0) 1 | mod_privacy_dashboard (3.9.0) 1 | mod_quickicon (3.0.0) 1 | mod_toolbar (3.0.0) 1 | mod_multilangstatus (3.0.0) 1 | mod_custom (3.0.0) 1 | mod_version (3.0.0) 1 | mod_feed (3.0.0) 1 | mod_sampledata (3.8.0) 1 | mod_logged (3.0.0) 1 | mod_menu (3.0.0) 1 | mod_title (3.0.0) 1 | mod_status (3.0.0) 1 | mod_latest (3.0.0) 1 |
3rd Party:: mod_cck_menu (3.17.4) 1 | JSitemap Quickicons (4.3.5) 1 | mod_cck_quickicon (3.17.4) 1 | mod_cck_quickadd (3.17.4) 1 |
Libraries :: SITE ::
Core ::
3rd Party:: Astroid Plugin (2.2.0) 1 | file_fof30 (3.4.1) ? |
Источник
0 Пользователей и 1 Гость просматривают эту тему.
- 13 Ответов
- 4310 Просмотров
Добрый день!
Сайт — armymusic.ru (Joomla — 3.9.16). Вчера вечером стал выдавать ошибку — Error: Failed to start application: Error starting the session.
При попытке входа в админку — 1114 Ошибка инициализации сессии.
Ошибка появляется периодически, через 1-2 перезагрузки сайта. Позавчера и вчера утром и днем сайт работал корректно. Никаких работ на нем не производилось. Обратился к хостеру — пока затрудняются ответить о причинах ошибки. Они проверили работу сайта на разных версиях веб-сервера PHP — проблема оказалась не в этом.
Кто-нибудь сталкивался с подобным? Какие варианты решения?
« Последнее редактирование: 25.03.2020, 10:56:18 от Андрей Нестеров »
Записан
Место на диске закончилсь?
Очистить таблицу сессий в базе данных, переключить на None, т.е. запись в файл, а не БД .
Место на диске закончилсь?
Нет, использовано 57%
Очистить таблицу сессий в базе данных, переключить на None, т.е. запись в файл, а не БД .
«Запись в файл» было реализовано пару недель назад, т.е. задолго до появления ошибки. Хостеры попробовали вернуть хранение сессий в базу данных, однако это не дало какого-либо результата.
Была подобная проблема на ранних версиях тройки, вроде бы уже давно поправили, не? Плагин «System — Session Data Purge» решает эту траблу (что сессии забивали место на дискебазе и выдавали эту ошибку)
beliyadm, на ранних версиях тройки такой проблемы не было, появилась только сейчас. Плагин «System — Session Data Purge» включен: Enable Session Data Cleanup — Да, Enable Session Metadata Cleanup — Да, Probability — 1, Divisor — 100
В Google по коду ошибки есть куча разных сообщений — тоже ничего не помогает?
Да — А сайт действительно не работает ! (((
В Google по коду ошибки есть куча разных сообщений — тоже ничего не помогает?
По тем сообщениям, где люди описывают подобную проблему и варианты ее решения, было отработано следующее:
1) пробовались разные версии веб-сервера PHP;
2) проверялся файл configuration.php;
3) откинута версия с достижением максимального размера БД или ее таблиц — на хостинге нет таких ограничений.
Проблема с работоспособностью решилась восстановлением сайта из резервной копии. Но что примечательно, все крайние изменения сайта вошли в этот бэкап. После ничего не делалось. Для меня вопрос о причинах появления ошибки остается открытым.
Проблема с работоспособностью решилась восстановлением сайта из резервной копии. Но что примечательно, все крайние изменения сайта вошли в этот бэкап. После ничего не делалось. Для меня вопрос о причинах появления ошибки остается открытым.
Интересно.
Тогда сохраните текущую конфигурацию в бекап, где все работает без ошибок и в случае обнаружения еще раз подобной гадости — искать действия в обновлении конфига сервера, установки чего либо и так далее.
Если уж все советы из Google не помогли — я пока точно пас, до следующего рецидива
Здравствуйте!
Вновь столкнулся с данной проблемой. С момента предыдущего ее возникновения и решения путем восстановления из бэкапа, на сайте проводились мелкие текстовые правки и стандартное добавление контента. НО перед самым появлением ошибки я обновил компонент Akeeba Backup. Есть у кого какие мысли, может ли это быть причиной?
P.S.: Перед появлением этой ошибки в первый раз я тоже вроде как обновлял либо этот компонент, либо Admin Tools от того же разработчика, но на 100% этого не помню)
Здравствуйте,
возникла аналогичная проблема. Подскажите, пожалуйста, как ее решить? Ошибка — Error: Failed to start application: Error starting the session
Подскажите, пожалуйста, как ее решить? Ошибка —
В директориях кеша не чего не валяется ?
Здравствуйте, такая же ошибка, но на localhost. Потребовалось изменить 127.0.0.1 на 127.0.0.5
phpMyAdmin запускается, в файле host все корректно, а сайты не стартуют.
Публикую «как есть» свою трехдневную переписку с «саппортом» хостинга RU-Center… знаете, мне совсем незазорно без всяких там звездочек и кавычек охарактеризовать уровень компетенций технических специалистов Руцентра и вообще работу этого учреждения как полный и законченный so fucked up. «Саппортеры» хостинга то на сутки замолкают, то отписываются рекламными слоганами или ничего не значащими фразами, совершенно не в контексте предъявленных технических претензий. Что здесь еще сказать? — если простенькая ваша Joomla выдает на шареде Руцентра Error: Failed to start application: Failed to start the session — не рекомендую тратить время на никчемную болтовню саппорта; спешно переходите на другой хостинг, лучше на забугорный: цифровые услуги в Рашке ниже плинтуса… бля, не забыть бы добавить про оценочное суждение, а то ведь привлекут за экстремизм… впрочем, пох; отмотаю, опосля будет проще просить политического убежища в любой нормальной стране, за возможность уехать из расейского дурдома не зазорно заплатить любую цену.
Неслабо позабавило предложение подтвердить «право управления договором» в ответ на тикет, отправленный из ПУ, «пройдя» при этом по несуществующей ссылке. Публикую опять-таки «как есть»:
Пожалуй, не помешает и повториться, уже по-русски: Руцентр это полный пиздец.
Заявка
[***********] Warning: session_start(): Failed to read session data
Текущий статус:В работе
Последнее изменение:21.12.2018, 15:30
Вы написали 18.12.2018, 23:55
Номер договора: 2905524/NIC-D
Идентификатор услуги: ************
Категория: Технические вопросы
Здравствуйте, в течение временного промежутка примерно с 20.00 до 20.40 msk сегодня несколько раз получал для сайта *************** (joomla 3.9.1) следующую ошибку:
Warning: session_start(): Failed to read session data: user (path: /tmp) in /home/***********/************/docs/libraries/joomla/session/handler/native.php on line 260
Error: Failed to start application: Failed to start the session
, происходило это, насколько смог локализовать, при попытках поиска обновлений для расширений Joomla, также при попытках зайти в панель управления CMS, но неперманентно, а как бы «через раз». Несложно воспроизводил проблему, используя php 7.0, 7.1, 7.2; после чего переключился в v.5.6, в ходе работы которой проблем на данный момент не вижу.
Трабла легко гуглится, насколько могу судить, чаще всего она упирается в некорректно сконфигурированные настройки сервера: forum.joomla.org/viewtopic.php?t=961683 :
I appears that the server is not properly configured.
Ничего не берусь утверждать, т.к. не располагаю средствами диагностики в данном случае; но очень прошу саппорт разобраться в причине проблемы. Корпия сайта установлена на Таймвебе, где и происходила разработка, там при использовании php 7.1 ошибок нет, очень хотелось бы и здесь придти к тому же. Подчеркну, поскольку речь идет о продакшн, крайне нежелательно надолго вводить сайт в состояние ступора, но логи должны вполне отражать текущее положение вещей.
Жду ответа, заранее спасибо.
18.12.2018, 23:55
Здравствуйте!
Вас приветствует служба технической поддержки компании RU-CENTER.
Это письмо — автоматическое уведомление о том, что Ваша заявка получена и принята к рассмотрению.
Вашей заявке присвоен номер ********************
Если Вы уже являетесь клиентом RU-CENTER, пожалуйста, подтвердите право управления договором. Для этого пройдите по ссылке
<<AuthReqNicRu>>
Если вы не авторизованы на сайте nic.ru, укажите номер Вашего договора и административный пароль. Нажмите кнопку «Подтвердить».
Это позволит нам наиболее полно ответить на ваше обращение.
Обратите внимание!
1) Не отправляйте Вашу заявку повторно – это замедлит обработку уже полученной заявки.
2) Просим Вас в дальнейшей переписке по Вашему запросу сохранять номер заявки в теме письма.
3) Ответы на наиболее распространенные вопросы по услугам можно найти на нашем сайте:
4) В случае обращения по телефону назовите номер заявки – это ускорит ее поиск.
5) Заявки, которые могут серьезно повлиять на функциональность Вашей услуги, выполняются
только по авторизованному запросу.
—
С уважением,
Департамент по работе с клиентами RU-CENTER Group
Телефоны:
+7 (495) 994-46-01
+7 (495) 737-06-01
Факс: +7 (495) 737-06-02
English
Hello,
This is an automatic notification message from RU-CENTER to tell you that your request has been successfully submitted and is being processed. We will respond to you shortly.
Your request number is ********************.
If you already have contract number and password, please follow this link in order to authorise your request
<<AuthReqNicRu>>
—
Best regards,
RU-CENTER Group Customer Service Department
Phones:
+7 (495) 994-46-01
+7 (495) 737-06-01
Вы написали 19.12.2018, 16:43
что-то еще необходимо от меня в контексте решения проблемы?
Вы написали 20.12.2018, 02:59
Весьма впечатлен оперативностью и профессионализмом технических сотрудников руцентра; уровень обслуживания воистину поражает. Господа-товарищи, что именно требуется от клиента хостинга, чтобы т.н. «технические специалисты» у вас хоть как-то , в силу отпущенных природой способностей, на вторые сутки наконец отреагировали на запрос из ПУ управления?
Ответ службы поддержки 20.12.2018, 03:00
Здравствуйте!
В данном случае необходимо подключить расширение PHP «session».
Подключить расширение можно через панель управления хостингом:
— авторизуйтесь в панели управления хостингом, используя номер Вашего договора и пароль;
— перейдите в раздел «Управление веб-сервером» — «Управление модулем PHP»;
— в блоке «Расширения PHP» нажмите на ссылку «Управление расширениями»;
— найдите в открывшемся списке нужное расширение, пометьте его флажком и сохраните изменения.
Дополнительно рекомендуем ознакомиться с инструкцией по настройке модуля PHP:
Рекомендуем проверить системные требования в документации по используемой Вами CMS и подключить указанные в них расширения.
Примеры настройки хостинга для некоторых популярных CMS:
—
С уважением,
Дмитрий Полухин
Департамент по работе с клиентами
RU-CENTER Group
Телефоны:
+7 495 994-46-01
+7 495 737-06-01
Факс: +7 495 737-06-02
Регистрируйте домены на специальных условиях:
19.12.2018 23:59 — ***************** написал(а):
> Весьма впечатлен оперативностью и профессионализмом технических сотрудников
> руцентра; уровень обслуживания воистину поражает. Господа-товарищи, что именно
> требуется от клиента хостинга, чтобы т.н. «технические специалисты» у вас хоть
> как-то , в силу отпущенных природой способностей, на вторые сутки наконец
> отреагировали на запрос из ПУ управления?
>
Вы написали 20.12.2018, 18:21
Расширение PHP «session» в данном случае уже подключено, если верить показаниям указанной страницы:
Версия PHP: 7.1
Подключенные:ctype, curl, dom, fileinfo, filter, ftp, gd, iconv, json, mbstring, mcrypt, mysqli, opcache, openssl, pdo, pdo_mysql, session, simplexml, soap, sockets, timezonedb, tokenizer, xml, xmlreader, xmlwriter, xsl, zip
Тем не менее, мне потребовалось секунд 30, чтобы получить все ту же ошибку, скриншот прилагаю. Более того, я не вижу возможности подключить/отключить расширение с названием session априори, нет этого расширения в списке тех, которым можно выставить/снять чекбокс.
Еще идеи?Screenshot_20181220_151126.png
Ответ службы поддержки 21.12.2018, 16:52
Здравствуйте!
Модуль session включен на Вашем веб-сервере:
$ php -m |grep sess
session
Включение/отключение этого модуля выполняется переключением триггера session внизу списка выбора расширений.
Для диагностики данной ситуации просим Вас уточнить — как мы можем ее воспроизвести?
—
С уважением,
Андрей Иллензеер
Департамент по работе с клиентами
RU-CENTER Group
Телефоны:
+7 495 994-46-01
+7 495 737-06-01
Регистрируйте домены на специальных условиях:
20.12.2018 15:21 — *************** написал(а):
> Расширение PHP «session» в данном случае уже подключено, если верить показаниям
> указанной страницы:
>
> Версия PHP: 7.1
> Подключенные:ctype, curl, dom, fileinfo, filter, ftp, gd, iconv, json, mbstring,
> mcrypt, mysqli, opcache, openssl, pdo, pdo_mysql, session, simplexml, soap,
> sockets, timezonedb, tokenizer, xml, xmlreader, xmlwriter, xsl, zip
>
> Тем не менее, мне потребовалось секунд 30, чтобы получить все ту же ошибку,
> скриншот прилагаю. Более того, я не вижу возможности подключить/отключить
> расширение с названием session априори, нет этого расширения в списке тех, которым
> можно выставить/снять чекбокс.
>
> Еще идеи?
>
Вы написали 21.12.2018, 18:30
Я этот модуль не включал; логично ли с моей стороны предположить, что рекомендация вашего коллеги была, как бы это помягче выразиться… непрофессиональной? Да и ваш «ответ» мне представляется, признаться, несколько не в тему; разве я спрашивал о том, каким образом на руцентре включаются/отключаются модули? Меня интересовал совсем иной вопрос: почему PHP у вас работает столь криво, и есть ли возможность это как-то залатать.
Как воспроизвести? — элементарно. Поставьте джумлу с дефолтными настройками, включите седьмой пых. Уверен, если будет у инженеров хостинга хоть малейшее желание «воспроизвести проблему» — они ее воспроизведут, если желания не будет — последует новый велеречивый ответ, маскирующий нежелание работать. Не стесняйтесь, прошу вас.
Про возможность глянуть логи — не случайно ведь указал в первом сообщении время ручного тестирования — в разговоре с «инженерами поддержки хостинга» я даже как-то и заикаться стесняюсь.