Неведомая ошибка!
 

Добрый день господа! С недавнего времени возникли проблемы с сервером под OpenBSD. Сервер стал "виснуть", но неокончательно и безповоротно, а как бы не до конца, прежде всего рубится подключение по ssh, перестает функционировать почта, но при этом интернет продолжает исправно раздаваться, скайп работает, но аська отваливается, что наводит на размышления о том, что DNS тоже начинает жить своей неведомой жизнью. Для полного счастья совершенно необъяснимо начинает вести себя клавиатура подключенная локально. Лампочки на ней работать продолжают, можно переключаться между сеанcами (alt+ctrl+f1/f2), но написать ничего нельзя, буквы не печатаются, помогает только перезагрузка через reset(
До недавнего времени все это проходило без каких-нибудь сообщений об ошибках и тут, когда я уж было совсем заскучал сервак ощастливил меня сообщением следующего вида:
panic kernel diagnostic assertion "uvmexp.swpgoule <= uvmexp.swpages" failed: file "/usr/src/sys/uvm/uvm_pdaemon.c", line 581
Stopped at Debugger+0x4: leave

RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTRUT WHEN REOPRTING THIS PANIC!

DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!

Может кто-нибудь подскажет, что с этим делать?
Пытаюсь гуглить, но пока неособо результативно...

MAXOB,ну, во-первых, отправить лог разработчикам. Во-вторых, - это что?
Исключить его из загрузки, проверить. Заодно напишите, что у вас за ДНС поднят.

Хороший вопрос, что это за uvm и где его исключать из загрузки... проблема еще в том, что зависания происходят все чаще и чаще и даже гуглить нормально не получается.
ДНС у нас обыкновенный bind.

Что касается отправки лога разработчикам: ошибку я получить повторно не могу, он просто зависает точно таким образом((

Кстати, можно ли писать на bugs@openbsd.org по русски, или обязательно надо переводить на англицкий?

Я не знаток OpenBSD, но uvm в ней отвечает за виртуальную память и судя по ошибке у вас что-то нехорошее со свапом.
Либо он переполнился - тогда смотреть нет ли утечек памяти от левых процессов, либо диск собирается помереть и отсюда ошибки.

Повторю, я не работаю с OpenBSD и это всего лишь догадки.

А по поводу писать в список рассылки про баги, это на 99% не баг и вас там пошлют в пешее сексуальное путешествие, особенно если на русском напишете.

Я уже пытался проверить СМАРТ диска, но он пишет

sudo smartctl -a /dev/wd0a
smartctl version 5.33 [i386-unknown-openbsd3.8] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
Smartctl open device: /dev/wd0a failed: Device busy
Тоже самое и с другими файловыми ситемами /dev/wd0* которые куда-либо монтированы, аналогично и fdisk.
swapctl -l выдал следующее:
Device 512-blocks Used Avail Capacity Priority
swap_device 614880 614872 8 100% 0

Кстати, заглянул я тут внутрь сервака и увидел, что радиатор от чипсета с материнки премило торчит на одной из пружинок, которой должен прижиматься к мамке, убрав пружинки и посадив засранца на термопасту, включил все обратно, пока сбоев не было... в этом может быть проблема?

smartctl обращается не к файловым системам, а к дисковой ноде напрямую. Попробуйте sudo smartctl -a /dev/wd0
swap практически не используется.
Упс, как раз наоборот - он у вас забит под завязку. Покажите в тегах code на всякий случай - я правильно понял что Used у вас 614872 а Avail 8?

sudo smartctl -a /dev/wd0
говорит что нет таккого фала, как-нибудь еще диск называться может?

И да, сам уже ужаснулся, что свап забит по самое не балуйся, это значит что диск умирает?

Это значит, что у вас утечка памяти. Ищите "протекающий" процесс.
Увы, я не в курсе, как в OpenBSD дисковые ноды обзываются.

А не подскажете тогда случайно, как узнать кто именно swap занимает? Или это какая-то особая уличная магия?

man vmstat :) самому лениво читать

нет, это значит, что его "имеют по-чёрному", может быть и утечка памяти. Я про днс почему спросил... Можете его временно отключить?
А смарт можно посмотреть викторией и mhdd, загрузившись с загрузочного CD. Кстати, что за сервачок?

с кернел паник? Запросто. Но с свопу это никаким боком не относится. ИМХО

top -o res
top -o size

Проблема быда действительно в Swap, диск исправно работает, но просто я недоконца вычистил хвосты после удаления антивирусника, но это уже совсем другая история...)))

Всем ответившим огромное спасибо!

так оно ж вроде сортирует по зарезервированной и реально рабочей памяти, про своп не упоминается. :dont-know

Да там пофиг где страницы, в памяти или в свопе - кто больше всех сожрал тот и будет в топе. И он же скорее всего и своп загадил.

а можно точно узнать, кто именно и сколько именно нагадил в своп? vmstat я копал, но ничего не нашел, только общее количество записей в страницы памяти...

Я уже определил, что процесс кушающий весь swap - clamscan, но раньше он запускался от имени старого пользователя _clamav, пользователя я удалил, конфиги вроде везде подправил, однако проблема не исчезла, теперь память кушает тоже процесс, но уже от имени нового пользователя clamav, почему и зачем он это делает?!?!

Возможно, вы страдаете от популярной в последние пару-тройку недель проблемы со сменой формата баз у кламава :)
Суть такова - некоторое время назад кламав сменил формат баз и теперь они не совместимы с версиями старее 0.95. Обновите кламав минимум до 0.95, а лучше до 0.96

Вы правы, именно с этой проблемой я и столкнулся, OpenBSD у меня старенькая (3,8) поэтому обновиться через pkg_add -u не получилось, поэтому старый calmav был удален, а новый собран из исходников. После этого видимо и начались проблемы, правда почему-то не сразу, а спустя какое-то время. Сейчас чтобы избежать переподлнения swap отключен пользователь clamav, от имени которого запускаются clamscan'ы, по этой причине перестала ходить почта, приходится пропихивать её через postsuper -r ALL, а это, согласитель, неудобно.
Поэтому вопрос: как заставить clamav перестать жрать всю память?!

кушать хочецца :)

я не пользуюсь, но НЕУЖТО У НЕГО НЕТ КОНФИГОВ? В конце концов, можно его юзера в конкретный класс пихнуть (во фре есть по умолчанию всего один, но можно склонировать сколько надо), а уж в классе указать и количество разрешенных тредов, и память на тред, и время выполнения, и все такое. (опен я знаю очень-очень плохо, но думаю, что там почти так же, как во фре.) Пример класса

я сам с оперном столкнулся впервые в жизни, но не в этом суть))
В общем действительно проблема была в недонастроенности clamav, что в принципе странно, потому что большая часть настроек стояла по умолчанию, в логах вычитал строчку:
WARNING: MaxThreads * MaxRecursion is too high: 160, open file descriptor limit is: 64
и решал эксперимента ради уменьшить параметры MaxThreads и MaxRecursion, чтобы их произведене было меньше 64. В ощем после изменения и перезапуска swap грузится перестал и почта исправно ходит, тут надо бы постучать по деревянной голове.
А на счет классов идея может и неплохая, но уж больно это напоминает явные сексуальные извращения и папуасские пляски одновременно, а вообще возьму на заметку)))
Всем ответившим спасибо!

ну и отлично.

это почему же? Как раз это классический Unix-way, каждому по потребностям, если что - сразу в одном месте правится ограничение для всех. По умолчанию ограничения практически отсутствуют...

Просто в данном случае на лицо был сбой работы программы, поэтому хотелось устранить причину, покоторой этот сбой происходил. До обновления то никакие ограничения были не нужны, а значит введение ограничений не устраняло бы проблему, а просто её маскировало. Но повторюсь, за ссылку на статью спасибо, я не так давно администрирую unix-системы, поэтому всегда рад новой полезной информации))

Да, наследство, вызванное некоторой необходимостью, нас пару раз из спортивного интереса ломать пытались (компания информационной безопасностью занимается, прикольно же такую ломануть!), вот мой предшественник и обезопалсился по максимуму, хотя руки чешутся все тут переделать, тем более, что необходимость назревает - обновление OpenBSD c 3.8 до текущей 4.6 процесс долгий и очень печальный. )))

Можно подумать, что название ОС серьёзно может повлиять на взломоустйчивость, гг. Ну разве что хакер увидит в фингерпринте OpenBSD и руки опустятся.
Да, опёнок надёжный, но софт-то на нём крутится тот же, что и на других никсоподобных системах, а значит с теми же уязвимостями. Судя по версии и эпопее с кламавом, вам как поставили и настроили систему года 4 назад, так никто и не трогал. Я конешно не знаю, что у вас там на ней крутится, но с тех пор много воды утекло и много уязвимостей найдено ;)

ну это миф. Просто в "опен"-е всё прикручено по максимуму, можно и не менять ничего, а во фре, например, надо ручёнками всё лишнее блокировать/запрещать и т.п. Хотя, в 8 релизе уже гайки поприкрутили :)

угу, ябрышко пересобрать бы...

Что миф? Вы хотите сказать, что например, если на 4-летнем опёнке крутится 4-летний апач, а на нём 4-летний вордпресс, то система неуязвима, потому что это ж OpenBSD? :)

нет, вы неправильно поняли. При хорошей настройке и ДОС будет не хуже OpenBSD (утрирую, конечно, но смысл такой). Я к тому, что не обязательно ставить Open- , можно (и лучше) поставить FreeBSD и вручную закрыть ненужные порты, убрать ненужные сервисы, пропатчиться до последних версий (весь софт, не только ядро) - по надёжности будет ничуть не хуже "опёнка" ;)

Истину глаголете. Только
это ни к чему, если никто не слушает на ненужном порту, то и закрывать незачем. Это как приделать бронированную дверь с замком к глухой стене. ;)

Хотя, в последнее время появилась мода на использование tcpwrapper для оконфузивания сканеров. Суть в том, чтобы пару-тройку реально работающих портов посадить среди кучи обманок, выдающих на скан несусветную пургу.

"закрыть" - в смысле, "TCP/UDP black hole". Т.е. ответа не будет вообще.
Пусть стучат в дверь, они же не знают, есть за ней что-то или нет ;)
да, начинающих "хацкеров" это может остановить. Опять же, этот метод платформонезависим, можно и к линуксу прикрутить.
ЗЫ. что-то мы от темы отбились...