Astra linux зависает намертво
Добрый день. Помогите пожалуйста решить проблему.
Недавно перешли по импортозамещению на Astra Linux Орел
На скриншоте видны характеристики сервера.
Версия ОС сервера - 2.12.40
Версия ОС клиентских машин - 2.12.42
Версия 1С - Предприятие 8.3 (8.3.15.2107)
Проблем конечно хватает с этой ОС, но они в принципе сильно работу не тормозят.
Самая главная проблема, которая появилась - зависание 1С (толстый клиент) при подключении посредством RDP. Зависания происходят бывает 3 раза в день, а бывает и чаще.
Не важно подключиться через Remmina или через xfreerdp.
Зависает как правило когда работают несколько человек в 1С одновременно (человек 6). Проблема наблюдается у трех пользователей с остальными проблем не наблюдал. Если у одного пользователя зависает 1С, все остальные работают без зависания, но чувствуется, что система работает "в напряг".
После зависания окна 1С приходится закрывать процесс 1С через "Системный монитор".
После закрытия 1С и повторном запуске 1С продолжает зависать при каком-либо действии. Бывает зависнет сразу при клике на любую кнопку на панели задач 1С, а бывает зависает при работе с документом, при вызове какого-либо раздела.
Далее выявил закономерность. Если на учетке Buh1 зависло, то так и будет зависать, хоть сколько раз перезапускай 1С. Приходится заходить в 1С под другой учеткой Buh2. Тогда 1С работает без зависаний, но это не всегда стабильно и не всегда помогает. Помогало также смена пользователя 1С. Заходил вместо Бухгалтера на ее компьютере под своей учеткой 1С и она не зависала.
Когда зависает окно 1С, окно программы замирает, становится неактивным. Его можно свернуть, передвинуть и т.д. но оно становится однотонным серым.
При зависании в Системной мониторе в Таблице процессов, напротив зависшего процесса в разделе ЦП (центральный процессор) стоит значение 25% или 1/4 суммарного потребления процессорного времени процессором. То есть одно ядро из 4 грузится дико и по полной на 100%.
Если долго подождать, то окно может развиснуть и выполнить действие, которое сотрудник последний раз предпринял. (нажал к примеру на какой-нибудь значок на панели задач). Потом снова висит.
Ну этому есть объяснение - ядро отведенное под данный процесс 1С загружено под 100%, соответственно можно и не ждать, что 1С будет работать стабильно.
Ключ 1С аппарантный. Попробовали выгрузить модуль ядра vhci-hcd." - ситуация не изменилась.
Куда копать. Так невозможно работать. С ОС Windows привыкли работать, проблем не было, а Астра это ппц.
Техподдержка Linux утверждают что проблема у 1С, а 1С говорят что проблема у Астры.
Очень прошу помочь, работать просто невозможно.
У меня уже на втором компе под Смоленском 1,5 такой-же случай.
Начи
нается с открытия файла LOffice, файл виндовый, зависает. И это в 3 уровне. Потом офис не открывается, пишет что фатальная ошибка. Чисткой и переустановкой офиса не помогает. Под другими уровнями все работает. Все лечится только установкой нового пользователя. И если удалить старого пользователя, вычистить и удалить в home, завести по-новому этого юзера, то под 3 уровнем стол не грузится. Не хотелось бы переустанавливать fly
Сегодня уже третья машина при открытии MOffise файла виснет LibreOffice, работа по 0 уровнем. Опять-же вычистил все. Не помогло. Завел нового пользователя
всем привет. у меня вопросы. у заказчика Astra 1.6 SE. Astra 1.6 SE производная от какой версии Debian? Какая PostgreSQL в репо и какая jdk? Как нибудь можно Astra 1.6 SE скачать себе?
Необходимо поставить по на Смоленск с сd rom напомните как нужно ли прописывать путь (и как) или достаточно sudo install название день пакета. ?
Владислав, Как говорит офф сайт Астры версия debian 9. PostgreSQL 9.6. Как получить, кроме покупки, непонятно. Отдел продаж на письмо о тестовой версии молчит. Если получиться получить, поделитесь пожалуйста)
Доброго всем. У меня следующая проблема: сканер на принтере под рутом сканит,а под пользователем нет,просто не видит сканер. Из трех таких принтеров сканит только один. Дрова ставил одни на все. ОС Astra linux Смоленск 1.6. Пользователь доменный.
И еще вопрос, есть ли типовая инструкция по установке пакетов deb с архитектурой i386 на Смоленск 64x?? Буду признателен за помощь))
Ребят помогите поставили астру смоленск 1.5 на сервер дальше командной строки не идёт графическая оболочка не в какую не запускается видеокарта амд радеон es1000 есть ли какое то решение пробовали уже разные способы может кто сталкивался .
Прописывать устройства в Fly-admin-smc, зайти в устройства - добавить воткнуть usb кабель когда запросит, потом дать права для пользователя. По второму вопросу - как устанавливали ОС в конце 32бит ставили?
Максим, Ставили в графическом режиме, или нет? Вытащите карту, установите ОС, потом поставьте назад посмотрите подхватит карту или нет. Будете знать тогда точно карта виновата
Она встроенная это же сервер оттуда ее не вытащить . Если про 32 бита ко мне то да ставили галку
Юрий,
Она встроенная это же сервер оттуда ее не вытащить . Если про 32 бита ко мне то да ставили галку
Виснет намертво (Линукс виснет без симптомов)
Модератор: SLEDopit
Виснет намертво
У меня вот какая проблема. Часто виснет линукс, ставил разные дистрибутивы (ubuntu/xubuntu, openSuse и Mint на основе Debian). Система может работать нормально несколько дней, а может в день зависнуть раза 3-4. Клавиатура и мышь не работают, на Ctrl+Alt+Backspace не реагирует, иногда начинают моргать лампочки Caps Lock и Scroll Lock, но чаще и этого нет. После зависания светодиод на мышке, который показывает установленную чувствительность гаснет (мышь A4tech X7 XL-750F).
Не могу понять кто виноват. Зависает в самый неожиданный момент, бывает просто ведешь мышь по экрану, а потом бац! все замерло. К kern.log к моменту зависаний никаких записей нет.
На перегрев проца не похоже - когда оставлял на полдня комп обрабатывать фотки с полной загрузкой процессора, все работало нормально. Memtest прогнал пару раз - тоже ничего подозрительного не нашел. Compiz отключен, под Windows на том же компе такой проблемы нет.
Железо: Мать Asus A8V deluxe, проц AMD Athlon 3500+, 2.5 гига оперативки, два харда (один IDE, второй sata). Видюха Radeon HD 3650 AGP. Стоят последние ATI-ые драйвера.
Может быть есть еще какой-то лог, который может подсказать в какую сторону копать?
очень похоже, что проблема как раз с железом.1. MHDD
2. Внешний осмотр матери
3. замена SATA шлейфа. После Alt+SysRq+R в консоль переключиться не получается?
Вообще действительно похоже на проблему с железом. И вряд ли с хардом, хотя smartctl глянуть и не помешает.
| в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Спасибо всем ответившим, пробую проверить/пощупать железо. Внешне ничего подозрительного не видно, хотя от набившейся пыли окмп почистить все-таки пришлось.
На комбинации клавиш с SysRq во время зависаний комп не реагирует, как и на нажатия NumLock/CapsLock.
У меня вот какая проблема. Часто виснет линукс, ставил разные дистрибутивы (ubuntu/xubuntu, openSuse и Mint на основе Debian). Система может работать нормально несколько дней, а может в день зависнуть раза 3-4. Клавиатура и мышь не работают, на Ctrl+Alt+Backspace не реагирует, иногда начинают моргать лампочки Caps Lock и Scroll Lock, но чаще и этого нет. После зависания светодиод на мышке, который показывает установленную чувствительность гаснет (мышь A4tech X7 XL-750F).
Не могу понять кто виноват. Зависает в самый неожиданный момент, бывает просто ведешь мышь по экрану, а потом бац! все замерло. К kern.log к моменту зависаний никаких записей нет.
На перегрев проца не похоже - когда оставлял на полдня комп обрабатывать фотки с полной загрузкой процессора, все работало нормально. Memtest прогнал пару раз - тоже ничего подозрительного не нашел. Compiz отключен, под Windows на том же компе такой проблемы нет.
Железо: Мать Asus A8V deluxe, проц AMD Athlon 3500+, 2.5 гига оперативки, два харда (один IDE, второй sata). Видюха Radeon HD 3650 AGP. Стоят последние ATI-ые драйвера.
Может быть есть еще какой-то лог, который может подсказать в какую сторону копать?
после месяца таких же танцев [внезапно] умер контроллер на HDD - "fatal error input/output" . вот теперь любуюсь на прикольные блины - блястят ! . ну я же просил четыреста капель , а сдесь четыреста две .
Спасибо всем ответившим, пробую проверить/пощупать железо. Внешне ничего подозрительного не видно, хотя от набившейся пыли окмп почистить все-таки пришлось.
На комбинации клавиш с SysRq во время зависаний комп не реагирует, как и на нажатия NumLock/CapsLock.
Ни одна современная операционная система (ОС), какой бы совершенной она ни была, не избавлена от вероятности зависаний и/или сбоев. Однако, какими бы ни были зависания и как бы часто они не происходили, всегда следует уметь выходить из подобных ситуаций с наименьшими потерями и ущербом для системы. О том, как правильно это делать в системах Linux. Какие вообще бывают ситуации, связанные с зависанием процессов или самой системы, будет изложено в данной статье.
Почему зависают программы и приложения?
В первую очередь это происходит из-за действий пользователей. Система не может предусмотреть все без исключения ситуации, которые потенциально могут вызвать сбой или зависание. А действия самого пользователя порой бывают чрезмерно необдуманными.
Некачественное программное обеспечение (ПО), которое не было должным образом протестировано разработчиками. А также ПО сомнительного происхождения также являются частой причиной зависаний.
Аппаратная составляющая также оказывает существенное влияние на работу ОС. Например достаточный объём оперативной памяти, стабильные частоты, на которых она работает, высокоскоростная дисковая подсистема. Всё это является важным фактором, существенно снижающим вероятность зависаний.
Системы на основе Linux заслуженно и неоспоримо считаются наиболее устойчивыми к различного рода сбойным ситуациям. Ядро этих систем действительно, работает очень стабильно и способно «переваривать» нагрузки в круглосуточном режиме на протяжение очень длительного времени. Системы Windows такими показателями похвастаться не могут. Именно поэтому, управление самыми высоконагруженными серверами, где критически важна надёжная работа системы. Доверяют именно Unix/Linux.
Но, как бы ни была надёжна Linux, сбои и зависания происходят и в этой ОС. В подавляющем большинстве случаев они связаны либо с устаревшей, маломощной аппаратной составляющей, либо с нестабильным ПО. В последнем случае это касается по большей части настольных компьютеров обычный пользователей. Где используются различные графические оболочки. Что и говорить, графическая подсистема — одна из наиболее уязвимых для сбоев в ОС Linux.
Завершение зависших приложений в командной оболочке
Прежде всего необходимо знать и понимать, каким образом идентифицировать зависший процесс. Ну а дальше попытаться его завершить принудительно.
Каждому процессу в системе соответствует свой уникальный идентификатор (PID). При помощи которого система им управляет, в частности может завершить. Самым простым способом узнать PID процесса является команда pidof:
В данном случае в качестве аргумента указывается имя процесса. Для примера используется утилита psensor. Считывающая показания, предоставляемые различными провайдерами для системных датчиков: lm-sensors, hddtemp, udisks2 и т. д. Если, к примеру, замечено, что psensor не обновляет показания датчиков, т. е. предполагается, что эта утилита зависла. То завершить её можно командой kill, передав ей соответствующий PID:
Эта команда предназначена для отправки сигналов управления процессам. По-умолчанию завершает процесс. Для завершения процессов по их имени существует команда killall:
Однако, использование kill по идентификаторам процессов более корректно. К тому же команда kill более предпочтительна для крепко зависших процессов. И обладает более гибкими возможностями.
Вообще в таких случаях может быть проблематично использовать или запустить командную консоль. Поскольку она также может зависнуть. Тогда можно попытаться переключиться на параллельный сеанс комбинацией клавиш <Ctrl+Alt+FN>. Где N – номер функциональных клавиш от 1 до 12, например F1, F2, . . . F12. И уже оттуда продолжить работу с процессами.
Зависание графической оболочки в Linux
Как уже было отмечено выше, если в системе установлена и работает какая-либо из графических оболочек (GNOME, KDE, Xfce и т. д.), то это лишний повод увидеть перед собой зависшее окно какого-либо приложения, либо даже целиком некликабельный рабочий стол. В таком случае удобно воспользоваться графическим менеджером процессов и управлять ими визуально. Используя элементы интерфейса и контекстное меню процесса.
Но бывает также и так, когда рабочий стол не реагирует ни на клики мыши, ни на привязанные к нему клавиатурные комбинации. В этом случае остаётся задействовать виртуальные терминалы. Переключившись на один из них, как это указано в предыдущей главе по нажатию сочетаний клавиш <Ctrl+Alt+FN>. Стоит отметить, что при переключении на такой терминал необходимо сначала авторизоваться в системе через него. После этого можно попытаться перезапустить графическую оболочку и/или X-сервер, например для Ubuntu:
Здесь lightdm или ssdm зависит от того, какая графическая оболочка используется. В последних версиях дистрибутивов Ubuntu в основном используется композитный менеджер ssdm.
Нехватка памяти и полное зависание системы
В некоторых случаях зависание процесса может быть вызвано нехваткой памяти. Особенно когда сам процесс потребляет её слишком много, т. е. Как говорят, «сильно течёт». Иногда это не очевидно, если такой процесс выполняется в фоне, а пользователь непосредственно с ним не работает. Такие случаи выявляются по первичным признакам в виде общей «заторможенности» всей системы. Когда зависший процесс отобрал большую часть ресурса памяти. В данном случае нужно выявить такой процесс, воспользовавшись командой ps. И отсортировав все процессы по количеству используемой памяти:
Будет выведена таблица, среди столбцов которой есть столбец «%MEM», указывающий количество памяти в процентном соотношении от доступной в системе и используемой соответствующим процессом, запущенным командой, указанной в столбце «COMMAND».
К примеру, если это веб-браузер Firefox, то у него может быть много связанных с ним процессов:
Их можно разом завершить:
Но может и случиться так, что даже Linux-система может зависнуть наглухо, не реагируя ни на что. В таких случаях, как правило, само ядро продолжает работать и ему можно отдавать команды, в том числе и через клавиатуру. Таким образом, можно попытаться более-менее корректно, с наименьшими потерями выполнить ручную поэтапную перезагрузку, передавая ядру соответствующие команды через клавиатурные сочетания. Эти команды следует отдавать, нажимая следующие клавиши через каждые 3-4 секунды, при этом удерживая сочетание клавиш :
На этапах 2 и 3 стоит объективно оценивать время работы команды. Если процессов запущенно много, то и времени на их завершение и уничтожение может также потребоваться несколько больше, чем 3-4 секунды.
Заключение
В заключение, стоит отметить, что хотя в системах Linux далеко не так часто случаются вообще какие-либо зависания. Однако всё же необходимость правильно и быстро вывести систему из нештатного состояния может возникнуть в любой момент. Такими состояниями являются рассмотренные в данной статье как зависания отдельных процессов, так и целых подсистем, например графической. Также был рассмотрен вариант с ручной перезагрузкой системы в случае её полного зависания.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Читайте также: