LINUX.ORG.RU
ФорумAdmin

SYN flooding и падение сервака

 ,


1

1

Всех приветствую. Собственно вопрос такой - может ли сервак прилечь наглухо от SYN-флуда? Дело в том, что есть один сервак (точнее виртуалка, VPS), который иногда устает и перестает подавать какие-либо признаки жизни. В логах тишина и покой. Почти. Только есть такая запись в syslog перед падением:

TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters.

В nginx access и error-логах в момент падения выводится абракадабра:

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

Да, на серваке стоит Ubuntu 20.04.4 LTS

Если он бажный то может. По-нормальному - не должен. В первую очередь я бы проверил железо (хотя поскольку у тебя виртуалка и скорее всего у какого-нить нищебродского хостера то вряд ли кто-то будет с этим запариваться). Во-вторую - заменил убунту на нормальную ОС.

абракадабра

Это не абракадабра.

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

Благодарю за ответ. Но 2 вопроса: А какая есть нормальная ось? Centos, Debian? Просто к Убунте уже привыкли, и проблем не было никак. Ну и я не админ, а быдло-кодер.

Это не абракадабра.

Интересно. А что же это такое? Какие-то бинарные данные пролезли в лог?

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

И CentOS (но не stream), и Debian лучше чем убунту, но тут всё же вероятнее проблема не в ОС а в самом сервере.

Это байты с кодом 0, получаются когда система зависла не успев правильно всё записать на диск. Зависнуть система может либо из-за внешних причин (битое железо или фокусы настроек виртуалки), либо из-за багов в ядре.

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

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Это байты с кодом 0, получаются когда система зависла не успев правильно всё записать на диск.

Вы такое реально наблюдали на appends с data-ordered journaled fs? Я не до конца понимаю что именно должно произойти чтобы привести к такому результату.

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

Наблюдал на ufs2 в append-only файлах. Журнал там есть. Насчёт data-ordered не интересовался. Какие настройки файловой системы у автора - не знаю, но в любом случае других причин для нулей в конце файла я не вижу. Может быть там гипервизор крашится, а очередь записей на диск не соблюдается. Или десинхронизация между числовым размером файла и количеством выделенных ему блоков к такому как-то приводит.

Если автор укажет точные байтовые позиции начала и конца этих нулевых байт, наверно будет понятнее. Я почти уверен, что либо начало, либо конец выровнены на 4к-границу. Впрочем, проблему автора всё это решить никак не поможет.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от firkax

Было бы интересно от’strace’ить как именно nginx логи пишет. Сильно подозреваю что там не просто appends. Я к тому что partial records при крешах вполне себе ожидаемы, а вот лишние нули в конце - это очень нехорошая проблема, потенциально ломающая много чего.

bugfixer ★★★★★
()