SS14.Watchdog обнаруживает, что ваш сервер завис, он завершит его и перезапустит. Если это происходит по-настоящему на живом сервере, шанс просто посмотреть логи упущен. Это руководство даст краткое введение в то, как подойти к отладке такого рода проблем.
Чтобы было ясно: вы можете получить похожую ошибку, если игровой сервер не может связаться с watchdog из-за неправильной конфигурации, и в этом случае игровой сервер будет надёжно завершаться после запуска по кругу. Эта статья не об этом, а о настоящей, реально серьёзной ошибке-зависании.
Предыстория: Ping’и Watchdog
Watchdog ожидает, что игровой сервер будет отправлять ему регулярные ping-сообщения, указывающие на то, что игровой сервер всё ещё жив. Игровой сервер отправляет эти ping’и с регулярным интервалом в 15 секунд (в настоящее время не настраивается, о чём я думал?), и watchdog ожидает хотя бы один ping каждыеTimeoutSeconds в конфигурации экземпляра. Если игра застрянет в бесконечном цикле какого-либо рода, она перестанет отправлять эти ping’и, и watchdog быстро завершит её и перезапустит.
Итак, что у нас есть?
Если вы хотите легко спровоцировать это, подключитесь к вашему серверу и выполните что-то вроде этого вscsi:
Если вы вообще читаете эту страницу, я надеюсь, у вас достаточно опыта хостинга серверов, чтобы знать об этом, но просто для ясности: эти два сообщения
[WARN] — не проблема.TimeoutDumpType в конфигурации экземпляра watchdog на одно из этих значений. Предупреждаем: дампы ядра довольно большие, и запись большего объёма информации может сделать их чрезвычайно большими.
Дампы ядра могут содержать конфиденциальную информацию с вашего сервера (например, пароли базы данных) и не должны передаваться людям, которым вы не доверяете!
Использование lldb
lldb — это приличный2 отладчик для Linux и macOS. Установите его:lldb для обычной нативной отладки нативных модулей и всего прочего. Хотя это всё ещё не для слабонервных и может потребовать дополнительной настройки, например, для получения символов нативных библиотек.
Чтобы получить некоторую значимую информацию из управляемого стека вызовов, мы можем выполнить команду clrstack из SOS:
Submission#0, что является внутренней деталью C# Interactive, в котором мы выполнили while (true) { }. Хотя я не могу показать вам байт-код IL или C#-код в lldb (ну, я уверен, что первое возможно с SOS), я могу показать вам ассемблерный код, который выглядит как довольно простой бесконечный цикл:
Использование WinDBG
WinDBG — это отладчик для Windows, который достают, когда всё остальное не помогло (а здесь именно так). Вы можете получить WinDBG Preview из Microsoft Store. Вам также понадобится SOS. Он расширит WinDBG, чтобы сделать возможной отладку .NET-трассировки:
.load, упомянутую в выводе выше, чтобы загрузить SOS:
!clrstack для отображения управляемого стека вызовов:
🤫 Я на самом деле использовал
dotnet dump collect для получения дампа Windows, потому что мне было лень настраивать watchdog дважды ради этой статьи. Работает так же, в основном. Чёрт, я почти уверен, что он использует ту же базовую библиотеку для создания дампа, что и watchdog!Footnotes
-
Я пытался открыть дамп ядра Linux в WinDBG, который до некоторой степени поддерживается… но он жаловался на недостающее количество файлов и другие проблемы, так что я сдался. Попробуйте переместить папку вашего watchdog
bin/в сторону и отлаживать дамп ядра с помощью lldb… Да, результаты будут совершенно разными, не так ли? ↩ - Настолько хорош, насколько может быть инструментарий разработки на Linux, то есть не очень хорошо. ↩