как узнать кто перезагрузил сервер
Как узнать кто перезагрузил сервер
Всем привет, сегодня небольшая заметка для начинающих системных администраторов, рассмотрим вопрос как определить кто перезагрузил сервер Windows. Бывают ситуации, что по какой то причине отваливается сервер его удаленно перезагрузили, зайдя на которой вы не видите что у него был синий экран BSOD, и значит надо искать кто то его отправил в ребут. Вам необходимо выяснить кто это был.
И так рассматривать кто перезагрузил сервер Windows я буду на примере Windows Server 2008 R2, но все действия абсолютно одинаковы в любой версии Windows начиная с Vista. Поможет нам в реализации нашей задачи оснастка Просмотр событий. Открыть его можно Пуск-Администрирование-Просмотр событий или нажать WIN+R и ввести там evenvwr.msc.
у вас откроется оснастка Просмотр событий. Вам нужно выбрать журнал Windows Система. В нем как раз и находится нужная нам информация в виде события. Проблема в том что их генерируется порой очень много, для этого придумали фильтр. Жмем справа в колонке действия Фильтр текущего журнала.
В открывшемся окне вам нужно отфильтровать данный журнал. Задаем дату, я выставил период за последнюю неделю,
можете выставить и меньше и больше. Выбираем уровень событий, ставим все и самое главное какой будет источник событий. В источнике событий выбираете USER32, он и хранит нужный лог.
В итоге у меня получилась вот такая картина
После нажатия кнопки ок вы получите отфильтрованный журнал система, у меня нашлось одно событие. Код события 1074 о том что сервер с Windows Server 2008 R2 был перезагружен системой после установки программы Microsoft SOAP Toolkit.
Мне этого мало и нужно понять кто начал установку данного приложения. Для этого так же переходив уже в журнал Приложения, делаем фильтр, дату ставим например тоже неделю
Еще отфильтруем по кодам событий с 1035-1040
И в итоге мы видим вот такое событие
Вот мы и выяснили кто он мистер Х. В качестве эксперимента можете удаленно перезагрузить тестовую машину или например я рассказывал как перезагрузить компьютер через командную строку.
Как отследить кто нагибает сервер 1С
А по поводу перегрузки сервера каждый день, это было сделано для разгона юзеров, но не работало, после перегрузки сеансы снова восстанавливались, может еще здесь как то собака порылась. И остановка службы 1с батниками и запуск через час тоже не помогали. Я так и не понял почему такое происходит.
(16) 8.3
(14) 1с и скл живут на одном сервере
И еще момент восстанавливали сеансы базы с толстыми клиентами, и сами базы в режиме совместимости с 8.2 8.1. Но это так отступление от темы, потому что это происходит и на другом сервере где проблем с пиковыми нагрузками нет.
Сейчас написана иб которая только и занимается тем что удаляет сеансы пользователей на кластерах, сейчас проблем с бэкапами нет. (И причина тоже не в ней, написана она была уже во время проблем с производительностью)
13. Стандартные платежки БП3
Значительное потребление памяти процессами кластера на сервере приложений
https://its.1c.ru/db/metod8dev#content:5815:hdoc
(0) > под каждую базу создается свой рпхост
Зачем?
Этой фигнёй имеет смысл страдать в исключительных случаях в целях расследования проблем. Например, когда никак не удаётся вычислить, какая именно ИБ сбоит.
(4) > сервер перегружается каждую ночь
Зачем? Вам больше заняться нечем?
(8) > это было сделано для разгона юзеров
Зачем? Чем вам мешают работающие юзеры?
> остановка службы 1с батниками и запуск через час тоже не помогали
Это от того, что кому-то лень почитать документацию. Пример «правильного» батника от 1С (для 64-битного сервера, у которого папка кластера размещена по нетиповому пути «F:\srvinfo\reg_1541», а пользователь, от имени которого работает служба 1С называется Admin_1C):
set LOG_FILE=»scripts.log»
set SERVICE_1C_NAME=»1C:Enterprise 8.3 Server Agent (x86-
64)»
set SERVICE_RAS_NAME=»1C:Enterprise 8.3 Remote Server»
echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
При необходимости в батник следует добавить еще остановку службы сервера хранилища и службу агента ЦКК.
Потом не забыть всё это хозяйство запустить. У 1С на ИТС есть соответствующий батничек для старта всех служб.
(35) Что дадут счетчики производительности винды, покажет что у меня проц на серваке загружен до 100%, я и так это знаю. Мои счетчики производительности в виде юзеров мне сразу сообщают об этом. Дальше то что?
Технологический журнал попробую включить посмотреть, но плохо себе представляю что там смотреть, пару раз всего пользовался когда искал ошибку.
А почему не создавать проц. под каждую иб, в этом есть что-то что может привести к проблемам?
Пять шагов к спасению Linux-сервера, который рухнул
Мне доводилось видеть множество Linux-серверов, которые, без единой перезагрузки, работали годами, в режиме 24×7. Но ни один компьютер не застрахован от неожиданностей, к которым могут вести «железные», программные и сетевые сбои. Даже самый надёжный сервер может однажды отказать. Что делать? Сегодня вы узнаете о том, что стоит предпринять в первую очередь для того, чтобы выяснить причину проблемы и вернуть машину в строй.
Поиск и устранение неполадок: раньше и теперь
Когда, в 1980-х, я начал работать системным администратором Unix — задолго до того, как Линус Торвальдс загорелся идеей Linux — если с сервером было что-то не так, это была реальная засада. Тогда было сравнительно мало инструментов для поиска проблем, поэтому для того, чтобы сбойный сервер снова заработал, могло понадобиться много времени.
Теперь всё совсем не так, как раньше. Как-то один системный администратор вполне серьёзно сказал мне, говоря о проблемном сервере: «Я его уничтожил и поднял новый».
В былые времена такое звучало бы дико, но сегодня, когда ИТ-инфраструктуры строят на основе виртуальных машин и контейнеров… В конце концов, развёртывание новых серверов по мере необходимости — это обычное дело в любой облачной среде.
Сюда надо добавить инструменты DevOps, такие, как Chef и Puppet, используя которые легче создать новый сервер, чем диагностировать и «чинить» старый. А если говорить о таких высокоуровневых средствах, как Docker Swarm, Mesosphere и Kubernetes, то благодаря им работоспособность отказавшего сервера будет автоматически восстановлена до того, как администратор узнает о проблеме.
Данная концепция стала настолько распространённой, что ей дали название — бессерверные вычисления. Среди платформ, которые предоставляют подобные возможности — AWS Lambda, Iron.io, Google Cloud Functions.
Благодаря такому подходу облачный сервис отвечает за администрирование серверов, решает вопросы масштабирования и массу других задач для того, чтобы предоставить клиенту вычислительные мощности, необходимые для запуска его приложений.
Бессерверные вычисления, виртуальные машины, контейнеры — все эти уровни абстракции скрывают реальные серверы от пользователей, и, в некоторой степени, от системных администраторов. Однако, в основе всего этого — физическое аппаратное обеспечение и операционные системы. И, если что-то на данном уровне вдруг разладится, кто-то должен привести всё в порядок. Именно поэтому то, о чём мы сегодня говорим, никогда не потеряет актуальности.
Помню разговор с одним системным оператором. Вот что он говорил о том, как надо поступать после сбоя: «Переустановка сервера — это путь вникуда. Так не понять — что стало с машиной, и как не допустить такого в будущем. Ни один сносный администратор так не поступает». Я с этим согласен. До тех пор, пока не обнаружен первоисточник проблемы, её нельзя считать решённой.
Итак, перед нами сервер, который дал сбой, или мы, по крайней мере, подозреваем, что источник неприятностей именно в нём. Предлагаю вместе пройти пять шагов, с которых стоит начинать поиск и решение проблем.
Шаг первый. Проверка аппаратного обеспечения
В первую очередь — проверьте железо. Я знаю, что звучит это тривиально и несовременно, но, всё равно — сделайте это. Встаньте с кресла, подойдите к серверной стойке и удостоверьтесь в том, что сервер правильно подключён ко всему, необходимому для его нормальной работы.
Я и сосчитать не смогу, сколько раз поиски причины проблемы приводили к кабельным соединениям. Один взгляд на светодиоды — и становится ясно, что Ethernet-кабель выдернут, или питание сервера отключено.
Конечно, если всё выглядит более-менее прилично, можно обойтись без визита к серверу и проверить состояние Ethernet-соединения такой командой:
Если её ответ можно трактовать, как «да», это значит, что исследуемый интерфейс способен обмениваться данными по сети.
Однако, не пренебрегайте возможностью лично осмотреть устройство. Это поможет, например, узнать, что кто-то выдернул какой-нибудь важный кабель и обесточил таким образом сервер или всю стойку. Да, это до смешного просто, но удивительно — как часто причина отказа системы именно в этом.
Ещё одну распространённую аппаратную проблему невооружённым взглядом не распознать. Так, сбойная память является причиной всевозможных проблем.
Виртуальные машины и контейнеры могут скрывать эти проблемы, но если вы столкнулись с закономерным появлением отказов, связанных с конкретным физическим выделенным сервером, проверьте его память.
Для того, чтобы увидеть, что BIOS/UEFI сообщают об аппаратном обеспечении компьютера, включая память, используйте команду dmidecode:
Даже если всё тут выглядит нормально, на самом деле это может быть и не так. Дело в том, что данные SMBIOS не всегда точны. Поэтому, если после dmidecode память всё ещё остаётся под подозрением — пришло время воспользоваться Memtest86. Это отличная программа для проверки памяти, но работает она медленно. Если вы запустите её на сервере, не рассчитывайте на возможность использовать эту машину для чего-нибудь другого до завершения проверки.
Если вы сталкиваетесь со множеством проблем с памятью — я видел такое в местах, отличающихся нестабильным электропитанием — нужно загрузить модуль ядра Linux edac_core. Этот модуль постоянно проверяет память в поиске сбойных участков. Для того, чтобы загрузить этот модуль, воспользуйтесь такой командой:
Подождите какое-то время и посмотрите, удастся ли что-нибудь увидеть, выполнив такую команду:
Эта команда даст вам сводку о числе ошибок, разбитых по модулям памяти (показатели, название которых начинается с csrow ). Эти сведения, если сопоставить их с с данными dmidecode о каналах памяти, слотах и заводских номерах компонентов, помогут выявить сбойную планку памяти.
Шаг второй. Поиск истинного источника проблемы
Итак, сервер стал странно себя вести, но дым из него ещё пока не идёт. В сервере ли дело? Прежде чем вы попытаетесь решить возникшую проблему, сначала нужно точно определить её источник. Скажем, если пользователи жалуются на странности с серверным приложением, сначала проверьте, что причина проблемы — не в сбоях на клиенте.
Например, друг однажды рассказал мне, как его пользователи сообщили о том, что не могут работать с IBM Tivoli Storage Manager. Сначала, конечно, казалось, что виновен во всём сервер. Но в итоге администратор выяснил, что проблема вообще не была связана с серверной частью. Причиной был неудачный патч Windows-клиента 3076895. Но то, как сбоило это обновление безопасности, делало происходящее похожим на проблему серверной стороны.
Кроме того, нужно понять, является ли причиной проблемы сам сервер, или серверное приложение. Например, серверная программа может работать кое как, а железо оказывается в полном порядке.
Для начала — самое очевидное. Работает ли приложение? Есть множество способов проверить это. Вот два моих любимых:
Если оказалось, что, например, веб-сервер Apache не работает, запустить его можно такой командой:
Если в двух словах, то прежде чем диагностировать сервер и искать причину проблему, узнайте — сервер ли виноват, или что-то другое. Только тогда, когда вы поймёте, где именно находится источник сбоя, вы сможете задавать правильные вопросы и переходить к дальнейшему анализу того, что произошло.
Это можно сравнить с неожиданной остановкой автомобиля. Вы знаете, что машина дальше не едет, но, прежде чем тащить её в сервис, хорошо бы проверить, есть ли бензин в баке.
Шаг третий. Использование команды top
Шаг четвёртый. Проверка дискового пространства
Даже сегодня, когда в кармане можно носить терабайты информации, на сервере, совершенно незаметно, может кончиться дисковое пространство. Когда такое происходит — можно увидеть весьма странные вещи.
Разобраться с дисковым пространством нам поможет старая добрая команда df, имя которой является сокращением от «disk filesystem». С её помощью можно получить сводку по свободному и использованному месту на диске.
Обычно df используют двумя способами.
Если что-то кажется вам странным, можно копнуть глубже, воспользовавшись командой Iostat. Она является частью sysstat — продвинутого набора инструментов для мониторинга системы. Она выводит сведения о процессоре, а также данные о подсистеме ввода-вывода для блочных устройств хранения данных, для разделов и сетевых файловых систем.
Вероятно, самый полезный способ вызова этой команды выглядит так:
Такая команда выводит сведения об объёме прочитанных и записанных данных для устройства. Кроме того, она покажет среднее время операций ввода-вывода в миллисекундах. Чем больше это значение — тем вероятнее то, что накопитель перегружен запросами, или перед нами — аппаратная проблема. Что именно? Тут можно воспользоваться утилитой top для того, чтобы выяснить, нагружает ли сервер MySQL (или какая-нибудь ещё работающая на нём СУБД). Если подобных приложений найти не удалось, значит есть вероятность, что с диском что-то не так.
Работая с утилитами для проверки дисков, обращайте внимание, что именно вы анализируете.
Например, нагрузка в 100% на логический диск, который представляет собой несколько физических дисков, может означать лишь то, что система постоянно обрабатывает какие-то операции ввода-вывода. Значение имеет то, что именно происходит на физических дисках. Поэтому, если вы анализируете логический диск, помните, что дисковые утилиты не дадут полезной информации.
Шаг пятый. Проверка логов
Для новичков в Linux лог-файлы могут выглядеть как ужасная мешанина. Это — текстовые файлы, в которые записываются сведения о том, чем занимаются операционная система и приложения. Есть два вида записей. Одни записи — это то, что происходит в системе или в программе, например — каждая транзакция или перемещение данных. Вторые — сообщения об ошибках. В лог-файлах может содержаться и то, и другое. Эти файлы могут быть просто огромными.
Данные в файлах журналов обычно выглядят довольно таинственно, но вам всё равно придётся с ними разобраться. Вот, например, хорошее введение в эту тему от Digital Ocean.
Есть множество инструментов, которые помогут вам проверить логи. Например — dmesg. Эта утилита выводит сообщения ядра. Обычно их очень и очень много, поэтому используйте следующий простой сценарий командной строки для того, чтобы просмотреть 10 последних записей:
Вот ещё один удобный сценарий командной строки:
Он сканирует логи и показывает возможные проблемы.
Бывает полезно настроить journald так, чтобы он сохранял логи после перезагрузки системы. Сделать это можно, воспользовавшись такой командой:
Самый распространённый способ работать с этими журналами — такая команда:
Она покажет все записи журналов после последней перезагрузки. Если система была перезагружена, посмотреть, что было до этого, можно с помощью такой команды:
Мне, например, нравится система для управления логами с открытым кодом Graylog. Она собирает, индексирует и анализирует самые разные сведения. В её основе лежат MongoDB для работы с данными и Elasticsearch для поиска по лог-файлам. Graylog упрощает отслеживание состояния сервера. Graylog, если сравнить её со встроенными средствами Linux, проще и удобнее. Кроме того, среди её полезных возможностей можно отметить возможность работы с многими DevOps-системами, такими, как Chef, Puppet и Ansible.
Итоги
Как бы вы ни относились к вашему серверу, возможно, он не попадёт в Книгу Рекордов Гиннеса как тот, который проработал дольше всех. Но стремление сделать сервер как можно более стабильным, добираясь до сути неполадок и исправляя их — достойная цель. Надеемся, то, о чём мы сегодня рассказали, поможет вам достичь этой цели.
Уважаемые читатели! А как вы обычно поступаете с упавшими серверами?
Как разрешить (запретить) обычному пользователю перезагрузку (выключение) Windows?
В этой статье мы рассмотрим несколько способов, позволяющих управлять правами пользователей на перезагрузку и выключение компьютеров и серверов Windows. По умолчанию пользователи могут перезагружать и выключать только десктопные версии Windows, и не могут перезагрузить сервер (кнопки выключения и перезагрузки не доступны). Возможно ли разрешить пользователю без прав локального администратора перезагружать Windows Server? Возможна и обратная задача – запретить пользователям перезагружать компьютер с Windows 10, который используется в качестве некого информационного киоска, диспетчерского пульта и т.д.
Разрешить (запретить) пользователю перезагрузку Windows с помощью политики
Обратите, что по-умолчанию права на выключение/перезагрузку Windows различаются в десктопных версиях Windows 10 и в редакциях Windows Server.
Откройте редактор локальной политики gpedit.msc и перейдите в указанную выше секцию. Как вы видите, в Windows 10 права на перезагрузку (выключение) компьютера есть у членов локальных групп: Администраторы, Пользователи и Операторы архива.
В то время как в Windows Server 2012 R2 выключить или перезагрузить сервер могут только Администраторы или Backup Operators. Это правильно и логично, т.к. у пользователей в подавляющем большинстве случаев не должно быть прав на выключение сервера (даже случайное). Представьте себе RDS сервер, который периодически выключается из-за того, что пользователи случайно нажимают на кнопку выключения в стартовом меню…
Но из всякого правила бывают исключения. Соответственно, если вы хотите разрешить определенному пользователю (без права администратора) перезагружать ваш Windows Server, достаточно добавить его учетную запись в эту политику.
Или наоборот, вы хотите запретить пользователям десктопной редакции Windows 10 перезагружать компьютер, который выполняет некую серверную функцию. В этом случае вам достаточно удалить группу Users из локальной политики “Завершение работы системы”.
Аналогичным образом вы можете запретить (или разрешить) выключение или перезагрузку компьютеров для всех компьютеров в определённом OU домена Active Directory с помощью доменной политики. С помощью редактора доменных GPO (gpmc.msc) создайте новую политику Prevent_Shutdown, настройте параметр политики “Shut down the system” в соответствии с вашими требованиями и назначьте политику на OU с компьютерами или серверами.
Право на удаленное выключение/перезагрузку Windows
Вы также можете разрешить определенным пользователям перезагружать ваш Windows Server удаленно с помощью команды shutdown, не предоставляя пользователю права локального администратора и право на RDP вход на сервер.
Для этого необходимо добавить учетную запись нужного пользователя в политику “Принудительное удаленное завершение работы” (Force shutdown from a remote system) в той же самой секции GPO Назначение прав пользователя (User Rights Assignment).
По умолчанию выключить сервер удаленном могут только администарторы. Добавьте в политику нужную учетную запись пользователя.
В результате пользователю будет назначена привилегия SeRemoteShutdown и он сможет перезагрузить данный сервер удаленно с помощью команды:
Скрыть от пользователя Windows кнопки выключения и перезагрузки
После включения этой политики пользователь сможет завершить работу с Windows, только выполнив логофф. Кнопки выключения, сна и перезагрузки компьютера станут недоступными.
Как узнать, кто перезагрузил (выключил) Windows сервер?
После того, как вы представили определенному пользователю права на перезагрузку серверов вы, вероятно, захотите узнать кто перезагружал определенный сервер: пользователь или один из администраторов.
Как вы видите, в журнале событий остались события перезагрузки сервера в хронологическом порядке. В описании события указано время перезагрузки, причина и учетная запись, которая выполнила рестарт.
Log Name:System
Source: User32
EventID: 1074
The process C:\Windows\system32\winlogon.exe (MSK-RDS1) has initiated the restart of computer MSK-RDS1 on behalf of user CORP\AAIvanov for the following reason: No title for this reason could be found.
Reason Code: 0x500ff
Shutdown Type: restart
Comment:
Аналогичным образом можно получить информацию о последних событиях перезагрузки Windows. Для этого нужно искать по событию с кодом 1076.
Как узнать кто перезагрузил сервер
Этот форум закрыт. Спасибо за участие!
Лучший отвечающий
Вопрос
Имеется сервер Supermicro. Работал пол года нормально и тут в недавнее время стал сам перегружается без ведомых причин. При просмотре журнала проблем обнаружено не было. В чем может быть проблема и как ее выявить?
Windows 2008 R2 Standart SP1
RAID контроллер Adaptec
Роли: Файловый сервер. служба печати
Антивирус не установлен (скрыт за фаерволом)
У сервера 2 блока питания
В стойке стоит такой же конфигурации сервер куплен в одно время работает нормально.
Ответы
Все ответы
Со вторый серваком на базе интел были аналогичные проблемы. win 2003 std eng- решилось накатыванием апдейтов. (я это делаю раз в год)
Еще был сервак, тож на интеле. win 2003 std rus. Падал когда хотел. Решилось переустановкой винды
Это точно, что в журнале событий нет никаких сообщений о перезагрузках? Регистрируется ли после перезагрузки событие 6008, что «the previous system shutdown was unexpected»?