user 100% это значит что на дисковых операциях комп проводит 0 процентов времени и можно на диски не смотреть пока. К тому же гиг свободной памяти означает что можно закешировать еще дохрена страниц и забыть про диск.

Да атом это х86 (32 бита). А х86_64 это очевидно 64 бита.
В данном случае играет роль отсутствие разделения на LOW|HIGHMEM в x84_64

Здесь много интересных моментов, но до конца я так и не разобрал проблему.
То что nfs может подвесить процессы в TASK_UNINTERRUPTABLE это нормально, но почему оно вешает всю систему, а не один процесс я долго немогу понять.


Для начала включи slabtop, там будет запись вроде nfs-cache (или nfs-buffer) типа того.
Вот когда ты большое файло скидываешь на nfs оно реально в сеть не пролазит и складывается в опреативке в этот самый буфер, а буфер то в slab - а slab это ядро и соответственно low-mem, который нельзя сваппить и который ограничен 1 Гигабайтом.


Соответственно место под структуры ядра нет и операции на память становятся очень дорогими ... в этот момент все висит, но slabtop будет иногда обновлятся, и ты будешь видеть как очищается буфер скидывая на nfs закэшированные данные, так вот как только буфер освободиться - система оживет.

А вот как это лечить и как именно kernel-nfs приводит к такой ситуации я пока непридумал - 100% ситуацию спасает переход на x86_64 но в случае атома это неработает.

Говорю же - смотреть мак. Хаб неможет отличить арп от ицмп, соответственно если мы видим мак - значит арп пролетел и проблема не в хабе. Если мак невидно то видимо арп не пролетел и тогда можно думать на хаб.

Если бы у вас была петля 2-го уровня ( A->B->C->A ), то ничего бы не пинговалось ;)

А вообще советы дельные. Остановить панику и проверять все.
С проблемных компов проверить мак шлюза, сверить его с маком который видят нормальные компы. Если проблемные компы мак невидят впринципе - думать топологию, если видят, но не мингуют - думать софт (файерволы антивирусы и пр.)

Опытным путем было выяснено что виновата XFS - это из-за нее buffer=0, правда к замедлению транзакций она не имеет отношения.
Почему xfs так себя ведет еще предстоит выяснить, а пока всем спасибо кто наталкивал на умные мысли.

Проблема повторяется на нескольких машинках - на некоторых есть нехватка памяти и я сначала на это сваливал. На данном экземпляре хардварный рейд от hp. Что внутри у рейда узнать нельзя.

В общем я неисключаю что проблема хардварная, но в чем она - какое железо может запретить ядру буфферить вообще? - такое разве бывает? - я ненашел пока подтверждений.

В параметрах ядра только root,vga и silent - никакой экзотики.

Кстати файловая система xfs - может она.

Вот у меня похожее впечатление, но найти таких опций в ядре у меня не получилось. Постить тут конфиг думаю смысла нет, он длинный - но проверить наличие каких опций можно если есть предположение.

Под спойлером большой график. Наверху график io диска в 13 14 и в 15 видны проблемные периоды. На втором частота обращения к диску, на 3 занятая память.

Думаю заменит meminfo

iostat есть, просто проблемы нет пока, она не по заказу появляется.

Это точно не свап, если даже free меньше 150 не падало за весь обозримый в заббиксе период. Да и пустой свап стоит.

Когда последний раз ловил подвисший оракл DBA сказал что оракл просто ждет окончания записи транзакции в лог - вот просто одну строчку около минуты писал. А система отзывается la в норме.

Неа, не то.
Памяти много, с этим все хорошо. И эти настройки регулируют скорость освобождения cache (как я понимаю буфер чтения), а здесь buffer это буфер записи - чем его регулировать я как раз и пытаюсь найти.

iostat соберу позже но это точно не свапинг. Памяти дофига и свап ноль.

На iostat правда надеяться то же мало смысла - есть графики где хорошо видно что периоды "тормознутого" поведения никак не бьют с периодами нагрузки на диск, и даже вручную созданная нагрузка как правило отрабатывается адекватно.

косяк
MASQUERADE

А iproute вообще должен делать nat?

В общем автор либо незнает про iptables либо нехочет им пользоваться ... на всякий случай маскарадинг в iptables делается так
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERAD
Перед этим включить фовардинг как zend прописал.

Если получиться сделать это через iproute - поделись магией.

id3 -A"" /home/my/Music/*

Кажется так можно сбросить названия альбомов или заменить на что то однообразное(указать в кавычках после -А).
А вообще id3 может все, если заглянуть в доки ... есть ключики для всех полей файла.

rsync рулит, это суперкомбаин, он может все.

Но если нужно только копирование с приостановкой и продолжением то
cp /a/* /b/*
kill -STOP `pgrep cp`
kill -CONT `pgrep cp`

О! кажется я понял - человек пытается вбить пароль/логин от интернета в вебморду роутера - это неправильный путь.

Пароль/логин от роутера это не то что дает провадер - это либо пароль от доступа к настройкам роутера.

А пароль/логин который дал провайдер - это сами настройки роутера.

Соответственно надо найти пароль от роутера (поискать в инструкции стандартный пароль), потом получить доступ к панели настроек и вбить в эту панель настройки которые дал провайдер - где то так.

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

Первое - копай NAT - какой он там у тебя ... правильно ли NATит ... второе копай файер, если натишь ipfw, то тяжко тебе будет ))

Как вариант
eth0 - пров
eth1 - локал


tcpdump -npi eth0 - в одной консоли
tcpdump -npi eth1 - в другой консоли

потом из локалки пингуешь яндекс

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

Ребут конечно нельзя.

Утилита просто читает procfs ... незнаю еще откуда она вытаскивает это значение, но она не одна его так показывает - procinfo и остальные с ней солидарны.

Насчет размера это вряд ли ... около сотни серверов и на большей части счетчик давно перевалил за 2^8 ... да и при нормальном значении 2-4К/секунду он переполнялся бы слишком быстро.

А вот насчет обнуления это да - везде простот обнуляется сам - потому меня это и заинтересовало.

Народ.
Вопрос был не как защититься а как посмотреть что они будут делать.
Вопрос про хонипот интересный.

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

Если после winbind stop процессы не исчезают, то может быть это зомби - если так то надо писать багу убунтуйцам. Иначе проверь родителя этих процессов

Lenovo s10-3t ... Основное оборудование подхватывается в убунте почти без плясок ... только для тачскрина надо ядро >= 2.6.35 и WIFI - если версия с ваймаксом.

Если версия с броадкомовским вайфаем то плясать придеться первое время. И микрофон неработает.

я как раз вокруг этой идеи и ходил кругами ... вот тут наткнулся на эту мысль, но в том варианте он режет сильно много лишнего.

Твой кстати тоже режет немного промежуточных значений ... например TOKEN-15 и TOKEN-154, но для меня оно непринципиально, да я и не вижу как это поправить.

^TOKEN-.{5,}$

вот эта конструкция отматчит все что было исключено предыдущими условиями

Ух ты - сработало.
Очень тебе спасибо motonarola.

rushba это было бы слишком просто что бы быть правдой ...
Но мне надо скормить этот шаблон программе в которой есть поддержка ERE. Эта программа будет парсить логи на большом количестве серверов используя полученный шаблон.

Похоже корень система все же видит.
run-init это скрипт в initramfs который запускает /sbin/init из корневого раздела после того как раздел смонтирован. Вот судя по всему инит запускается и падает ... простой вариант откатиться на другое ядро ... интересный вариант загружиться в initramfs основной системы, смонтировать корень куданить в /mnt и потом
# chroot /mnt /sbin/init
ну там видно будет что дальше делать ...

Такое возможно если вайн не объявил себя программой по умолчанию для открывания .exe

Попробуйте ПКМ на иконке пакета с оффисом и выбрать "Открыть в wine"

P.S. Правда сама идея ставить M$office под вайном поражает воображение.