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