asio, bad file descriptor(EBADF)
есть некоторый код, написанный с использованием asio, реализующий обмен некоторыми данными между клиентом и сервером.
- подключение к серверу
- обмен публичными ключами
- отсылает один пакет данных
- в основном находится в ожидании
проблема в том, что первые три пункта выполняются успешно, но после некоторого ожидания, при попытке послать серверу очередные данные, запись завершается с ошибкой «bad file descriptor»(EBADF)
попытки понять кто/кодга и почему закрывает сокет — ничего не дали. (сокет, вроде бы, ни клиент, ни сервер, не закрывают)
вопрос в том, есть ли какой-то софт, которым я могу мониторить состояние сокета извне?
ну и вообще, какие мысли?
Bad file descriptor что это
Есть сервер, который используя жаббероподобный протокол, обслуживает клиентов. Всё многопоточно, работает в режиме один поток — один клиент, блокирующий режим.
В теле цикла select, который следит за несколькими сокетами. один сокет к клиенту, другие — для внутренних целей (синхронизация и так дальше, используются unix сокеты).
все чтения/записи с/в сокет и другие блокирующие операции с сокетами (open, close. ) завернуты в TEMP_FAILURE_RETRY или делается проверка на errno==-1 и EINT. Это надо, так как приложение активно использует сигналы (Основную массу времени поток спит в select. А другие потоки посылают SIGUSR1/SIGUSR2 что бы пробудить поток (обычно это нужно только для удаления дубликатов — пользователи любят подключаться несколько раз — старые сессии удаляем). На другие сигналы (например SIGSERV) тоже повешены обработчики, которые находят поток-вредитель и завершают его.
И вот время от времени на клиентах при попытке сделать select возникает ошибка и errno возвращает Bad file descriptor. Интересно то, что возникает в нескольких потоках практически одновременно.
Интересуют методы выявления, какой сокет может быть плохим или как не допустить вообще такой ситуации, может есть какой-нибудь макрос/функция, что бы проверить, что сокет стал плохим.
Re: Ошибка Bad file descriptor
| От: | zaufi |
| Дата: | 17.02.09 10:46 |
| Оценка: |
Здравствуйте, OdesitVadim, Вы писали:
OV>Есть сервер, который используя жаббероподобный протокол, обслуживает клиентов. Всё многопоточно, работает в режиме один поток — один клиент, блокирующий режим.
?? чото я недопонял кто кого блокирует ??
OV>В теле цикла select, который следит за несколькими сокетами. один сокет к клиенту, другие — для внутренних целей (синхронизация и так дальше, используются unix сокеты).
OV>все чтения/записи с/в сокет и другие блокирующие операции с сокетами (open, close. ) завернуты в TEMP_FAILURE_RETRY или делается проверка на errno==-1 и EINT. Это надо, так как приложение активно использует сигналы (Основную массу времени поток спит в select. А другие потоки посылают SIGUSR1/SIGUSR2 что бы пробудить поток (обычно это нужно только для удаления дубликатов — пользователи любят подключаться несколько раз — старые сессии удаляем).
OMG! зачем так сложно то все? чем mutexы с conditionами не устраивают?
OV> На другие сигналы (например SIGSERV) тоже повешены обработчики, которые находят поток-вредитель и завершают его.
может SIGSEGV?? я конечно не знаю деталей твоего приложения но еси оно валицо по SIGSEGV нада найти баг и исправить его а не закрывать на это глаза делая вид что ничо страшного не происходит
OV>И вот время от времени на клиентах при попытке сделать select возникает ошибка и errno возвращает Bad file descriptor. Интересно то, что возникает в нескольких потоках практически одновременно.
OV>Интересуют методы выявления, какой сокет может быть плохим или как не допустить вообще такой ситуации, может есть какой-нибудь макрос/функция, что бы проверить, что сокет стал плохим.
сокет сам по себе «плохим» не становится. еси полоть закрытый (не существующий) сокет (дескриптор) получишь именна эту ошибку. погоняй свою прогу под valgrindом — imho многа нового узнаешь о поведении своей проги
Re[2]: Ошибка Bad file descriptor
| От: | OdesitVadim |
| Дата: | 17.02.09 14:59 |
| Оценка: |
Здравствуйте, zaufi, Вы писали:
Z>Здравствуйте, OdesitVadim, Вы писали:
OV>>Есть сервер, который используя жаббероподобный протокол, обслуживает клиентов. Всё многопоточно, работает в режиме один поток — один клиент, блокирующий режим.
Z>?? чото я недопонял кто кого блокирует ??
Сокеты в блокирующем режиме.
Z>OMG! зачем так сложно то все? чем mutexы с conditionами не устраивают?
Не все мютексами можно разрулить.
OV>> На другие сигналы (например SIGSERV) тоже повешены обработчики, которые находят поток-вредитель и завершают его.
Z>может SIGSEGV?? я конечно не знаю деталей твоего приложения но еси оно валицо по SIGSEGV нада найти баг и исправить его а не закрывать на это глаза делая вид что ничо страшного не происходит
Да, соскользнула рука. да эти события как неуловимые джо. Нет, нет. а потом хоп. но отрубать сразу всех клиентов как то не с руки.
Z>сокет сам по себе «плохим» не становится. еси полоть закрытый (не существующий) сокет (дескриптор) получишь именна эту ошибку. погоняй свою прогу под valgrindом — imho многа нового узнаешь о поведении своей проги
Да в том то дело, что если я сокет закрываю, то переменная для сокета получает значение -1. и кругом есть проверки на это -1.
под valgrindом гонял. часть отловил. Но к сожалению, он не всё может розрулить и основная масса сообщений — это либо баги валгринда, на их сайте написано «не обращать внимания», либо то, что даже непонятно, как устранить.
Но это не так важно, так как на отладочной машине я не могу воспроизвести ситуацию. А на продакшине — повторяется.
Чувствую, буду ещё жесче проверять сокеты.
Использование pipe в Python «Bad file descriptor»
Пытаюсь написать калькулятор, в котором все вычисления производятся в дочернем процессе, после чего он возвращает результат родительскому. Программа отрабатывает корректно один раз, а дальше-выдает ошибку «Bad file descriptor» В чем может быть причина? Все ломается как только добавляю цикл.
import os class Calculator: operations = ['+', '-', '*', '/', '.'] def add(self, a, b): return a + b def subtract(self, a, b): return a - b def multiply(self, a, b): return a * b def divide(self, a, b): return a / b def get_expression(self): user_input = input("Input the expression: op n1 n2 ") return bytes(user_input, encoding="UTF-8") def check_expression(self, expression): if len(expression) != 3 : return 0 if (expression[0] not in self.operations): return 0 else: return 1 def check_quit(self, user_input): user_input = user_input.decode("utf-8").split() if user_input[0] == '.': return 1 else: return 0 def find_result(self, user_input): user_input = user_input.decode("utf-8").split() operand = user_input[0] a = int(user_input[1]) b = int(user_input[2]) if operand == '+': return str(my_cl.add(a, b)).encode("utf-8") elif (operand == '-'): return str(my_cl.subtract(a, b)).encode("utf-8") elif (operand == '*'): return str(my_cl.multiply(a, b)).encode("utf-8") elif (operand == '/'): return str(my_cl.divide(a, b)).encode("utf-8") else: print("ERROR") my_cl = Calculator() r2, w2 = os.pipe() r1, w1 = os.pipe() pid = os.fork() while(1): if pid > 0: os.close(r2) os.close(w1) user_input = my_cl.get_expression() os.write(w2, user_input) print("Result:", os.read(r1, 100).decode("utf-8")) else: os.close(w2) os.close(r1) user_input = os.read(r2, 100) os.write(w1, my_cl.find_result(user_input)) forum.lissyara.su
Сталина давно нэт. Чтоби спасти Россию, ищитэ его внутри сэбя.
Bad file descriptor on UFS
Простые/общие вопросы по UNIX системам. Спросите здесь, если вы новичок
Правила форума
Убедительная просьба юзать теги [cоde] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
Первое новое сообщение • 11 сообщений • Страница 1 из 1
Miguel ефрейтор Сообщения: 58 Зарегистрирован: 2011-03-28 8:56:22
Bad file descriptor on UFS
Здрасте, товарищи)
Сабж. Поддох хард под freebsd. Сыпаться начал, 1 бэд есть, не ремапится. я с него на другой такой же, но рабочий (от греха подальше) хард вот так вот
dd if=/dev/ad0 of=/ad4 conv=noerror,syncданные клонировал. заменил клонированным. все нормально, только когда fsck_ufs для одного из разделов делаешь, пишет
** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames MISSING '.' I=1696289 OWNER=root MODE=40755 SIZE=512 MTIME=Nov 30 16:37 2010 DIR=/local/share/locale/rw UNEXPECTED SOFT UPDATE INCONSISTENCY CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS LC_MESSAGES UNEXPECTED SOFT UPDATE INCONSISTENCY когда ls вот так делаешь, пишет то, что в листинге ниже. как бы это пофиксить?
ls -l /usr/local/share/locale/rw ls: LC_MESSAGES: Bad file descriptor total 0 Последний раз редактировалось f_andrey 2011-03-28 14:20:17, всего редактировалось 1 раз.
Причина: Автору, выбирайте пожалуйста раздел соответствуюший тематике вашего сообщения. приводите полную диагностику, больше логов больше вероятности ответа, а не флуда
Даже стеклотара чья-то аватара.
Miguel
Хостинг HostFood.ru
Услуги хостинговой компании Host-Food.ru
Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/
Miguel ефрейтор Сообщения: 58 Зарегистрирован: 2011-03-28 8:56:22
Bad file descriptor on UFS
fsck_ufs -b [номер альтернативного суперблока] не помогает
Даже стеклотара чья-то аватара.
Miguel
unix-admin ст. сержант Сообщения: 324 Зарегистрирован: 2010-11-26 12:43:04 Откуда: Cornucopia
Re: Bad file descriptor on UFS
fsck -f -y unix-admin
Miguel ефрейтор Сообщения: 58 Зарегистрирован: 2011-03-28 8:56:22
Re: Bad file descriptor on UFS
Да, конечно, в синглюзер.
спасибо, буду пробовать.
Читал эту статью. Но! Битых секторов на этом харде нет. он живой, я его гонял MHDD, все хорошо. и вот теперь понять не могу, что делать то. это, имхо, глюк фс.
Даже стеклотара чья-то аватара.
Miguel
Miguel ефрейтор Сообщения: 58 Зарегистрирован: 2011-03-28 8:56:22
Re: Bad file descriptor on UFS
не помогает
fsck -y -f
в однопользовательском режиме. даже
fsck_ufs -y -f -bне помогает.
Даже стеклотара чья-то аватара.
Miguel
savio лейтенант Сообщения: 813 Зарегистрирован: 2007-11-08 15:46:43 Откуда: UA
Re: Bad file descriptor on UFS
аналогичная проблема. решения так и не нашли?
Помни о смерти, все суета сует.
savio
Miguell проходил мимо
Re: Bad file descriptor on UFS
Непрочитанное сообщение Miguell » 2014-03-13 0:39:07
clriMiguell
Miguell проходил мимо
Re: Bad file descriptor on UFS
Непрочитанное сообщение Miguell » 2014-03-13 0:42:28
Пардон, пароль забыл что-то.
да, clri, потом fsck. Но я что-то тогда то ли tar-ом все запаковал да форматнул, то ли жестак поменял.
Miguell
savio лейтенант Сообщения: 813 Зарегистрирован: 2007-11-08 15:46:43 Откуда: UA
Re: Bad file descriptor on UFS
нда. у меня даже touch нету, /usr/bin/ пуст.
что интересно, на винте (который умирает) все файлы есть. Сделал бекап по провереной методе
в single user, в этом же режиме развернул на другом ПК на другой новый винт. Все разедлы вроде ок, а вот /usr не повезло сним.
Щас тоже покавать таром буду.
Помни о смерти, все суета сует.
savio
Alex Keda стреляли. Сообщения: 35450 Зарегистрирован: 2004-10-18 14:25:19 Откуда: Made in USSR Контактная информация:
Re: Bad file descriptor on UFS
Miguel писал(а): не помогает
fsck -y -f
в однопользовательском режиме. даже
fsck_ufs -y -f -bне помогает.
выхлоп покажите.
должно помочь, вообще-то
Убей их всех! Бог потом рассортирует.
Alex Keda
Miguel ефрейтор Сообщения: 58 Зарегистрирован: 2011-03-28 8:56:22
Re: Bad file descriptor on UFS
Ну что же. Расставим палки рядом с Ы. Тема старая, тех данных и жестких дисков уж нет и в помине. Но, тем не менее, имеет смысл поговорить об этом.
Какой был выхлоп fsck_ufs -y -f -b я не помню, 2011 год шел, однако. Но суть в том, что это не помогало, а почему? Я мыслю так, что первый суперблок и его копии ведь со временем синхронизируются. А проблема с битой инодой всплыла далеко не сразу. И попытки выполнить fsck_ufs -y -f -b были предприняты не после первого затыка на ручной проверке после перезагрузки сервера. А на диск писалась инфа, удалялась с него. И когда я сдампил с помощью dd образ с этого, как оказалось, плохого диска на его хорошего близнеца, то, видимо, все суперблоки уже содержали одинаково битую запись о том директории (см 1 пост темы).
Поэтому я искал способ затереть иноду вручную. Но, тогда же, уже на новых хардах и железе я перешел на 9 версию фри с 8.2, емнип. И как-то однажды смотрю — нет уже этой проблемы. А уж потом узнал про clri.