Starting Cleanup of Temporary Directories

В юнитах системд.

Не зря в федоре хотят эти описательные бредни на имя юнита заменить, не зря…

Поиск Google забит советами по Red Hat / Centos с описанием кучи проблем.

Нашел:

./system/systemd-tmpfiles-clean.service:9:Description=Cleanup of Temporary Directories
./system/systemd-tmpfiles-clean.timer:9:Description=Daily Cleanup of Temporary Directories

Теперь появился другой вопрос. Как изменить время запуска? Мне оно абсолютно не нужно во время пиковой нагрузки. Вот образец с очистки php сессий:

[Timer]
OnCalendar=*-*-* *:09,39:00
Persistent=true

А вот что написано в упомянутом выше файле:

[Timer]
OnBootSec=15min
OnUnitActiveSec=1d

Ставить просто OnCalendar=--* 02:00:00 ? Как применить изменения?

P.S. мистика: в /etc/systemd отсутствует symlink на этот файл. Если следовать той же логике что у модулей и конфигов nginx / apache - то запускаться должно только то что в /etc/systemd/, а не все подряд из /lib/systemd/

переходи на system v init.

или лучше тереби адептов systemd, пускай защищают свой любимый программный продукт.

Нет, мне лучше в это все не вникать. Первый раз за годы использования Debian мне пришлось лезть в эти дебри, и надеюсь что последний. То что тот же php session clean на многих машинах сам по себе отваливается, в результате 100% used inodes - это я знаю, но на этот счет у меня есть свои костыли, а с тем что подозрительно ошибки сегментации, спонтанно возникающие в разных процессах, совпадают по времени с запуском очистки временных файлов - это впервые.

Если следовать той же логике что у модулей и конфигов nginx / apache - то запускаться должно только то что в /etc/systemd/, а не все подряд из /lib/systemd/

необязательно. посмотри в /lib/systemd/system/timers.target.wants/

Как изменить время запуска?

создай каталог /etc/systemd/system/systemd-tmpfiles-clean.timer.d и в нём файл с любым именем и расширением .conf в этот файл напиши

[Timer]
OnCalendar=<тут во сколько запускать>

описательные бредни на имя юнита заменить

это было бы неплохо

P.S. мистика: в /etc/systemd отсутствует symlink на этот файл. Если следовать той же логике что у модулей и конфигов nginx / apache - то запускаться должно только то что в /etc/systemd/, а не все подряд из /lib/systemd/

Нет, почитай man systemd.unit, там всё расписано. TL;DR — запускаются не «те юниты, которые в /etc», а те юниты, на которые есть симлинки из *.target.wants, либо в /etc/systemd, либо в /lib/systemd.

Ставить просто OnCalendar=–* 02:00:00 ? Как применить изменения?

Создай файл с любым названием в каталоге /etc/systemd/system/systemd-tmpfiles-clean.service.d и впиши туда любые нужные изменения (существующие директивы отменяются путём присвоения им пустых значений):

# /etc/systemd/system/systemd-tmpfiles-clean.service.d/override.conf
[Timer]
OnBootSec=
OnUnitActiveSec=
OnCalendar=02:00:00
EOF

Беглым гуглением удалось обнаружить StatusUnitFormat=name в system.conf

спасибо, сделал, посмотрю завтра что будет

Вообще это не должно ни на что влиять. systemd очищает /tmp и /var/tmp от файлов, которые старше 10 и 30 дней соответственно (любым из трёх timestamp-ов, включая atime). Сильно сомневаюсь, что это создаёт какие-то проблемы с производительностью — ну какие могут быть проблемы от перебора файлов в /var/tmp, разве что если у тебя там сто гигабайт мусора в четырёхкилобайтных файлах.

разве что если у тебя там сто гигабайт мусора в четырёхкилобайтных файлах.

Или 100 тыщ мильенов файлов, которыми срёт туда php на более-менее нагруженном сайте. У меня из-за этого на несильно нагруженных проектах /tmp лежит в tmpfs(и на всякий случай переопределен tmpdir у php на /tmp/php, потому что даже ls по этому великолепию бывает вызывает боль) - дабы не насиловать SSD.

По поводу 100 тыщ мильенов файлов, которых rm -rf не берет («список слишком длинный») и приходится выпиливать через find знаю, но здесь не тот случай. Я бы не сказал что проблема была именно со временными файлами PHP, я даже сам не понял, с чем она была связана. Просто периодически начинали приходить уведомления о том что крон задача не запустилась из-за ошибки выделения памяти, потом в логах несколько раз было падение (рестарт) процессов, работающих 24/7. И все это по времени магическим образом совпадало со строчкой

Starting Cleanup of Temporary Directories

в логе, решил переставить от греха подальше. Как ни странно, проблема решена.