Рестарт сервера 1С с очисткой сеансовых данных на Linux посредством systemd

12.09.23

Администрирование - Linux

Сказ о том, как сделать "кошерный" перезапуск сервера 1С, работающего на платформе GNU/Linux, с очисткой сеансовых данных посредством systemd

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
(только для физ. лиц)
snccntx_reset.tgz
.tgz 0,70Kb
2 1 850 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

В среде 1С можно часто услышать рецепт: "перезапустить сервер 1С с очисткой сеансовых данных" или "перезапустить сервер 1С с чисткой серверного кэша"

Про сеансовые данные сервера 1С можно почитать, например, на ИТС

Да, есть случаи когда перезапуск сервера 1С с очисткой сеансовых данных действительно решает возникшие проблемы. Есть даже рекомендации коллег, делать ежедневный рестарт сервера 1С с чисткой сеансовых данных, и в каких-то ситуациях это действительно может стать единственным выходом из сложившейся ситуации.

Однако я не являюсь приверженцем идеи "в любой непонятной ситуации чистить кэш сервера 1С", поэтому не буду ни кого ни за что агитировать, или что-то советовать в этом контексте, а всего лишь поведаю о способе реализации механизма очистки сеансовых данных сервера 1С посредством systemd

О том, как мы на своих проектах управляем сервером 1С посредством systemd можно почитать в статье Запуск нескольких экземпляров сервера 1С на GNU/Linux посредством systemd

Дальнейшее повествование будет отталкиваться именно от файла сервиса, описанного в приведенной выше статье, но в целом может быть "пристроено" и к файлу сервиса, распространяемому в составе дистрибутива платформы (см. ИТС)

Вспомогательный скрипт

Для реализации механизма очистки сеансовых данных нам потребуется вспомогательный скрипт следующего содержания

#!/bin/bash

function make_snccntx_reset_conf {
   cat <<EOF > "/etc/systemd/system/srv1cv83@${1}.service.d/snccntx_reset.conf"
[Service]
ExecStopPost=/bin/find \${SRV1CV8_DATA} -maxdepth 3 -regex "\${SRV1CV8_DATA}.*snccntx.*" -name "*.dat" -delete
EOF
}

case ${1} in
on) make_snccntx_reset_conf "${2}" ;;&
off) rm -f "/etc/systemd/system/srv1cv83@${2}.service.d/snccntx_reset.conf" ;;&
on|off) systemctl daemon-reload;;
*) echo "ОШИБКА: Неизвестный режим работы!"; exit 1;;
esac

Которому следует дать имя snccntx_restet.sh, поместить в каталог /usr/local/sbin/ и дать права на выполнение!

$ sudo cp ~/snccntx_reset.sh /usr/local/sbin
$ sudo chmod +x /usr/local/sbin/snccntx_reset.sh

Данный скрипт добавляет, или удаляет у указанного в параметрах вызова сервиса сервера 1С файл настроек, отвечающий за поиск и удаление сеансовых данных в каталоге сервера 1С, после чего выполняет перечитывание настроек systemd

Дополнительный сервис и таймер systemd

Так же необходимо создать файл дополнительного сервиса restart_srv1cv83@.service нижеследующего содержания, который следует поместить в  каталог /etc/systemd/system

[Unit]
Description=Restart srv1cv83@%i service with session data reset

[Service]
Type=oneshot
ExecStartPre=-/usr/local/sbin/snccntx_reset.sh on %i
ExecStart=/usr/bin/systemctl try-restart srv1cv83@%i.service
ExecStartPost=-/usr/local/sbin/snccntx_reset.sh off %i

Вместе с тем следует создать файл таймера restart_srv1cv83@.timer, который так же необходимо поместить в каталог /etc/systemd/system

[Unit]
Description=Daily srv1cv83@%i restart

[Timer]
OnCalendar=*-*-* 05:00:05

[Install]
WantedBy=timers.target

Как все это работает?

Для ручного перезапуска сервера 1С с очисткой сеансовых данных вам необходимо будет выполнить команду (для случая если вы управляете сервисом сервера 1С посредством сервиса srv1cv83@default.service)

$ sudo systemctl start restart_srv1cv83@default

В случае когда вам требуется регулярный перезапуск, вам необходимо активировать таймер (в текущем варианте он будет запускаться каждый день в 05:00:05, если вам требуется иное время, вы можете внести необходимые изменения). Активация/запуск таймера можно выполнить командой (так же для сервера 1С, управляемого сервисом srv1cv83@default.service)

$ sudo systemctl enable --now restart_srv1cv83@default.timer

Проверить что таймер действительно включился можно командой

$ sudo systemctl list-timers
NEXT                         LEFT     LAST                         PASSED  UNIT
Tue 2023-09-12 05:00:05 MSK  23h left n/a                          n/a     restart_srv1cv83@default.timer restart_srv1cv83@default.service

В выводе указанной команды должен присутствовать наш таймер restart_srv1cv83@default.timer с информацией о дате и времени следующего и последнего запуска

Зачем все так сложно!?

Вероятно у читателя может возникнуть вопрос, а зачем вообще такие "сложности" для казалось бы "банальной" операции. Попробую пояснить ключевые моменты предлагаемого решения:

  1. Хотелось сохранить выбранную концепцию мультисервисности, предлагаемую systemd
  2. Мы сохраняем без изменений оригинальный сервис, который можно с легкостью перезапускать без очистки сеансовых данных (читай, без принудительного завершения пользовательских сеансов). Если у вас нет нужды в таком сценарии, то можно файл конфигурации, создаваемый скриптом, поместить в файл дополнительных настроек мультисервиса srv1cv83@.service (или в файл дополнительных настроек конкретного сервиса, например srv1cv83@default.service) "на постоянной основе". При этом вы избавитесь от необходимости вспомогательного скрипта. Способ задания таких настроек приведен в предыдущей статье, на пример, как это делается для портов сервера 1С
  3. Зачем вообще нужен вспомогательный скрипт, если можно было бы поместить все эти команды в файл сервиса restart_srv1cv83@.service!? Основная причина - это необходимость выполнения команды systemctl daemon-reload, которую не получиться вызвать непосредственно из файла сервиса systemd

Надеюсь изложенная информация будет полезна коллегам!

Вступайте в нашу телеграмм-группу Инфостарт

сервер 1с сеансовые данные перезапуск linux systemd

См. также

Администрирование СУБД Linux Системный администратор Программист 1С v8.3 Бесплатно (free)

Преимущества использования PostgreSQL как объектно-реляционной СУБД и Linux в качестве операционной системы сервера

02.06.2025    3560    PROSTO-1C    12    

2

Обновление 1С Linux Системный администратор Программист Бесплатно (free)

Пошаговая инструкция для обновления платформы 1С на сервере Linux Debian.

28.03.2025    2069    California_Dreaming    2    

5

Linux Системный администратор Программист 1С v8.3 Бесплатно (free)

В очередной раз решая проблему с доступом к файлу программной лицензии - решил сделать памятку на будущее для себя и коллег.

10.03.2025    2228    unichkin    11    

13

Linux Рефакторинг и качество кода Программист 1С v8.3 Бесплатно (free)

В третьей статье по докладу Александра Кириллова, с которым он выступил на конференции INFOSTART TECH EVENT 2024, обсудим подходы к рефакторингу платформеннозависимого кода

11.02.2025    1484    it-expertise    0    

3

Рефакторинг и качество кода Linux Программист 1С v8.3 Бесплатно (free)

Во второй статье по докладу Александра Кириллова, с которым он выступил на конференции INFOSTART TECH EVENT 2024, поговорим об особенностях анализа конфигурации 1С на наличие платформеннозависимого кода.

31.01.2025    2264    it-expertise    1    

9

Linux Системный администратор 1С v8.3 Россия Бесплатно (free)

Как устроить зависание системы (Ubuntu) из 1С (толстый клиент) с помощью буфера обмена и что с этим делать.

29.01.2025    1704    Klok22    6    

15

Linux Системный администратор Программист 1С v8.3 1C:Бухгалтерия Бесплатно (free)

Задача разработки перед выполнением проходит пять стадий принятия: отрицание, гнев, поиск в интернете, депрессия и чтение документации. Некоторым темы, затронутые в публикации, будут знакомы, некоторым покажутся банальными, но, надеюсь, некоторым они сэкономят немного времени и нервов. По сути это шпаргалка самому себе по тем вещам, которые потребовали более часа поисков.

23.12.2024    3095    capitan    8    

16

Linux Системный администратор Программист 1С v8.3 Бесплатно (free)

Александр Кириллов, руководитель группы разработки компании «ИТ-Экспертиза», на конференции INFOSTART TECH EVENT 2024 выступил с докладом на тему «Как найти и устранить платформеннозависимый код менее, чем за 5 лет». Материал получился интересным и объемным, поэтому мы решили сделать на базе выступления Александра цикл статей. В первой части начнем с особенностей работы информационных систем 1С под управлением ОС Linux.

06.12.2024    2953    it-expertise    8    

26
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. nvv1970 14.09.23 09:09 Сейчас в теме
Убил бы за очистку по таймеру.
Особенно на серверах разработки.

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

Подробное действие должно быть только ручным, по требованию и ситуации.

Часто ли встречаются проблемы с сеансовыми данными? Встречаются, но достаточно редко.
2. starik-2005 3180 14.09.23 10:20 Сейчас в теме
(1)
Между тем на ночь остаются открытыми сеансы, консоли, конфигураторы.
Отрубить голову!
Иногда какие-то длительные обработки.
Отрубить вторую голову!
user2107215; headMade; webester; +3 Ответить
3. webester 26 18.09.23 07:42 Сейчас в теме
(1)
Между тем на ночь остаются открытыми сеансы, консоли, конфигураторы.

Должно работать правило. Если конфигуратор занимает базу после окончания рабочего дня и человека который его занимает нет на месте, конфигуратор может быть убит(если это нужно). Человека можно попробовать спросить, как так вышло, что конфигуратор открыт, а он в нем не работает. Но это не обязательно.
user2046697; +1 Ответить
4. nvv1970 18.09.23 08:58 Сейчас в теме
(3) ни разу не работал в компаниях где рабочее время как-то ограничено. Но вечерам ночам вполне может идти разработка.
Или например большое обновление может длиться 2-3 суток. А если тесты больше суток идут?

И да, может потребоваться рестарт по разным причинам. И ночью никто никого оповещать не будет.
Но рестарт без причины, просто так, каждые N часов, в контуре разработки...
В рабочей так можно, особенно во время обновления. В контуре разработки, тестирования - нельзя.
5. webester 26 19.09.23 03:52 Сейчас в теме
(4)Не ограничено конечно ничего. Перерабатывай сколько влезет. Хоть круглые сутки. Или может ты пришел позже. Но если ты открыл конфигуратор и ушел домой. Конфигуратор будет убит если он нужен другим людям. Тебя могут спросить, могут не спросить(когда например вы во Владивостоке в 8утра а тот кто занял конфигуратор сладко спит в мск) но если ты ушел, разработку сохрани. А лучше и конфигуратор освободи ну или не обижайся, если сеанс умрет. База твоя конечно, но всякое бывает.).
Оставьте свое сообщение