ага, спс. Про netconsole посмотрим. Edac у нас мониторится (но поэтому серверу, да, походу упустили эту проверку)

ls -1 /sys/devices/system/edac/mc/mc0/csrow1/
ce_count
ch0_ce_count
ch0_dimm_label
ch1_ce_count
ch1_dimm_label
ch2_ce_count
ch2_dimm_label
ch3_ce_count
ch3_dimm_label
dev_type
edac_mode
mem_type
power
size_mb
subsystem
ue_count
uevent

вы прямо смотрите счетчики ue_count и ce_count? Я просто когда-то при добавлении проверки делал так: grep "[0-9]" /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count, т.е. смотрел чуть другое. Или это в принципе одно и тоже?

Привет всем! Здесь ведь можно будет задать вопрос не совсем про девопс? (замечал, что здесь могут обсуждать просто вопросы ОС и железа)
Если ближе к делу: есть железный сервер с ОС debian jessie 8.2

uname -a
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u1 (2015-12-14) x86_64 GNU/Linux

На сервере запущено довольно много сервисов (Elasticsearch, впн, докер (storage driver - aufs) контейнеры с сервисами). Сервер жил не тужил до недавнего времени. Периодически (за 2 недели это второе падение) он стопается наглухо. Есть скриншот call trace при первом падении .
Начал разбираться, при втором падении были следующая ситуация:
- в 22:20 сервер упал (отрапортовала система мониторинга + плюс отсутствие метрик с этого периода)
- по логам сервера (syslog, kern.log) сервер еще жил до 22:32 (писались логи докера, типа kernel: docker0: port 15(veth63b10e9) entered disabled state)
- в atop последние данные только за 22:20
- по метрикам никаких аномалий нету (метрики хоста, контейнеров, эластика). Сервер выполняет чисто служебные роли (на sata-диски конечно идет высокая нагрузка на запись из-за эластика, но так уже живем несколько лет (это только при мне, а так мб и дольше))

У нас как-то относительно была похожая ситуация с другим сервером (но там вроде в консоли были другие ошибки). Обновились до stretch и уже больше месяца, тьфу-тьфу, проблем нет. Чем руководствовались, что обновление может помочь? На сервере стоял докер c aufs, хотели посмотреть что будет когда станет overlay2))
Память на том другом сервере тестили только из под ОС (но старались в момент тестов все сервисы тушить, чтобы проверить максимальное кол-во памяти) - всё было OK.

Также все сервера в md-рэйде (1), смарты дисков конечно проверяли.

Следовательно есть несколько вопросов:
- как бы далее пытались понять, что с сервером мб не так? (снять дамп ядра - у меня не хватит навыков его прочитать и понять).
Обновить-то обновим, проблема может быть уйдет, но причина так и останется неясной. Сервер длительное время работал без проблем.
- ниже есть скриншот консоли в момент ошибки. Для меня малоинформативно. Есть подозрение, что когда смотрим в консоль через ipmi, мы просто не видим части информации (экран и так маленький, и всю важная инфа вполне могла быть просто промотана). Возможно ли вывод экрана физической консоли перенаправлять куда-либо? Погуглил обзорно, но что-то ничего не нашел. Если бы было это возможно, вполне вероятно, ошибка была до этого call trace с более ясным описанием.

Контейнер успешно создался но не запустился. Чекнул внутри контейнера логи. Ошибка msg="Error opening query log file" file=/data/prometheus/queries active err="open /data/prometheus/queries.active: permission denied"
panic: Unable to create mmap-ed active query log

Шутки шутками, а у меня фронтенд на реакте один случай из десяти не билдится, потому что 4 Гб ОЗУ мало

Ахахах...это ты ещё Ангуляр не билдил...ему и 6Гб иногда бывает мало🤣

у тебя озу часом не 512 мб на сервере?