LINUX.ORG.RU
ФорумAdmin

coredump после обновления до wheezy

 ,


0

1

Локальная сеть, два файл-сервера с Samba, один PDC, другой BDC, авторизация через LDAP. Изначально стояли Debian 6 на обоих. Решился обновиться до Debian 7. На BDC обновление прошло нормально, ну если не считать мелких косяков. В части Samba все прошло гладко. На PDC тоже все обновилось, все работает, никаких жалоб. Однако, в процессе стал замечать в «/» на PDC стал время от времени появляться файл core. Файл бинарный, насколько понимаю это какой-то дамп. При попытке открыть его просмотрщиком MC видна запись: «from smbstatus -l», потому грешу на самбу. Однако никаких сообщений типа «Panic or segfault in Samba» на мыло не приходит, сам скрипт panic-action работает, проверял. Повторю, что все ровно, все работает. Если бы не этот периодически появляющийся файл, я бы вообще не беспокоился. Что это такое, в чем может быть причина? На BDC такого не наблюдается, конфиги самбы идентичны в глобальной секции на обоих серверах (ну, с поправкой на имена). Самба-шары имеются на обоих серверах, функционируют нормально. Да, в директории логов самбы core/smbd есть файл core годичной давности с записью «from smbd -D», создался задолго до обновления. В логе log.smbd имеются записи «Cleaning up brl and lock database after unclean shutdown» По времени не связанные с временем создания злополучного core в корневике.

★★★

Последнее исправление: cetjs2 (всего исправлений: 3)

Лучше core грузить в gdb через команду ″core-file ИМЯ_файла″, а не открывать в mc, тогда ещё может быть выведено имя сигнала. А так гуглится такой баг https://bugzilla.samba.org/show_bug.cgi?id=9058 , которые убрали 3.6.8, может это ваш. Если всё работает, ИМХО, просто ждать обновлений.

mky ★★★★★
()
Ответ на: комментарий от mky

Гуглил тоже, конечно. Тоже склоняюсь к мысли что бага уйдет с апдейтом каким-нибудь. с gdb попробую, спасибо.

conalex ★★★
() автор топика
Ответ на: комментарий от conalex

Поковырялся с gdb. запустил gdb smbstatus /core. backtrace выдал segfault в traverse_fn (at locking/locking.c:1768) при обращении к библиотечной функции strlen(). Там, судя по исходникам, обрабатываются вынутые из tdb пути до шар и происходит вылет. Видимо, некорректная строка пути. Отчего - непонятно.

conalex ★★★
() автор топика
Ответ на: комментарий от conalex

В той ссылке, что я дал ведь как раз в этом месте сегфолт и случался, и патч там, где достаточно сильно меняют traverse_fn (). Как я понял, если файл удалён, но клиент ещё его не закрыл, то нельзя из tdb читать имя (путь) такого файла.

mky ★★★★★
()
Ответ на: комментарий от mky

Да-да, спасибо. Подожду апдейта с фиксами.

conalex ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.