33018 2017-01-20 11:40:56 +0300 Ошибка osec: getgrgid_r: No such file or directory 2020-06-15 18:57:00 +0300 1 1 4 Development Sisyphus osec unstable all Linux CLOSED FIXED P3 normal --- 1 VladGousev legion VladGousev asy evg legion mike nbr qa-sisyphus oldest_to_newest 161398 0 VladGousev 2017-01-20 11:40:56 +0300 После обновления 13.01.2017 сломался скрипт проверки. После запуска скрипта (хоть руками, хоть через cron) "/usr/share/osec/osec.cron" отображаются ошибки: # ./osec.cron osec: getgrgid_r: No such file or directory Program (/usr/bin/osec) exited abnormally, exit code = 1 Use of uninitialized value $fields[4] in substitution (s///) at /usr/bin/osec_reporter line 107, <STDIN> line 2. Use of uninitialized value $fields[4] in split at /usr/bin/osec_reporter line 112, <STDIN> line 2. После этого на почту приходит письмо, что изменений не обнаружено, но видно, что проверка оборвалась не первом каталоге из /etc/osec/dirs.conf: Processing /bin ... This is a report generated by osec at 'Fri Jan 20 11:38:05 MSK 2017' No changes 162074 1 mike 2017-02-22 10:32:28 +0300 Предлагаю перевесить на osec (поскольку взрывается именно он); на сизиф не перевешиваю, т.к. с osec-1.2.7-alt3.x86_64 и osec-cronjob-1.2.7-alt3.x86_64 у меня не воспроизводится. 162079 2 nbr 2017-02-22 12:13:09 +0300 Не воспроизводится /usr/share/osec/osec.cron от рута просто отработало. osec-1.2.7-alt2.M80P.1 osec-cronjob-1.2.7-alt2.M80P.1 162122 3 VladGousev 2017-02-24 13:33:32 +0300 (В ответ на комментарий №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. 162135 4 asy 2017-02-26 20:34:39 +0300 У меня тоже не воспроизводится, (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 162187 5 VladGousev 2017-02-28 16:55:24 +0300 (В ответ на комментарий №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 +++ 162191 6 asy 2017-02-28 18:32:57 +0300 А зачем ему /var/run/samba/winbindd ? В сборочных зависимостях от Самбы ничего нет. 162193 7 VladGousev 2017-03-01 10:12:41 +0300 (In reply to comment #6) > А зачем ему /var/run/samba/winbindd ? В сборочных зависимостях от Самбы ничего > нет. А бог его знает, зачем он туда лезет. Я не могу понять, откуда скрипт берёт этот файл. Ещё заметил, что в каталоге /var/lib/osec все файлы osec.cdb.* от 17 января. Видимо это дата последнего удачного выполнения. Я удалил все эти файлы, после чего скрипт отработал без ошибок, пересоздав базы и отправив отчёт по почте. Я конечно, потерял информацию по изменениям до этого момента, но это для меня не сильно принципиально. Главное, чтобы в дальнейшем скрипт работал без ошибок. Посмотрю, как он отработает завтра уже в автоматическом режиме. 162196 8 asy 2017-03-01 13:22:53 +0300 (In reply to comment #7) > Я удалил все эти файлы, после чего скрипт отработал без ошибок, > пересоздав базы и отправив отчёт по почте. Тогда, вероятно, надо таки на Сизиф перевешивать. Но ошибка, похоже, редко воспроизводится. > Я не могу понять, откуда скрипт берёт этот файл. А в /etc/osec/dirs.conf не было ничего с /var когда-нибудь ? 162199 9 asy 2017-03-01 13:28:51 +0300 (In reply to comment #7) > Посмотрю, как он отработает завтра уже в автоматическом режиме. Можно, кстати, и сейчас: время в cron поправить, потом обратно вернуть. Или в новом файле задание в другое время описать. 162217 10 VladGousev 2017-03-02 10:13:22 +0300 (In reply to comment #8) > (In reply to comment #7) > > > Я не могу понять, откуда скрипт берёт этот файл. > > А в /etc/osec/dirs.conf не было ничего с /var когда-нибудь ? Точно не было. 162218 11 VladGousev 2017-03-02 10:20:30 +0300 После вчерашнего удаления из каталога /var/lib/osec файлов osec.cdb.* и последующего из пересоздания сегодня скрипт отработал без ошибок, корректно описав произведённые за ночь изменения. 162266 12 asy 2017-03-05 12:41:10 +0300 (In reply to comment #11) > После вчерашнего удаления из каталога /var/lib/osec файлов osec.cdb.* и > последующего из пересоздания сегодня скрипт отработал без ошибок, корректно > описав произведённые за ночь изменения. Я, пока, не заметил, чтобы у меня где-то osec отпал после обновления. Наверное, стоило сохранить /var/lib/osec/osec.cdb.* на всякий случай, для разбора... 162290 13 asy 2017-03-06 16:12:11 +0300 Кое-что попалось (причём база с непонятного времени - 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/* сохранил пока. 162294 14 legion 2017-03-06 16:30:03 +0300 (В ответ на комментарий №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 имеет инструменты для миграции базы. Возможно я чего-то не учёл. Расскажите подробнее о обновлении и о том что и как запускалось. Думаю, лучше это в отдельную багу оформить. 162303 15 asy 2017-03-06 17:20:43 +0300 (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. 190679 16 repository-robot 2020-06-15 18:57:00 +0300 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.