У мене виникла проблема з сервером, на якому Apache і Snort займали 100% процесора, завдяки чому sshd не реагує на віддалений доступ. Мені довелося фізично зайти на сервер, щоб увійти в локальний TTY, а потім зупинити apache / snort.
Мені цікаво, чи є спосіб гарантувати підключення ssh у ситуації зі 100% завантаженим процесором / пам'яттю. Визначити "приємний" пріоритет буде достатньо?
Дякую!
Відповіді:
Крім використання позадіапазонного методу, немає жодного способу гарантувати, що SSH буде доступний на повністю завантаженому сервері. Якщо ваша служба навантажена настільки, що вона навіть не може обслуговувати базовий SSH-термінал, у вас є інші проблеми.
Так, reniceі надання йому меншої niceвартості підвищить продуктивність при великих навантаженнях, але замість цього використання чогось на кшталт pam_security (приклад, показаний тут ) запобіжить Apache / що завгодно, щоб не почати керувати .
niceвинуватець буде завантажений з процесора досить швидко, щоб забезпечити доступ до SSH (або з цього приводу, що будь-який доступ до вашої консолі був би корисний). Основне питання (ресурс-бори) необхідно вирішувати. Пожежна боротьба - це погане управління системою.
Вашим загальним рішенням для цього є позадіапазонний інструмент управління, наприклад Dell iDRAC, IBM Remote Supervisor або HP iLO. Він завжди може представити консоль (чи може реагувати на неї ОС залежно від вашої конкретної ситуації) та застосувати потрібні стани живлення за необхідності.
Я мав певний успіх, надаючи привілей на sshd у режимі реального часу, однак це коштує необхідності перезавантажити машину, якщо один із процесів у реальному часі закінчується.
Тож якщо ви хочете піти цим маршрутом, почніть другий демон-шш, який призначений лише для надзвичайних ситуацій. :)
realtimeing sshd здається мені небезпечним, особливо на порту 22 (сканування SSH може стати нападом DoS - біг на інший порт може пом'якшити це, але я все одно