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

12.09.23

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

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

Скачать файл

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

Наименование По подписке [?] Купить один файл
snccntx_reset.tgz
.tgz 0,70Kb
1
1 Скачать (1 SM) Купить за 1 850 руб.

В среде 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)

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

10.03.2025    432    unichkin    9    

9

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

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

11.02.2025    954    it-expertise    0    

3

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

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

31.01.2025    1623    it-expertise    1    

7

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

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

29.01.2025    1047    Klok22    4    

13

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

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

23.12.2024    2542    capitan    7    

15

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

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

06.12.2024    2081    it-expertise    8    

23

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

Проект перевода 10+ систем 1С на 2000+ пользователей в Авито завершен успешно, преодолев технические трудности и «черных лебедей» в виде неопределенности, демотивации, потерь производительности и нереалистичных требований руководства. Расскажем об опыте проекта, в котором было «очень страшно», но в итоге всё получилось.

29.11.2024    1982    kirill.skoromykin    1    

7

Linux Программист Бесплатно (free)

При многолетней эксплуатации 1С на Windows и MS SQL в базе накапливаются не самые оптимальные запросы, COM-объекты и скрипты, зависящие от ОС. Из-за этого процесс перехода на PostgreSQL и переноса сервера 1С на Linux неизбежно осложняется длительным исправлением кода и оптимизацией запросов. Расскажем о том, как с задачей такого рефакторинга справились в компании Avito.

13.11.2024    7063    klimat12    17    

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

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

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

Часто ли встречаются проблемы с сеансовыми данными? Встречаются, но достаточно редко.
2. starik-2005 3162 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утра а тот кто занял конфигуратор сладко спит в мск) но если ты ушел, разработку сохрани. А лучше и конфигуратор освободи ну или не обижайся, если сеанс умрет. База твоя конечно, но всякое бывает.).
Оставьте свое сообщение