CentOS, или как перезагрузить сервер ?

произошел непонятный трабыл.

непонятно почему и что заставило ядро упереться в 100.

необходимо перезагрузить сервер

[root@serv ~]# clear
-bash: /usr/bin/clear: Ошибка ввода/вывода
[root@serv ~]# reboot
-bash: /sbin/reboot: Ошибка ввода/вывода
[root@serv ~]# top
-bash: /usr/bin/top: Ошибка ввода/вывода
[root@serv ~]# yum
-bash: /usr/bin/yum: Ошибка ввода/вывода
[root@serv ~]# 

Но вот что я получаю на выходе.

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

Так же опробовал

[root@serv ~]# init 0
[root@serv ~]# init 3

как видите команды вроде прошли, а вот реации от железа 0.

Есть варианты как его ребутнуть ?

PS. Кстати потихоньку оперу выедает. Что то сервер там делает но что ?

Пара пара парадуемся на своем веку.

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

ребята делам бекапы, делаем бекапы и бекапы сделают вашу жизнь милее.

Rassol2 написал:

ребята делам бекапы, делаем бекапы и бекапы сделают вашу жизнь милее.

У меня данные живут на 2х серверах (репликация по DRBD и GlusterFS), на самих серверах - диски в RAID-1 организованы. Ну и бэкапы еженощно на третий сервер сливаются. Там тоже RAID-1 под дисками. Ну а дальше - оргвопрос: как долго конкретные бэкапы хранить, какой им статус присваивать, архивной копии или резервной.

Может это и паранойя, но зато сплю спокойно. При том, что на этих серверах, за 3 года их эксплуатации все диски повылетали напрочь и были заменены по гарантии. А некоторые менялись и по 2 раза. При этом процедуры замены дисков никак не сказывались на непрерывности бизнеса фирмы.

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

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

Rassol2 написал:

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

Про полеты винта. Есть простенький монитор smartctl (мне по крону каждое утро такие репорты присыляются). Им можно прекрасно контролировать состояние каждого диска. И по тренду параметра Relocation Count вполне можно делать вполне определенные предположения о его исправном состоянии. И когда значение этого параметра превышает критическое - нет проблем его изъять из системы. Я же говорил уже за три года эксплуатации своих серверов заменил на них уже все дистки. А некоторые и по два раза. За одним диском не уследил и он в понедельник утром встал колом, но RAID-1 это дело парировал. Так что бизнес фирмы от вылетов дисков не страдает. Если изначально продумать все эти "дисциплины".

А по сотрудникам ДЦ - там не в сотрудниках дело, а в изначальной жадности. Принципиально нельзя продавать ресурсы на _одном_ диске. А то и на одном сервере. Продавать можно только ресурс "высокой доступности". Ту же виртуальную машину, которая может (случись что) live-мигрировать на резервную ноду, и которая стоит на отказоустойчивом СХД. Если этого не обеспечено, то есть все основания думать о смене датацентра. Поскольку этот не обеспечивает основное требование договора 24х365.