Linux зависла командная строка

Как легко исправить команды с ошибками в Linux

Знаю, знаю! Вы можете просто нажать стрелку ВВЕРХ, чтобы вызвать команду, которую вы только что запустили, и перейти к слову с ошибкой, используя клавиши LEFT / RIGHT, и исправить слова с ошибками, наконец, нажать клавишу ENTER, чтобы снова запустить его, правильно?

Существует еще один простой способ исправить команды с ошибками Bash в GNU / Linux. В этом кратком руководстве объясняется, как это сделать.

Исправление команд с ошибками в Linux

Вы запустили неправильную команду, как показано ниже

Ты заметил? В приведенной выше команде есть опечатка. Я пропустил букву «a» в команде «uname».

Я делал такие глупые ошибки во многих случаях.

Прежде чем я узнал этот трюк, я использовал стрелку ВВЕРХ, чтобы вызвать команду и перейти к слову с ошибкой в команде, исправить орфографию и опечатки и нажать клавишу ENTER, чтобы снова запустить эту команду. Но поверь мне. Следующий трюк очень легко исправить любые опечатки и орфографические ошибки в команде, которую вы только что побежали.

Чтобы легко исправить вышеуказанную команду с ошибками, просто запустите:

Это заменит символы «nm» на «nam» в команде «uname». Круто, да?

Это не только исправляет опечатки, но и выполняет команду. Проверьте следующий снимок экрана.

ck the following screenshot.

Используйте этот трюк, когда вы сделали опечатку в команде.

Обратите внимание, что он работает только в оболочке Bash.

Бонусный трюк

Вы когда-нибудь задумывались, как автоматически исправлять орфографические ошибки и опечатки при использовании команды «cd»?

Все в порядке! Следующий трюк объяснит, как это сделать.

Этот трюк поможет только устранить орфографические ошибки и опечатки при использовании команды «cd».

Скажем, вы хотите перейти в каталог «Downloads», используя команду:

К сожалению! Нет такого файла или каталога с именем «Donloads». Ну, правильное имя было «Downloads».

В приведенной выше команде отсутствует «w».

Чтобы исправить эту проблему и автоматически исправить опечатки при использовании команды cd, отредактируйте файл .bashrc:

Добавьте строчку в конец.

Введите :wq для сохранения и выхода из файла.

Наконец, запустите следующую команду, чтобы обновить изменения.

Теперь, если во время использования команды cd есть какие-либо опечатки или орфографические ошибки, он автоматически исправляет и помещает вас в правильный каталог.

Как вы видите в приведенной выше команде, я намеренно сделал опечатку («Donloads» вместо «Downloads»), но Bash автоматически обнаружил в нем правильное имя каталога и cd.

Оболочки Fish и Zsh имеют встроенную функцию.

Таким образом, вам не нужен этот трюк, если вы их используете.

Однако этот трюк имеет некоторые ограничения. Он работает только в том случае, если вы используете правильный случай. В приведенном выше примере, если вы наберете «cd donloads» вместо «cd Donloads», он не узнает правильный путь. Кроме того, если в пути было несколько букв, это тоже не сработает.

Источник

Что делать при зависании программ в Linux?

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

Почему зависают программы и приложения?

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

Некачественное программное обеспечение (ПО), которое не было должным образом протестировано разработчиками. А также ПО сомнительного происхождения также являются частой причиной зависаний.

Аппаратная составляющая также оказывает существенное влияние на работу ОС. Например достаточный объём оперативной памяти, стабильные частоты, на которых она работает, высокоскоростная дисковая подсистема. Всё это является важным фактором, существенно снижающим вероятность зависаний.

Системы на основе Linux заслуженно и неоспоримо считаются наиболее устойчивыми к различного рода сбойным ситуациям. Ядро этих систем действительно, работает очень стабильно и способно «переваривать» нагрузки в круглосуточном режиме на протяжение очень длительного времени. Системы Windows такими показателями похвастаться не могут. Именно поэтому, управление самыми высоконагруженными серверами, где критически важна надёжная работа системы. Доверяют именно Unix/Linux.

Но, как бы ни была надёжна Linux, сбои и зависания происходят и в этой ОС. В подавляющем большинстве случаев они связаны либо с устаревшей, маломощной аппаратной составляющей, либо с нестабильным ПО. В последнем случае это касается по большей части настольных компьютеров обычный пользователей. Где используются различные графические оболочки. Что и говорить, графическая подсистема — одна из наиболее уязвимых для сбоев в ОС Linux.

Завершение зависших приложений в командной оболочке

Прежде всего необходимо знать и понимать, каким образом идентифицировать зависший процесс. Ну а дальше попытаться его завершить принудительно.
Каждому процессу в системе соответствует свой уникальный идентификатор (PID). При помощи которого система им управляет, в частности может завершить. Самым простым способом узнать PID процесса является команда pidof:

В данном случае в качестве аргумента указывается имя процесса. Для примера используется утилита psensor. Считывающая показания, предоставляемые различными провайдерами для системных датчиков: lm-sensors, hddtemp, udisks2 и т. д. Если, к примеру, замечено, что psensor не обновляет показания датчиков, т. е. предполагается, что эта утилита зависла. То завершить её можно командой kill, передав ей соответствующий PID:

Эта команда предназначена для отправки сигналов управления процессам. По-умолчанию завершает процесс. Для завершения процессов по их имени существует команда killall:

Однако, использование kill по идентификаторам процессов более корректно. К тому же команда kill более предпочтительна для крепко зависших процессов. И обладает более гибкими возможностями.

Вообще в таких случаях может быть проблематично использовать или запустить командную консоль. Поскольку она также может зависнуть. Тогда можно попытаться переключиться на параллельный сеанс комбинацией клавиш . Где N – номер функциональных клавиш от 1 до 12, например F1, F2, . . . F12. И уже оттуда продолжить работу с процессами.

Зависание графической оболочки в Linux

Как уже было отмечено выше, если в системе установлена и работает какая-либо из графических оболочек (GNOME, KDE, Xfce и т. д.), то это лишний повод увидеть перед собой зависшее окно какого-либо приложения, либо даже целиком некликабельный рабочий стол. В таком случае удобно воспользоваться графическим менеджером процессов и управлять ими визуально. Используя элементы интерфейса и контекстное меню процесса.

Но бывает также и так, когда рабочий стол не реагирует ни на клики мыши, ни на привязанные к нему клавиатурные комбинации. В этом случае остаётся задействовать виртуальные терминалы. Переключившись на один из них, как это указано в предыдущей главе по нажатию сочетаний клавиш . Стоит отметить, что при переключении на такой терминал необходимо сначала авторизоваться в системе через него. После этого можно попытаться перезапустить графическую оболочку и/или X-сервер, например для Ubuntu:

Здесь lightdm или ssdm зависит от того, какая графическая оболочка используется. В последних версиях дистрибутивов Ubuntu в основном используется композитный менеджер ssdm.

Нехватка памяти и полное зависание системы

В некоторых случаях зависание процесса может быть вызвано нехваткой памяти. Особенно когда сам процесс потребляет её слишком много, т. е. Как говорят, «сильно течёт». Иногда это не очевидно, если такой процесс выполняется в фоне, а пользователь непосредственно с ним не работает. Такие случаи выявляются по первичным признакам в виде общей «заторможенности» всей системы. Когда зависший процесс отобрал большую часть ресурса памяти. В данном случае нужно выявить такой процесс, воспользовавшись командой ps. И отсортировав все процессы по количеству используемой памяти:

Будет выведена таблица, среди столбцов которой есть столбец «%MEM», указывающий количество памяти в процентном соотношении от доступной в системе и используемой соответствующим процессом, запущенным командой, указанной в столбце «COMMAND».
К примеру, если это веб-браузер Firefox, то у него может быть много связанных с ним процессов:

Их можно разом завершить:

Но может и случиться так, что даже Linux-система может зависнуть наглухо, не реагируя ни на что. В таких случаях, как правило, само ядро продолжает работать и ему можно отдавать команды, в том числе и через клавиатуру. Таким образом, можно попытаться более-менее корректно, с наименьшими потерями выполнить ручную поэтапную перезагрузку, передавая ядру соответствующие команды через клавиатурные сочетания. Эти команды следует отдавать, нажимая следующие клавиши через каждые 3-4 секунды, при этом удерживая сочетание клавиш :

1. R – возврат управления клавиатурой непосредственно ядру.
2. E – отправка сигнала SigTerm всем запущенным процессам.
3. I — отправка сигнала SigKill всем запущенным процессам.
4. U – перемонтирование всех файловых систем в режиме «только чтение».
5. S – сохранение всех актуальных буферов и временных данных файловых систем на диск.
6. B – собственно, перезагрузка.

На этапах 2 и 3 стоит объективно оценивать время работы команды. Если процессов запущенно много, то и времени на их завершение и уничтожение может также потребоваться несколько больше, чем 3-4 секунды.

Заключение

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Виснет консоль на некоторых командах

При заходе по SSH на сервер все работает отлично, кроме некоторых команд. Например простецкое

Что это может быть вообще такое? Может ли это быть связано с настройками iptables?

Java же!

И насколько длинный ps у твоего сервера? Что на нём крутится? Как с памятью дела?

Твой ответ мы отошлём телепатам по почте на тот курорт, на котором они сейчас отдыхают. Так что не взыщи, если долго не будет ответов по сути.

повторить не смог

Описание проблемы — как будто школьник писал — понимаю. Но, черт возьми, проблема именно такая! И я не школьник, уж поверьте =)

Проблема не в длине ps, думаю. На сервере пока ничего не крутится, памяти 24 GB.

Некоторые команды почему-то отрубают консоль напрочь. Не сервер вырубают, а консоль. Например, смотрю top. Нажимаю «с» — чтобы смотреть список процессов с аргументами, и консоль виснет. Может, как-то с шириной консоли связано?

проблем с mtu нет?

Я тоже сначала на MTU подумал. У меня помимо этого еще 5 серверов у этого провайдера, подобных проблем не было. Везде MTU=1500.

Попробовал 1400 поставить — то же самое. Стабильно вырубает консоль на «ps -ef|grep something».

Верю, верю. Ну sshd_config выкини тогда что ли.

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

еще я бы попробовал сделать strace из соседней ссх сессии и глянуть что там.

Стабильно вырубает консоль на «ps -ef|grep something».

ps -ef|grep —color=never something

результат тот же ?

и какие ещё команды вырубают консоль ?

кстати про ps «The utility does not correctly display argument lists containing multibyte characters.»

кстати про ps «The utility does not correctly display argument lists containing multibyte characters.»

тогда бы консоль висла и при простом ps -ef ?

работает ли pgrep -lf java

у меня такое было, когда работал через OpenVPN over udp, переключил на tcp — все заработало. Ковыряться не стал. Причем до этого стабильно и долго работало, потом вот неожиданно стало как у тебя.

тогда бы консоль висла и при простом ps -ef ?

не факт..grep все-таки нарушает поток символов и из случайно встретившихся на разных строках DC1 DC0 вполне мог один выкусить

а вообще информации нехватает. Неплохо-бы знать что за терминал используется, увидеть переменные TERM COLUMNS COLS в терминале и в сессии ssh. Выхлоп stty тоже не помешал-бы. И надеюсь ssh-сессия чистая ? Безо всяких mc, screen на концах ??

автор говорит, что на той-же площадке ещё 5 его серверов, думаю что под тем-же дистрибутивом с тем-же софтом, поэтому варианты неправильно настроенной сети или сбойного ssh крайне маловероятны. Прям таки даже интерестно что это за такие «детские грабельки» 🙂

не давно была такая же проблема вылечилось через TCPMSS в iptables(проблема была в MTU). Некоторые команды(не всегда выдающие что-то большое) вешали консоль SSH намертво

Дополнительные данные

— все эти команды тоже вешают консоль.

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

Да, это включено.

у меня такое было, когда работал через OpenVPN over udp, переключил на tcp — все заработало. Ковыряться не стал. Причем до этого стабильно и долго работало, потом вот неожиданно стало как у тебя.

У меня простой советский OpenSSH.

а вообще информации нехватает. Неплохо-бы знать что за терминал используется, увидеть переменные TERM COLUMNS COLS в терминале и в сессии ssh. Выхлоп stty тоже не помешал-бы. И надеюсь ssh-сессия чистая ? Безо всяких mc, screen на концах ??

Про чистоту не совсем понял. На терминале ^M и подобного нету, если про это речь. Остальные данные:

автор говорит, что на той-же площадке ещё 5 его серверов, думаю что под тем-же дистрибутивом с тем-же софтом, поэтому варианты неправильно настроенной сети или сбойного ssh крайне маловероятны. Прям таки даже интерестно что это за такие «детские грабельки» 🙂

Дистрибутив везде Ubuntu, но на проблемной машине версия 11.04, на остальных более старые версии.

TCPMSS в iptables и STRACE попробую и отпишу еще чуть позже.

Источник