Автор Тема: pam_systemd(crond:session): Failed to release session: Interrupted system call  (Прочитано 704 раз)

Оффлайн keu

  • Начинающий
  • *
  • Сообщений: 19
Альт сервер 10. Без гуя.
Добавил в крон пару скриптов, запускаемых из-под обычного пользователя.
В лог посыпалось вот такое:

ноя 18 11:47:01 --- crond[15093]: pam_tcb(crond:session): Session opened for flow by (uid=0)
ноя 18 11:47:01 --- crond[15095]: (flow) CMD (/etc/flow-tools-ng/bin/flow-capture.pl --archive)
ноя 18 11:47:02 --- crond[15093]: pam_tcb(crond:session): Session closed for flow
ноя 18 11:47:02 --- crond[15093]: pam_systemd(crond:session): Failed to release session: Interrupted system call

ноя 18 11:50:01 --- crond[15107]: pam_tcb(crond:session): Session opened for root by (uid=0)
ноя 18 11:50:01 --- crond[15120]: (root) CMD (/usr/lib64/sa/sa1 -S DISK 1 1)
ноя 18 11:50:01 --- crond[15107]: pam_tcb(crond:session): Session closed for root
ноя 18 11:50:01 --- crond[15107]: pam_systemd(crond:session): Failed to release session: Interrupted system call



Причем ругается как на рутовые, так и на юзерские сессии, рандомным порядком - иногда 4 из 5 с руганью, иногда 4 из 5 без ругани. Рутовых заданий я не добавлял, ругается на системные (ну и на мои естественно).
При этом нарушений работоспособности скриптов не заметно, вроде пашут как надо. Тем не менее ситуация немного напрягает, я в тонкостях внутренностей systemd не разбираюсь, может у него какая утечка ресурсов будет или еще что неприятное.

Гугление дало очень мало вариантов, в том числе https://www.altlinux.org/Dynflow/FAQ, но там не рассказано что это вообще и почему так.

PS на экземпляре сервера без скриптов в логе такая же ругань, но строго с периодичностью раз в час, т.е. что-то типа системного задания hourly

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 246
  • Учиться .... Телепатами не рождаются, ими ....
    • Email
Вроде-бы правильнее делать systemd таймеры ?

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 246
  • Учиться .... Телепатами не рождаются, ими ....
    • Email

Оффлайн keu

  • Начинающий
  • *
  • Сообщений: 19
Вроде-бы правильнее делать systemd таймеры ?

Там один скрипт годится для таймера, а другой - это запуск демона и watchdog за ним. Его правильнее будет переделать в юнит systemd.
Вообще для меня после FreeBSD оказалось сюрпризом, что этот ваш systemd умеет работать только сам с собой.

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 246
  • Учиться .... Телепатами не рождаются, ими ....
    • Email
Надо время и желание, чтобы внедрить , что-нибудь типа openrc
Собрать его не проблема (он у меня в кармане есть), а вот как правильно его администрировать и тому подобное, на это у меня времени нет :-))

Оффлайн keu

  • Начинающий
  • *
  • Сообщений: 19
Собрать его не проблема (он у меня в кармане есть), а вот как правильно его администрировать и тому подобное, на это у меня времени нет :-))

То-то и оно. Система должна быть поддерживаемой и с определенным будущим. Я и за sysv немного опасаюсь, не отомрет ли постепенно.

В целом, наверное, проще переучиться под незнакомую систему, чем делать под себя знакомую :-)

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 5 183
  • antohami@
cron должен на systemd работать. Надо бы разобраться, что за беда...

Оффлайн keu

  • Начинающий
  • *
  • Сообщений: 19
cron должен на systemd работать. Надо бы разобраться, что за беда...

Так он работает. Но вот сыплет ошибками. И мне далеко не хватает знаний понять, можно ли эти ошибки игнорировать, или дело серьезное.

Оффлайн keu

  • Начинающий
  • *
  • Сообщений: 19
cron должен на systemd работать. Надо бы разобраться, что за беда...

Проверил на всех доступных мне экземплярах Альт Линукса, которые непрерывно включены. Три Альт-сервер p10, два alt-server-starterkit-p10, две Workstation 10. На всех в логе эта ошибка, причем свои задачи в крон я добавлял только на одной машине. Где моих задач нет, там ругается на системные вызовы, типа run-parts /etc/cron.hourly. Где мои задачи есть, там ругается на всех, случайным образом и с разной частотой. Версия systemd-249.12-alt3.x86_64

Для сравнения есть один сервер на Ubuntu 20, с моими задачами в кроне, там в логе ругани нет (смотрел так же через journalctl -e), сообщения типа Session closed - есть.
systemd   245.4-4ubuntu3.15

Откопал еще в залежах виртуалок сервер РедОС. Ядро 5.15.35-1.el7.3.x86_64, systemd-246.10-14.el7.x86_64. Ошибок в логе нет, но и сообщений Session opened/closed тоже, возможно, иначе настроен уровень логирования.

На этом основании пока  невозможно строить предположения, что это - регрессия в новых версиях systemd или ошибка в собственно Альте.

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 19 908
    • Домашняя страница
    • Email
Вы сами пакеты, обеспечивающие crond, сравнивайте.
Андрей Черепанов (cas@)

Оффлайн keu

  • Начинающий
  • *
  • Сообщений: 19
Вы сами пакеты, обеспечивающие crond, сравнивайте.

Альты: vixie-cron-4.1.20060426-alt10.3.x86_64, vixie-cron-4.1.20060426-alt10.2.x86_64
Убунту: cron 3.0pl1-136ubuntu1
РеДОС: cronie-1.5.6-1.el7.x86_64

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 19 908
    • Домашняя страница
    • Email
Вот поэтому.
Андрей Черепанов (cas@)

Оффлайн keu

  • Начинающий
  • *
  • Сообщений: 19
Вот поэтому.

И что теперь с этим делать? Игнорировать и считать чисто косметическим дефектом? Или это потенциальная утечка ресурсов, с которой нужно разбираться?


Вчера вечером поставил еще три виртуалки. Альт сервер 9.2, регулярку Mate, регулярку Jeos (в последней не стал настраивать сеть). Ничего своего в крон не добавлял.
В первой vixie-cron-4.1.20060426-alt10.2.x86_64, systemd-246.14-alt1.x86_64
во вторых двух vixie-cron-4.1.20060426-alt10.3.x86_64, systemd-251.8-alt1.x86_64

Итого за период примерно с 19-00 вчера по 12-00 сегодня соответственно 6, 18 и 0 ошибок в логе (journalctl -t crond | grep -i fail | wc -l) на 379, 75 и 57 строк (journalctl -t crond | wc -l). Подобный же разброс частоты ошибок был и в предыдущих опытах выше по треду. Может быть, дело в нагрузке системы и таймаутах?