Записки IT специалиста

Wildberries: Сердечные скидки на подарки любимым Для влюблённых любой день – праздник. А со скидками до 60% праздник станет еще лучше❤️ Выбирайте романтический декор и подарки для любимых на Wildberries! Перейти на сайт #реклама wildberries.ru О рекламодателе

Наш резервный канал в MAX, на всякий случай, основное движение пока здесь. https://max.ru/join/9O4RfUouLW10N1bPe9sM1iJ-CyRVJvi8WdjY2tZL_Cs

Что такое Magic SysRq и чем он может быть полезен Каждый из нас не раз сталкивался с ситуацией, когда Linux-система впадала в состояние близкое к коме и переставала реагировать на все ваши команды, включая reboot. Неприятно, да. Что делать? Обувать ботинки и спешить в место физического расположения сервера? Не спешите, попробуйте Magic SysRq – это специальные низкоуровневые команды, которые позволяют взаимодействовать даже с наглухо повисшей системой, работало бы ядро. Чтобы перейти в этот режим отправьте:

echo 1 > /proc/sys/kernel/sysrq

А затем обычно следует команда жесткой перезагрузки системы:

echo b > /proc/sysrq-trigger

Это эффективно и позволяет перезагрузить даже безнадежный сервер, но и достаточно жестко, так как эквивалентно нажатию кнопки Reset на корпусе. Но ведь мы же висим? Висим, но ядро то работает. Поэтому давайте не будем рубить с плеча, а попробуем обойтись с системой более гуманно. Прежде всего, если у вас система с графической оболочкой, то следует отключить от нее консоль ввода-вывода чтобы быть уверенным, что никто его не перехватит:

echo r > /proc/sysrq-trigger

Затем пробуем отправить SIGTERM всем процессам (попросим завершиться их по-хорошему). Некоторое время ждем, так как не все могут это сделать мгновенно.

echo e > /proc/sysrq-trigger

А дальше: кто не спрятался – я не виноват, приступаем к принудительному завершению всех активных процессов (посылаем SIGKILL):

echo i > /proc/sysrq-trigger

Чтобы не потерять данные в буферах и кешах принудительно пишем их на диск (посылаем fsync):

echo s > /proc/sysrq-trigger

После чего отмонтируем все файловые системы:

echo u > /proc/sysrq-trigger

А теперь можно и Reset нажать:

echo b > /proc/sysrq-trigger

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

Мужской клуб Wildberries На WB появился новый раздел — «Мужчины выбирают» Там есть всё: от носков до молотков. И есть даже специальные подборки по интересам для геймеров, спортсменов, автолюбителей и вообще всех-всех! Кстати, теперь искать подарки для своих любимых мужчин можно прямо в подборках! Ставим лайк этому лайфхаку ❤️ Перейти на сайт #реклама wildberries.ru О рекламодателе

Режимы выделения виртуальной памяти в Linux Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, нежели ее есть на самом деле. Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле. Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск). И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса. Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения е ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память. Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс. Режим работы этого механизма можно задать при помощи опции

vm.overcommit_memory

Которая может принимать одно из трех значений: 0, 1 и 2 🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память. В таком режиме ядро обычно допускает умеренное избыточное выделение памяти, примерно до 50% от общего размера физической памяти (ОЗУ + подкачка). Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer. Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой. 🔹 vm.overcommit_memory = 1 – выделение память происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих потомков и общую память (веб-сервера). Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer. 🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:

vm.overcommit_ratio = 100

Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:

CommitLimit = swap_total + (RAM_total × vm.overcommit_ratio / 100)

По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии оперативной памяти. Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно. Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска. В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.

Как работать удаленно с нейросетями? Присоединяйся! Подпишись прямо сейчас, чтобы не потерять: Свежие обзоры нейросетей, которые реально работают — без лишнего хайпа и воды, только проверенная информация, которую можно использовать для заработка. Пошаговые видео-уроки, после которых всё станет понятно — научитесь быстро осваивать новые профессии и автоматизировать рутинные задачи. Как находить клиентов, готовых платить дорого — секреты эффективного поиска заказов и построения стабильного потока заказов. Автоматизация работы — научитесь выполнять 2-часовую работу за 20 минут без выгорания, автоматизируя рутину с помощью нейросетей. Подписаться #реклама 16+ О рекламодателе

🎯Бесплатный вебинар: Инструменты DevOps — что реально используют на проектах в 2026 УЖЕ ЗАВТРА! Если ты: - сисадмин, знакомый с серверами, но Docker и Terraform пока всё ещё «тёмный лес» - разработчик, которому интересно, как всё крутится в проде - уже начал изучать DevOps, но запутался в хаосе инструментов — приходи. Что будет: — как выбрать инструменты, которые реально нужны на проектах — Docker, Kubernetes, Terraform, Ansible без перегруза теорией — CI/CD пайплайны на примерах GitLab CI и GitHub Actions — минимальный мониторинг, который работает без боли 📅 12 февраля, 19:00 (МСК) 💸 Регистрация бесплатная, плюс скидка 10% на обучение (любой тариф) GigaDevOps 👉 РЕГИСТРАЦИЯ ЗДЕСЬ.

Управление сетевыми настройками в Linux Последние годы Linux проделал большой путь унификации, во многом благодаря systemd. Теперь вам не нужно вспоминать приемы работы со службами и автозагрузкой в том или ином дистрибутиве. Все везде делается одинаково. Чего не скажешь о сетевых настройках. Причем, если в графической среде стандартом де-факто давно используется NetworkManager, то в серверном варианте наблюдается полный разброд и шатание. Debian использует службу networking, которая управляет сетевой конфигурацией через ifupdown, надо сказать – порядком устаревший. RHEL и производные полагаются на службу network, использующую скрипты ifup и ifdown. В принципе то же самое, что и в Debian, только все по-другому. Arch и основанное на нем семейство использует netctl собственной разработки, а если вы решите освоить ALT, то познакомитесь с еще одной системой – Etcnet. Ну и Ubuntu тоже не остался в стороне со своим netplan. От такого разнообразия разбегаются глаза и становится довольно тоскливо. Если вы редко работаете с тем или иным дистрибутивом, то для управления сетью вам придется заглядывать в справку. Тем не менее есть инструмент, который позволяет унифицировать работу с сетью, но по какой-то причине до сих пор не пользуется широкой популярностью. Это systemd-networkd, как и весь systemd он очень прост и также строится на основе юнитов соответствующего типа. В простейшем случае нам достаточно создать юнит с типом network и внести в него следующее содержимое:

[Match]
Name=ens33

[Network]
Address=10.8.8.100/24
Gateway=10.8.8.1
DNS=10.8.8.1

Однако, несмотря на простоту, systemd-networkd достаточно мощный сетевой менеджер и позволяет управлять как проводными, так и беспроводными соединениями, мостами, маршрутизацией и многим другим. При этом его основной плюс – унификация, он будет работать везде, где есть systemd. И в целом никто не мешает перейти на systemd-networkd уже сейчас, не дожидаясь пока его завезут из коробки в ваш любимый дистрибутив. Почему? Потому что это наиболее универсально и перспективно. Вам не нужно учить разные сетевые менеджеры, достаточно просто знать systemd-networkd. Также отдельно хотелось бы отметить netplan от Ubuntu. Это не самостоятельный сетевой менеджер, а фронтенд, поддерживающий systemd-networkd и NetworkManager. Netplan позволяет абстрагироваться от конкретного сетевого менеджера и описывать сети декларативно в формате YAML, после чего уже сам netplan сформирует конфигурацию для используемого сетевого менеджера. Это удобно, прежде всего переносимостью, а также возможностью расширения практически для любого дистрибутива и любого сетевого менеджера. Кроме того, у netplan есть интересные возможности, например, проверить сетевые настройки перед их применением. Если что-то пошло не так, то вы не потеряете сетевой доступ к узлу, так как все изменения будут автоматически откачены обратно. Поэтому, глядя на существующий зоопарк технологий мы бы обратили внимание прежде всего на systemd-networkd – он есть везде, где есть systemd, прост, понятен и отлично работает. В перспективе, конечно, хотелось бы видеть единый унифицированный фронтенд по образу netplan, который бы позволял описывать сети в едином формате и применять их без оглядки на используемый менеджер. Как и snap, netplan давно уже вышел за рамки мира Ubuntu и доступен практически в любом дистрибутиве, однако широкого распространения не имеет.

«Вечная отчётность» по интернет-рекламе ушла в прошлое! ⚡Теперь для большинства размещений достаточно отчитываться в ЕРИР только в течение года с даты публикации. После 12 месяцев данные можно не подавать — исключение составляют видеоинтеграции, которые продолжают распространяться на платформах. Мы в Digital Agency Insight уже разобрали: ✅ как считать срок отчётности; ✅ что делать с прошлыми размещениями; ✅ как не получить штраф. 📱Подписывайтесь на наш Telegram — рассказываем просто о сложных изменениях в рекламе, делимся практическими инструкциями и интересными кейсами о маркетинге в России и за рубежом. Узнать больше #реклама 16+ О рекламодателе

Монтирование файловых систем при помощи systemd Казалось бы, монтирование файловых систем в Linux задача простая и не требующая каких-либо доработок. Но очень часто именно в простоте таятся различные сложности и затруднения. Текущая система монтирования уходит корнями еще во времена UNIX и дошла до наших дней без серьезных изменений. Но мир с тех пор серьезно изменился, сегодня в широком ходу сетевые расположения и съемные устройства, работать с которыми классическим образом не слишком удобно. И вот тут нам на помощь снова приходит systemd, предлагая современные методы монтирования файловых систем. ✅ Читать далее

Монтирование файловых систем при помощи systemd Казалось бы, монтирование файловых систем в Linux задача простая и не требующая каких-либо доработок. Но очень часто именно в простоте таятся различные сложности и затруднения. Текущая система монтирования уходит корнями еще во времена UNIX и дошла до наших дней без серьезных изменений. Но мир с тех пор серьезно изменился, сегодня в широком ходу сетевые расположения и съемные устройства, работать с которыми классическим образом не слишком удобно. И вот тут нам на помощь снова приходит systemd, предлагая современные методы монтирования файловых систем. ✅ Читать далее

Монтирование файловых систем при помощи systemd Казалось бы, монтирование файловых систем в Linux задача простая и не требующая каких-либо доработок. Но очень часто именно в простоте таятся различные сложности и затруднения. Текущая система монтирования уходит корнями еще во времена UNIX и дошла до наших дней без серьезных изменений. Но мир с тех пор серьезно изменился, сегодня в широком ходу сетевые расположения и съемные устройства, работать с которыми классическим образом не слишком удобно. И вот тут нам на помощь снова приходит systemd, предлагая современные методы монтирования файловых систем.

🚀 Устали от рутины в Python? Автоматизируйте задачи с GPT за 90 минут Собираем и забираем себе в пользование рабочее решение по практической автоматизации на стыке Python + ИИ. 🕑 Завтра | 12:00 или 19:00 (МСК) на бесплатном вебинаре покажем, как с помощью GPT превращать Python-скрипты в умные сервисы. За 90 минут вы: 🔹 разберёте базовую архитектуру «умных» сервисов и поймёте, как они устроены 🔹 увидите, как подключаться по API к GPT-моделям и интегрировать их в Python-проекты 🔹 получите готовый каркас автоматизационной системы, который можно забрать себе и дальше развивать: усложнять сценарии, расширять функциональность и автоматизировать рабочие задачи Кому будет полезно: — Python-разработчикам — Data / ML-инженерам — ИТ-руководителям и тимлидам — всем, кто хочет применять GPT в реальных проектах ✅ Получите бесплатный доступ к фрагменту курса и живые примеры. 🔗 Регистрируйтесь на вебинар #реклама О рекламодателе

Настраиваем таймеры systemd вместо заданий cron Технологии постоянно развиваются, внося в нашу жизнь новые инструменты, которые вытесняют и заменяют старые и привычные нам. Но зачастую администраторы не спешат не только применять их на практике, но даже изучать. Нет, здоровый консерватизм безусловно оправдан, но исключительно в разумных пределах. Гораздо хуже, когда внедрение новых технологий тормозится по надуманным или "идеологическим" причинам несмотря на то, что они предоставляют гораздо более широкие возможности. Одна из таких технологий - таймеры systemd, которые позволяют по-новому взглянуть на некоторые классические задачи. К systemd можно относиться по-разному, но нельзя отрицать, что данная подсистема вывела на новый уровень управление службами в системе Linux и сделала эту задачу гораздо более простой и удобной. Все ведущие, имеющие промышленное применение дистрибутивы, используют systemd, который стал де-факто стандартом. А поэтому глупо отрицать все преимущества, которые он нам предоставляет и продолжать цепляться за старые технологии. Сегодня мы поговорим от таймерах, как современной и эффективной замене cron. Cron - один из старожителей, пришедший к нам из мира UNIX и полностью следующий его философии, но современные системы гораздо более сложны, чем классический UNIX и некоторые подходы приходится пересматривать. Да, сron многим привычен, но если рассматривать его сильные и слабые стороны, то в плюсы ему можно записать только простоту, все остальное - обратная сторона медали от этой простоты. Что умеет cron? Запускать задачи по расписанию и уведомлять администратора, если такой запуск завершился неудачей. Неудачей в данном случае считается возврат запускаемым приложением или скриптом кода ошибки, все остальное cron не касается, его дело запустить. Уведомление по электронной почте в современных реалиях фактически равноценно его отсутствию, мало кто будет настраивать почтовый сервер ради нескольких уведомлений. В остальном cron является достаточно сложным и недружественным сервисом. Одним из популярных запросов в поисковых системах является "скрипт не работает в cron", это действительно так, ваш скрипт может прекрасно работать интерактивно, но не работать через планировщик, либо работать, но приводить к неожиданным результатам. И установить причину такого поведения иногда бывает достаточно сложно. Из этого вытекает одна из основных проблем - сложность отладки. Если вы не позаботились о логировании всех действий вашего скрипта, то найти источник проблем может оказаться крайне затруднительно. Вторая проблема - тонкая настройка расписания. Хорошо, когда условие простое и задание можно проверить, просто уменьшив интервал, а если довольно сложное? Тогда вы все узнаете только по наступлению события. Теперь посмотрим, что нам предлагает systеmd. Таймеры - это специальные триггеры, позволяющие запускать любые сервисы периодически, либо по наступлению какого-либо события. Здесь кроется существенное отличие от cron, запись которого содержит и расписание, и действие, в systemd эта логика разделена: таймер отвечает за управление сервисом, который уже выполняет действие. Для таймеров используются юниты с расширением .timer, в то время как для служб с расширением .service. Чтобы управлять каким-либо сервисом вам понадобится создать для него одноименный таймер. ✅ Читать далее

Поступление по портфолио в IT-магистратуру ИТМО Вы знаете, что Конкурс портфолио позволяет без вступительных экзаменов поступить на программы магистратуры ИТМО в партнёрстве с Практикумом? Мы — знаем! Поэтому приглашаем вас на вебинар, чтобы рассказать все подробности: — Из чего состоит портфолио и сколько баллов можно получить за каждый из разделов. — Как всё проходит, что нового в условиях в 2026 году, когда подавать документы и ждать результаты. — На что обратить внимание при подготовке портфолио. На какие программы ИТМО в партнёрстве с Яндекс Практикумом можно поступить по портфолио: 1. DevOps-инженер облачных сервисов 2. Фронтенд- и бэкенд-разработка 3. Управление продуктом в цифровом бизнесе Встречаемся 18 февраля в 19:00 мск. Зарегистрироваться #реклама 16+ practicum.yandex.ru О рекламодателе

Как в Linux узнать скорость USB-портов и их текущий режим работы Вопрос достаточно интересный и непраздный, очень часто нужно определить наиболее быстрый USB-порт устройства, чтобы, например, перекинуть большой объем данных. Воткнуть в синий порт давно уже не вариант, так как разновидностей стандарта USB 3.x сегодня несколько и скорость работы там может существенно отличаться. Первый приходящий на ум вариант – заглянуть в документацию, но это не всегда возможно, тем более документация не покажет нам реальный режим работы устройства. Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:

lsusb -t

Которая покажет номинальные скорости концентраторов и режимы работы подключенных к ним устройств. Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно: ▫️12М - USB 1.0 ▫️480M – USB 2.0 ▫️5000M - USB 3.2 Gen 1 (USB 3.0) ▫️10000M - USB 3.2 Gen 2 (USB 3.1) ▫️20000M/x2 - USB 3.2 Gen 2x2 Реальный вывод команды показан на скриншоте из которого четко видны режимы работы концентраторов и портов.

Долги довели до трясучки? Выход есть! ✅ Твои соседи уже списали долги. Легально. По 127-ФЗ. А ты всё платишь и платишь, сводя концы с концами? 💰 Хватит это терпеть! ⚡ Узнай за 2 минуты 📅, подходишь ли ты под списание. Бесплатно. ЖМИ 📞 Получить консультацию Получить консультацию Банкротство влечет негативные последствия, в том числе ограничения на получение кредита и повторное банкротство в течение пяти лет. Предварительно обратитесь к своему кредитору и в МФЦ. #реклама sfera.help О рекламодателе

Виртуализация, контейнеризация, докеризация Технологии виртуализации и контейнеризации плотно вошли в нашу жизнь, и любой системный администратор сталкивается с ними ежедневно. Но до сих пор бытуют мифы и заблуждения относительно технологий и поэтому давайте разберем их отдельно. Начнем с виртуализации. Это наиболее старая и зрелая технология, достигшая к современному состоянию дел определенной стабильности и совершенства. Виртуальная машина предполагает полную развязку гостевой системы от хостовой и предполагает полную эмуляцию виртуального железа, предлагая виртуальной машине полностью отвязанные от физического хоста конфигурации. Но это влечет за собой максимально высокие накладные расходы, которые зависят от набора эмулируемого железа, в большинстве случаев они не превышают 10-15%, но могут оказаться и более высокими, особенно если нам нужно обеспечить высокую доступность. Высокая доступность для виртуальных машин давно отработанная технология и виртуальная машина может передаваться между узлами без остановки работы и не прекращая обслуживание пользователей. Однако, если в кластере используются процессоры разных поколений, с разными наборами инструкций, то виртуальная машина будет ограничена возможностями наиболее слабого узла, что может привести к более серьезной потере производительности на более быстрых нодах. Контейнеризация LXC на первый взгляд похожа на виртуализацию, вам также предоставляется как бы отдельный экземпляр операционной системы. Но мы не зря сказали «как-бы». Контейнер LXC не имеет собственного ядра и собственного железа, а также собственных ресурсов, он выполняется прямо на хосте и использует ресурсы и ядро хоста в рамках выделенных ему лимитов. Но снаружи это выглядит как отдельный экземпляр операционной системы, причем мы можем таким образом запускать самые различные ОС на ядре Linux. На самом деле контейнер предоставляет нам системное окружение выбранной ОС, работающей на ядре хоста и с ресурсами хоста. Это эффективно решает задачу, что у нас есть софт, собранный под определенную ОС и нам надо его запустить. Нет проблем, запускаем контейнер с нужным системным окружением и работаем в нем с нашим экземпляром ПО. ПО думает, что работает в среде нужной ему ОС, для администратора это выглядит также в итоге получаем привычную среду, которая похожа на виртуалку, но виртуалкой не является. Что касается живой миграции таких контейнеров, то с этим есть определенные проблемы. Сам контейнер привязан к ядру хоста и просто так не может быть передан на другой узел. В рамках Proxmox миграция LXC-контейнеров возможна только с остановкой и перезапуском. Хотя есть альтернативные решения, которые позволяют передавать контейнер без остановки, но это уже специфика и следует исходить из того, что контейнер без перезапуска не мигрирует. Теперь перейдем к докеризации. Докер представляет собой контейнер на уровне приложения. Накладные расходы минимальны – докер приложение исполняется на хосте в рамках установленных лимитов. Также у докер совсем другая философия, контейнер атомарен и неизменяем, по сути, это некоторый черный ящик, к которому мы подключаем свои ресурсы и настройки. В случае какой-то проблемы мы просто уничтожаем текущий контейнер и запускаем новый. Надо переключиться на другой хост, тушим контейнеры здесь, запускаем там. Балансировщик быстро перекидывает соединения. При том, что Докер-контейнеры запускаются и перезапускаются крайне быстро, то подобный подход является неплохой альтернативой живой миграции. Точнее сводят необходимость живой миграции к минимуму. Что в итоге выбрать – смотрите сами. Все указанные технологии достаточно зрелые, каждая их них имеет свои особенности и недостатки. А грамотный администратор всегда умеет играть от сильных сторон решений.

Сформируйте привычку говорить красиво за 21 день! Курс-практикум по совершенствованию речи. Перейти на сайт #реклама 16+ onlinetron.ru О рекламодателе

И что это было? Третьего дня произошла одна не очень приятная история. Один наш заказчик собирался открыть еще одно направление бизнеса. Под это дело еще в далеком 2023 году закупил технику. В общем и целом – ничего сверхъестественного, под сервер 1С был куплен Ryzen с максимальной частотой и памятью на настольной платформе и ряд железок попроще, под вспомогательные вещи и бекапы. Мы ее в свое время даже настроили, но поработать она тогда не успела, планы поменялись и почти три года она простояла то в подсобках, то в гараже, то еще где. Теперь этот вопрос вновь был поднят и ее привезли нам снова, чтобы привести в актуальное состояние. А с учетом прошедшего времени проще все снести и поставить заново, чем мы и занялись. Ничто не предвещало беды, но при очередной перезагрузке ПК просто повис, не реагируя ни на что. Выключили их розетки, после чего он больше не включился. В таких случаях надо проверять все, начиная с блока питания. Блок питания исправный, стартует, напряжения выдает. Отключаем и снимаем с материнской платы все, кроме процессора и памяти. Тишина. Снимаем память, ноль реакции. Становится понятно, что основной подозреваемый – материнская плата, потому как платы AM4 включаются даже без процессора и показывают ошибку CPU диагностическим светодиодом, а многие дают даже прошить в таком режиме BIOS. В общем все выкручиваем, разбираем, на всякий случай проверяем процессор и память на другой системе AM4 – все работает. Решаем на всякий случай проверить эту плату с другим процессором – неожиданно она включается и начинает работать. Собираем на стенде все обратно как было – включается, работает. Гоняем всякие тесты более суток, выключаем, перезагружаем. Все работает. Собираем обратно в корпус, гоняем – все работает. Во вторник система поедет к заказчику в работу и вроде бы все хорошо, но осадочек остался. Потому что доверять такой системе нельзя, период приработки она до сих пор не прошла. А гарантия на большинство компонентов заканчивается 26 апреля. Поэтому уведомили заказчика, чтобы он был готов быстро бежать покупать аналогичную систему, если вдруг чего. А что это было – решительно непонятно. Может что-то где-то отошло или наоборот замкнуло, отсырело, попало и т.д. и т.п. А может это мог быть глюк платы и со временем он повторится в самый неподходящий момент. А мораль сей басни проста, не допускайте длительного хранения систем, даже если они куплены в резервных целях. Потому что без периода приработки невозможно выявить заводской брак или несовместимость компонентов. Поэтому такие системы становятся черным ящиком без гарантий чего-либо вообще. И в самый неподходящий момент может выясниться что резерв это совсем не резерв, а еще одна требующая ремонта система.