Сессии в PHP и Битрикс «ломаются»: нет места на диске и быстрая диагностика

Что может выглядеть как баг Битрикса

В продакшене встречается картина: ядро на каждый хит считает bitrix_sessid() «новым», формы и AJAX-блоки отдают ошибки про недействительный сеанс, а авторизация в панели сначала работает или ведёт себя непредсказуемо. Одна из простых технических причин — нет возможности сохранить файлы сеансов: диск забит или выбраны временные каталоги на разделе без свободного места. Тогда каждый запуск session_start() фактически не получает постоянное хранилище, и браузеру прилетает очередная «случайная» строка cookie.

Минимальная диагностика чистым PHP

Имеет смысл отделить «Битрикс» от конфигурации PHP: короткая страница во временном файле покажет, стартует ли нативная сессия и совпадает ли идентификатор между перезагрузками.

Разместите скрипт вне боевых маршрутов (отдельный поддомен, HTTP basic или по IP), удалите сразу после проверки — вы выводите сырой дамп ошибок.

<?php
declare(strict_types=1);

ini_set('error_reporting', (string) E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');

if (!session_start()) {
    exit('cannot start native session');
}

header('Content-Type: text/plain; charset=UTF-8');

echo "native session boot: ok\n";
echo 'php_session_identifier: ';
var_dump(session_id());
echo "cookie_PHPSESSID (raw): ";
var_dump($_COOKIE['PHPSESSID'] ?? '(missing)');

$priorMarker = $_SESSION['counter_marker'] ?? null;
echo 'counter_marker before increment: ';
var_dump($priorMarker);

$_SESSION['counter_marker'] = (int) ($priorMarker ?? 0) + 1;
echo 'counter_marker after increment: ';
var_dump($_SESSION['counter_marker']);

При втором и следующих обращениях должны сохраниться и тот же session_id(), и растущий счётчик. Если между F5 строка сеанса скачет, смотрим логи PHP и сообщения уровня Optional open(/path/sess_xx) failed … No space left on device или ошибки записи в каталог временных файлов.

На сервере проверить в первую очередь

• Свободное место и inode — для разделов с корнем сайта, /tmp, каталогами сессий и логами веб-сервера (df -h, df -i). Частый сценарий на VM: журналы забили root-раздел, а приложение живёт там же.
• Куда пишутся сессии — значение директивы PHP session.save_path должно быть доступным для записи пользователю воркера (php-fpm). На «голом» диске путь может существовать, но запись упирается в квоту или SELinux/AppArmor.
• Не только «диск забит данными» — временно упираются вместимость после тяжёлых аплоадов, неочищенных бэкапов в каталоге проекта или всплесков лога Bitrix-кеша рядом с сессией.

В контексте 1С-Битрикс

Ядро полагается на рабочий механизм PHP-сессий и свой sessid для связки POST/AJAX. Пока нативный слой дергается в «режиме каждый раз новый файл», симптомы воспринимаются как ошибка форм без видимых правок со стороны разработчиков. После устранения нехватки места имеет смысл очистить тестовый скрипт и перепроверить проблемную форму уже в связке с /bitrix/services/main/ajax.php.

Отдельно полезно знать, что при кластерной сборке сеансы выносят в Redis/memcached через настройку обработчиков ядра; если файл на этом этапе отключён как хранилище, проверке подлежит доступность этого сервиса, но базовый тест без Битрикса всё равно помогает отсечь «физический» отказ записи на локальный диск.