Bug 33018 - Ошибка osec: getgrgid_r: No such file or directory
: Ошибка osec: getgrgid_r: No such file or directory
Status: NEW
: Sisyphus
(All bugs in Sisyphus/osec)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2017-01-20 11:40 by
Modified: 2017-03-06 17:20 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2017-01-20 11:40:56
После обновления 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
------- Comment #1 From 2017-02-22 10:32:28 -------
Предлагаю перевесить на osec (поскольку взрывается именно он); на сизиф не
перевешиваю, т.к. с osec-1.2.7-alt3.x86_64 и osec-cronjob-1.2.7-alt3.x86_64 у
меня не воспроизводится.
------- Comment #2 From 2017-02-22 12:13:09 -------
Не воспроизводится
/usr/share/osec/osec.cron от рута просто отработало.

osec-1.2.7-alt2.M80P.1
osec-cronjob-1.2.7-alt2.M80P.1
------- Comment #3 From 2017-02-24 13:33:32 -------
(В ответ на комментарий №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.
------- Comment #4 From 2017-02-26 20:34:39 -------
У меня тоже не воспроизводится, (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
------- Comment #5 From 2017-02-28 16:55:24 -------
(В ответ на комментарий №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 +++
------- Comment #6 From 2017-02-28 18:32:57 -------
А зачем ему /var/run/samba/winbindd ? В сборочных зависимостях от Самбы ничего
нет.
------- Comment #7 From 2017-03-01 10:12:41 -------
(In reply to comment #6)
> А зачем ему /var/run/samba/winbindd ? В сборочных зависимостях от Самбы ничего
> нет.

А бог его знает, зачем он туда лезет. Я не могу понять, откуда скрипт берёт
этот файл.
Ещё заметил, что в каталоге /var/lib/osec все файлы osec.cdb.* от 17 января.
Видимо это дата последнего удачного выполнения. 
Я удалил все эти файлы, после чего скрипт отработал без ошибок, пересоздав базы
и отправив отчёт по почте.
Я конечно, потерял информацию по изменениям до этого момента, но это для меня
не сильно принципиально. Главное, чтобы в дальнейшем скрипт работал без ошибок.
Посмотрю, как он отработает завтра уже в автоматическом режиме.
------- Comment #8 From 2017-03-01 13:22:53 -------
(In reply to comment #7)

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

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

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

А в /etc/osec/dirs.conf не было ничего с /var когда-нибудь ?
------- Comment #9 From 2017-03-01 13:28:51 -------
(In reply to comment #7)

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

Можно, кстати, и сейчас: время в cron поправить, потом обратно вернуть. Или в
новом файле задание в другое время описать.
------- Comment #10 From 2017-03-02 10:13:22 -------
(In reply to comment #8)
> (In reply to comment #7)
> 
> > Я не могу понять, откуда скрипт берёт этот файл.
> 
> А в /etc/osec/dirs.conf не было ничего с /var когда-нибудь ?

Точно не было.
------- Comment #11 From 2017-03-02 10:20:30 -------
После вчерашнего удаления из каталога /var/lib/osec файлов osec.cdb.* и
последующего из пересоздания сегодня скрипт отработал без ошибок, корректно
описав произведённые за ночь изменения.
------- Comment #12 From 2017-03-05 12:41:10 -------
(In reply to comment #11)

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

Я, пока, не заметил, чтобы у меня где-то osec отпал после обновления. Наверное,
стоило сохранить /var/lib/osec/osec.cdb.* на всякий случай, для разбора...
------- Comment #13 From 2017-03-06 16:12:11 -------
Кое-что попалось (причём база с непонятного времени - 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/* сохранил пока.
------- Comment #14 From 2017-03-06 16:30:03 -------
(В ответ на комментарий №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 имеет инструменты для миграции базы. Возможно
я чего-то не учёл. Расскажите подробнее о обновлении и о том что и как
запускалось.
Думаю, лучше это в отдельную багу оформить.
------- Comment #15 From 2017-03-06 17:20:43 -------
(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.