ALT Linux Bugzilla – #33018

Предлагаю перевесить на osec (поскольку взрывается именно он); на сизиф не перевешиваю, т.к. с osec-1.2.7-alt3.x86_64 и osec-cronjob-1.2.7-alt3.x86_64 у меня не воспроизводится.

Не воспроизводится
/usr/share/osec/osec.cron от рута просто отработало.

osec-1.2.7-alt2.M80P.1
osec-cronjob-1.2.7-alt2.M80P.1

(В ответ на комментарий №2)
> Не воспроизводится
> /usr/share/osec/osec.cron от рута просто отработало.
> 
> osec-1.2.7-alt2.M80P.1
> osec-cronjob-1.2.7-alt2.M80P.1

У меня два сервера. На одном всё ОК, на другом вышеуказанная ошибка.
Из существенных отличий между серверами - на одном стоит обычный syslog (тут с osec всё в порядке), на втором (проблемном) - syslog-ng.

У меня тоже не воспроизводится, (In reply to comment #3)

> У меня два сервера. На одном всё ОК, на другом вышеуказанная ошибка.

Надо найти разницу.

> Из существенных отличий между серверами - на одном стоит обычный syslog (тут с
> osec всё в порядке), на втором (проблемном) - syslog-ng.

Syslog никак не должен влиять, по идее. У меня тоже не воспроизводится, в том числе и там, где стоит syslog-ng.

Можно попробовать запустить /usr/bin/osec через strace, вдруг что-то видно будет. Как-то так:

strace /usr/bin/osec -X /etc/osec/exclude.conf -D /var/lib/osec -f /etc/osec/dirs.conf

(В ответ на комментарий №4)
> У меня тоже не воспроизводится, (In reply to comment #3)
> 
> > У меня два сервера. На одном всё ОК, на другом вышеуказанная ошибка.
> 
> Надо найти разницу.
> 
> > Из существенных отличий между серверами - на одном стоит обычный syslog (тут с
> > osec всё в порядке), на втором (проблемном) - syslog-ng.
> 
> Syslog никак не должен влиять, по идее. У меня тоже не воспроизводится, в том
> числе и там, где стоит syslog-ng.
> 
> Можно попробовать запустить /usr/bin/osec через strace, вдруг что-то видно
> будет. Как-то так:
> 
> strace /usr/bin/osec -X /etc/osec/exclude.conf -D /var/lib/osec -f
> /etc/osec/dirs.conf

strace заканчивается следующим блоком:
...
mprotect(0xb75c6000, 4096, PROT_READ)   = 0
mprotect(0xb75a7000, 4096, PROT_READ)   = 0
mprotect(0xb75ac000, 4096, PROT_READ)   = 0
mprotect(0xb75cd000, 4096, PROT_READ)   = 0
set_tid_address(0xb75f9768)             = 30683
set_robust_list(0xb75f9770, 12)         = 0
rt_sigaction(SIGRTMIN, {sa_handler=0xb75b2960, sa_mask=[], sa_flags=SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0xb75b29e0, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
ugetrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sysname="Linux", nodename="alt-serv.smpbank", ...}) = 0
munmap(0xb75d4000, 45858)               = 0
lstat64("/var/run/samba/winbindd", 0xbf954c2c) = -1 ENOENT (No such file or directory)
write(2, "osec: ", 6osec: )                   = 6
write(2, "getgrgid_r", 10getgrgid_r)              = 10
write(2, ": No such file or directory\n", 28: No such file or directory
) = 28
write(1, "/bin\tstat\tchanged\told", 21/bin     stat    changed old) = 21
_llseek(3, -122, [59], SEEK_CUR)        = 0
exit_group(1)                           = ?
+++ exited with 1 +++

А зачем ему /var/run/samba/winbindd ? В сборочных зависимостях от Самбы ничего нет.

(In reply to comment #6)
> А зачем ему /var/run/samba/winbindd ? В сборочных зависимостях от Самбы ничего
> нет.

А бог его знает, зачем он туда лезет. Я не могу понять, откуда скрипт берёт этот файл.
Ещё заметил, что в каталоге /var/lib/osec все файлы osec.cdb.* от 17 января. Видимо это дата последнего удачного выполнения. 
Я удалил все эти файлы, после чего скрипт отработал без ошибок, пересоздав базы и отправив отчёт по почте.
Я конечно, потерял информацию по изменениям до этого момента, но это для меня не сильно принципиально. Главное, чтобы в дальнейшем скрипт работал без ошибок.
Посмотрю, как он отработает завтра уже в автоматическом режиме.

(In reply to comment #7)

> Я удалил все эти файлы, после чего скрипт отработал без ошибок,
> пересоздав базы и отправив отчёт по почте.

Тогда, вероятно, надо таки на Сизиф перевешивать. Но ошибка, похоже, редко воспроизводится.

> Я не могу понять, откуда скрипт берёт этот файл.

А в /etc/osec/dirs.conf не было ничего с /var когда-нибудь ?

(In reply to comment #7)

> Посмотрю, как он отработает завтра уже в автоматическом режиме.

Можно, кстати, и сейчас: время в cron поправить, потом обратно вернуть. Или в новом файле задание в другое время описать.

(In reply to comment #8)
> (In reply to comment #7)
> 
> > Я не могу понять, откуда скрипт берёт этот файл.
> 
> А в /etc/osec/dirs.conf не было ничего с /var когда-нибудь ?

Точно не было.

После вчерашнего удаления из каталога /var/lib/osec файлов osec.cdb.* и последующего из пересоздания сегодня скрипт отработал без ошибок, корректно описав произведённые за ночь изменения.

(In reply to comment #11)

> После вчерашнего удаления из каталога /var/lib/osec файлов osec.cdb.* и
> последующего из пересоздания сегодня скрипт отработал без ошибок, корректно
> описав произведённые за ночь изменения.

Я, пока, не заметил, чтобы у меня где-то osec отпал после обновления. Наверное, стоило сохранить /var/lib/osec/osec.cdb.* на всякий случай, для разбора...

Кое-что попалось (причём база с непонятного времени - osec долго отсутствовал тут):

# /usr/share/osec/osec.cron
osec: /bin: osec_field(odata): Unable to get 'xattr' from database value
Program (/usr/bin/osec) exited abnormally, exit code = 1

Ошибка другая, но связанная, тоже, с базой. Лечение аналогичное. Только вот вопрос... Стоит ли неопознанные ошибки исправлять автоматом ? Это ведь и результатом внешнего воздействия может быть.

/var/lib/osec/* сохранил пока.

(В ответ на комментарий №13)
> Кое-что попалось (причём база с непонятного времени - osec долго отсутствовал
> тут):
> 
> # /usr/share/osec/osec.cron
> osec: /bin: osec_field(odata): Unable to get 'xattr' from database value
> Program (/usr/bin/osec) exited abnormally, exit code = 1
> 
> Ошибка другая, но связанная, тоже, с базой. Лечение аналогичное. Только вот
> вопрос... Стоит ли неопознанные ошибки исправлять автоматом ? Это ведь и
> результатом внешнего воздействия может быть.
> 
> /var/lib/osec/* сохранил пока.

Такого случаться не должно. osec имеет инструменты для миграции базы. Возможно я чего-то не учёл. Расскажите подробнее о обновлении и о том что и как запускалось.
Думаю, лучше это в отдельную багу оформить.

(In reply to comment #14)

> > # /usr/share/osec/osec.cron
> > osec: /bin: osec_field(odata): Unable to get 'xattr' from database value
> > Program (/usr/bin/osec) exited abnormally, exit code = 1

> Думаю, лучше это в отдельную багу оформить.

Bug 33207. Этот баг тоже на Сизиф, наверное. Вряд ли это специфика p8.

osec-1.3.0-alt1 -> sisyphus:

 Mon Jun 15 2020 Alexey Gladkov <legion@altlinux.ru> 1.3.0-alt1
 - New version (1.3.0);
 - Database creation is more error tolerant (ALT#38408, ALT#33207):
    - if osec failed to get the owner and user group by id, a numeric value will be used (ALT#33018).
    - if osec failed to read the file to calculate the checksum, an empty value will be used.
    - if osec failed to read symlink an empty value will be used.
 - The mtime field includes nanoseconds.
 - The basepath field has been added to the database.