Что такое дебаг логи
Файл debug.log в папках, на рабочем столе – что это такое, причины появления
В процессе работы за компьютером могут возникать различные ситуации, проблемы и прочие не совсем понятные и объяснимые вещи. И одной из таких проблем может являться появление файла под именем debug.log, который может быть пустым, и, соответственно, файл имеет размер в 0 байт, а может содержать не сильно понятные строки с текстом.
Давайте разберёмся, какова причина этого явления и как с ней справиться.
Спонтанное появление файла debug.log в различных папках
Дабы понять, что происходит, для начала стоит рассказать о предназначении данного файла. В данный файл прописывается различная отладочная информация, события, которые могут возникать в процессе работы программы. Данный функционал необходим программистам при разработке софта, его отладки (доведения до полностью безошибочной работы в тех или иных сценариях). Для обычных пользователей данная информация не несёт никакой пользы, она является избыточной. Так почему же тогда порой данные файлы всё равно можно наблюдать? Ответ прост – программисты порой забывают отключить данный функционал при релизе программы, или при выходе её очередного обновления.
Причём изредка данные файлы создаются не из-за действий самих разработчиков, а из-за действий третьих лиц, которые включают режим отладки при создании так называемых сборок. Под сборками подразумеваются неофициальные дистрибутивы программных продуктов, игр.
К примеру, не так давно данная проблема была замечена у весьма серьёзного и довольно популярного программного продукта – графического редактора Adobe Photoshop. При его использовании создаётся файл debug.log в тех папках, откуда берутся изображения и куда сохраняются.
Так как же исправить проблему с появлением файла debug.log. Об этом далее.
Исправить данную проблему достаточно легко – просто установить обновление данного программного обеспечения, где оная проблема устранена. Если на текущий момент более новая версия программы отсутствует, то можно установить предыдущую версию программы.
В конце концов, можно и немного подождать, благо сам софт же функционирует корректно и в полном объёме. А появляющийся файл debug.log можно удалить, ни к какому сбою это не приведёт. Единственное, необходимо отметить, что пока работает программа, которая его создала, оный файл удалить не получится, необходимо предварительно закрыть оную.
Ну вот, теперь вы знаете, что за файл такой под именем debug.log, почему он появляется на компьютере и как можно исправить ситуацию.
В свою очередь, Вы тоже можете нам очень помочь.
Просто поделитесь статьей в социальных сетях и мессенджерах с друзьями.
Поделившись результатами труда автора, вы окажете неоценимую помощь как ему самому, так и сайту в целом. Спасибо!
Что за файл debug.log и можно ли удалить его в WordPress
Приветствую, посетитель!
Важный нюанс: если вы сталкивайтесь с файлом под именем debug.log на компьютере, то в материале «Файл debug.log в папках, на рабочем столе – что это такое, причины появления» вы узнаете, почему так происходит и как это исправить.
А теперь давайте вернёмся к WordPress. При детальном изучении файлов WordPress сайта, что располагается хостинге, вы можете встретить файл под именем debug.log, который обычно располагается в поддиректории под названием …/wp-content/ Этот файл накапливает в себе информацию об ошибках при работе вашего сайта.
Эти ошибки могут быть как критичными, так и фактически не влияющие на работу сайта. И если на вашем сайте наблюдаются серьёзные проблемы, то информация из данного файла может оказаться полезной для решения возникших трудностей.
Если же говорить о его важности для функционирования WordPress сайта, то его наличие или отсутствие не оказывается какого-либо влияния. Это второстепенный текстовый файл (лог файл), который создаётся, если в конфигурационном файле WordPress включён режим отладки.
Негативная сторона присутствия данного файла может заключаться в том, что если ошибок много и соответственно записей о них в debug.log, то размер данного файла в конечном итоге будет весома существенным. И тогда может возникнуть банальное желание данный файл удалить.
Вы можете отключить режим отладки, а сам файл удалить и это никак не повлияет на стабильность и\или скорость сайта.
И если размещённая в данном файле информация вам ни о чём не говорит, то даже рекомендуется это сделать. Осуществить сие очень просто, необходимо отредактировать всего лишь одну строчку с параметром в конфигурационном файле WordPress (именуется wp-config.php). Информацию об этом вы можете прочесть в статье, ссылка на которую приведена чуть выше.
Более того, режим отладки по умолчанию у WordPress выключен. Этот режим мог быть включён технической поддержкой хостинга, дабы понять, проблема на их стороне с серверным оборудованием, или это что-то с вашим сайтом. Также этот режим мог включить Веб-мастер (технический специалист), которому вы доверили внедрение нового функционала, решение проблем и ошибок с вашим сайтом.
Напоследок хочу пожелать беспроблемной работы вашему WordPress сайту, а также развития в творческом и техническом плане. В последнем случае вам в этом окажет посильную информационную поддержку ресурс WPuse.ru
Следите за новыми материалами! До скорой встречи!
990x.top
Простой компьютерный блог для души)
debug.log — что это такое?
Текстовый файл, представляющий из себя служебную информацию о успешных/ошибочных операциях программы. Необходим для поиска причин сбоя/зависания приложения. Носит информативный характер, может помочь при ошибке ПО (например вылеты).
Может быть создан разными программами.
debug.log на рабочем столе может создаваться графическим редактором Photoshop при открытии файлов форматов JPEG, PNG, PSD или других. Кроме рабочего стола, файл может появляться также и в папке открываемого проекта. При попытке удалить — будет сообщение ошибки:
Удалить debug.log можно только после закрытия программы Photoshop. Способ открытия Фотошоп без появления данного файла: необходимо нажать по ярлыку Фотошоп, выбрать пункт открыть расположение, после откроется папка с выделенным файлом, который необходимо запустить. Тогда debug.log будет создан в папке с выделенным файлом. На рабочем столе уже не появится. Важно: вероятнее всего полностью исправить данную проблему можно путем установки последней актуальной версии Adobe Photoshop.
Обычно данные файлы — скрыты, находятся в папках, где установлены программы. На рабочем столе быть не должно, как в ситуации с Photoshop.
Пример содержимого debug.log, который создает Фотошоп:
Никакой опасности данный debug.log не несет и носит только информационно-служебный характер.
Надеюсь данная информация оказалась полезной. Удачи.
Архитектура логирования
Мой опыт разработки в основном строится вокруг разнообразных сетевых cервисов под Windows и Linux. Я обычно стремлюсь добиться максимальной кроссплатформенности вплоть до бинарной совместимости. И конечно, накопилось некоторое количество стабильных решений связанных с логированием.
Топик написан как продолжение к этой статье и будет полезен в первую очередь начинающим программистам.
Итак, начну со своих дополнений к предыдущей статье.
Я как и автор пользуюсь NLog’ом и разумеется широко использую его особенности. Конечно, после
их реализации в любом другом логгере, нижеописанную практику можно применять и у них.
Кстати, log4net продолжает развиваться.
Под капотом NLog
Сразу обсудим полезность второй фичи.
Часто, при разработке кода, возникает необходимость посмотреть значение какой либо переменной в процессе выполнения. Обычно, используют дебаггер и останавливают программу в интересующем месте. Для меня же, это явный признак, что этом месте будет полезен Trace вывод. В комплекте с юнит-тестами мы сразу получаем развертку этой переменной во времени и протокол для сравнения с тестами в других условиях. Таким образом, дебаггером я практически не пользуюсь.
Очевидно, что в боевом применении, даже выключенное подробное логирование, может мешать как скорости выполнения так и параллельности.
Исходный код класса можно посмотреть тут.
Отлично! Для NLog можно быть уверенным, что ваши сколь угодно детальные сообщения могут быть отключены и это минимально скажется на производительности. Но, это не повод посвящать логированию половину кода.
Что и как логировать
Следует придерживаться правил:
В целом, при выводе в лог, всегда отмечайте, то количество потенциально лишних вычислений, которые потребуются для случая когда лог отключен.
Простой пример (фрагмент некоторого класса):
private static Logger Log = LogManager. GetCurrentClassLogger ( ) ;
public string Request ( string cmd, string getParams )
Uri uri = new Uri ( _baseUri, cmd + «?» + getParams ) ;
HttpWebRequest webReq = ( HttpWebRequest ) WebRequest. Create ( uri ) ;
webReq. Method = «GET» ;
webReq. Timeout = _to ;
using ( WebResponse resp = webReq. GetResponse ( ) )
using ( Stream respS = resp. GetResponseStream ( ) )
using ( StreamReader sr = new StreamReader ( respS ) )
page = sr. ReadToEnd ( ) ;
catch ( Exception err )
Все аргументы логирования требовались для логики. Сообщение Debug отмечает аргументы с которыми мы пришли в функцию. В обработчике ошибки мы дублируем входные параметры на случай отключения Debug уровня. А это уже даст информацию при необходимости написать юнит-тест. Стек исключения не выводим, так как остается возможность сделать это вышестоящим обработчиком.
Вообще, в текущем обработчике ошибок полезно детализировать контекст который к привел к исключению и специфичные особенности исключения. В примере было бы полезно вывести поле Status для случая WebException.
Гарантии сохранности лога
Несмотря на некоторые возможности NLog по авто записи логов, нет гарантии сохранности лога при завершении процесса.
Первое, что следует сделать, это обработать событие AppDomain.UnhandledException. В нем следует записать в лог полную информацию об ошибке и вызвать LogManager.Flush(). Обработчик этого события использует тот же поток, который и вызвал исключение, а по окончании, немедленно выгружает приложение.
private static readonly Logger Log = LogManager. GetCurrentClassLogger ( ) ;
public static void Main ( string [ ] args )
static void OnUnhandledException ( object sender, UnhandledExceptionEventArgs e )
Кроме того, следует вызывать LogManager.Flush() везде, где потенциально возможно завершение процесса. В конце всех не фоновых потоков.
Если ваше приложение представляет собой win-service или Asp.Net, то следует обработать соответствующие события начала и завершения кода.
Сколько логировать
Серьезная проблема для разработчика. Всегда хочется получать больше информации, но код начинает выглядеть очень плохо. Я руководствуюсь следующими соображениями.
Вывод в лог это по сути комментарий. Логирование уровня Trace по большей части их и заменяет.
Уровни Trace и Debug читают разработчики, а все что выше — техподдержка и админы. Поэтому до уровня Info сообщения должны точно отвечать на вопросы: «Что произошло?», «Почему?» и по возможности «Как исправить?». Особенно это касается ошибок в файлах конфигурации.
Боевое развертывание
Предположим, разработка дошла до внедрения.
Отложим вопросы ротации логов, размера файлов и глубины истории. Это все очень специфично для каждого проекта и настраивается в зависимости от реальной работы сервиса.
Остановлюсь только на смысловой организации файлов. Их следует разделить на 3 группы. Может потребуется развести логи модулей в разные файлы, но дальше я все равно буду говорить об одном файле для каждой группы.
Если приложение успешно внедрено, то в работе остаются только первые две группы.
Расследование сбоев
Когда работающий сервис подает признаки ошибки, то не следует его пытаться сразу перезагружать. Возможно нам «повезло» поймать ошибки связанные с неверной синхронизацией потоков. И не известно сколько в следующий раз ждать ее повторения.
В первую очередь следует подключить заготовленные заранее конфиги для группы наблюдения. Как раз это и должен позволять делать приличный логгер. Когда мы получили подтверждение о том, что новая конфигурация успешно применена, то пытаемся опять спровоцировать сбой. Желательно несколько раз. Это обеспечит возможность для его воспроизведения в «лабораторных» условиях. Дальше уже работа программистов. А пока можно и перезагрузиться.
name = «fileInfo» type = «AsyncWrapper» queueLimit = «5000» overflowAction = «Block» >
type = «File» fileName = «$
name = «fileWarn» type = «AsyncWrapper» queueLimit = «5000» overflowAction = «Block» >
type = «File» fileName = «$
name = «*» minlevel = «Info» writeTo = «fileInfo» />
name = «*» minlevel = «Warn» writeTo = «fileWarn» />
При настройке фильтров следует учитывать относительность уровней логирования для каждой из подсистем. Например, некоторый модуль, имея Info сообщение об инициализации, может быть создан для каждого подключенного пользователя. Разумеется, его вывод в Info группу следует ограничить уровнем Warn.
Чего с логгером делать не следует
Логгер должен быть простым и надежным как молоток. И у него должна быть четко очерчена область применения в конкретном проекте. К сожалению, разработчиков часто трудно удержать. Паттерны проектирования, это в основном полезно, но не этом случае. Достаточно часто стал замечать предложения выделить для логгера обобщенный интерфейс (пример) или реализовать обертку в проекте, чтобы отложить муки выбора NLog vs log4net на потом.
Что бы ни было тому причиной, надо точно помнить, что в первую очередь, такие удобства напрочь убивают компилятору возможность оптимизации.
Не стоит напрямую выводить информацию логгера пользователю, даже с фильтрами. Проблема в том, что эта информация зависит от внутренней структуры программы. Вряд ли вы в процессе рефакторинга пытаетесь сохранить вывод логгера. Наверное, здесь стоит просто задуматься и разделить функционал. Возможно, в проекте просто требуется еще один уровень логирования. В этом случае как раз и уместна будет обертка над логгером.
Чего же мне еще не хватает в NLog?
NLog, Log4Net, Enterprise Library, SmartInspect.
Разнообразные сравнения логгеров между собой, упускают одну важную деталь.
Важно сравнивать не только ограничения/возможности, но и возможность быстро добавить свои «хотелки».
Поэтому, буду пока дружить с NLog.
Чего и Вам желаю.
Почему на моем компьютере есть файл отладки и как его исправить?
Файл отладки (debug.log или debug.txt) на рабочем столе вашей системы может появиться в основном из-за ошибки в браузерах на основе хрома. Более того, поврежденный профиль пользователя или установка браузера также могут привести к появлению файла отладки на рабочем столе вашей системы.
Проблема возникает, когда пользователь видит файл отладки на своем рабочем столе. Когда файл отладки открывается с помощью Блокнота, отображается что-то вроде ниже:
[1101/180331.337:ERROR:directory_reader_win.cc(43)] FindFirstFile: система не может найти указанный путь. (0x3)
Прежде чем приступить к процессу устранения неполадок, убедитесь, что на вашем компьютере установлена последняя сборка Windows. Кроме того, проверьте, решает ли проблему очистка временных файлов. Также проверьте, используете ли вы Google Talk (хотя поддержка прекращена с 2015 года, но некоторые пользователи все еще используют его). Если да, то попробуйте восстановить его установку через Панель управления вашей системы.
Решение 1. Удалите файл отладки
Первым шагом в процессе устранения этой проблемы является удаление самого ненужного файла отладки (файл может быть воссоздан после запуска системы / приложения). Возможно, вам придется повторять эти шаги после каждой попытки решения.
Решение 2. Обновите свой браузер до последней сборки
Почти все основные браузеры регулярно обновляются, чтобы учитывать новейшие функции и исправлять ошибки. Ваша система может отображать файл отладки на рабочем столе, если вы используете устаревшую версию своего браузера, поскольку это может создать несовместимость между браузером и ОС и, следовательно, создать файл отладки на рабочем столе для устранения неполадок. В этом случае обновление браузера до последней сборки может решить проблему.
Для Chrome:
Для браузера Edge
После обновления браузеров (на основе Chromium) перезагрузите компьютер и при перезагрузке проверьте, не содержит ли система отладочного файла.
Решение 3. Откройте файлы PDF в другом браузере / приложении
Создание файла отладки — это ошибка, о которой сообщается в браузерах на основе Chromium, особенно когда браузер используется для загрузки / открытия файлов PDF. В этом контексте открытие файлов PDF в браузере, не основанном на Chromium (например, Firefox или Safari) или другом приложении, может решить проблему.
Решение 4. Отключите инструменты разработчика Microsoft Edge.
Вы можете столкнуться с данной ошибкой, если включены инструменты разработчика браузера Microsoft Edge, так как его возможность редактировать рабочие процессы интерфейса может вызвать конфликт между приложением и ОС. В этом контексте отключение инструментов разработчика Microsoft Edge может решить проблему.
Решение 5. Удалите файл отладки из папки запуска
Ваша система может отображать файл отладки на своем рабочем столе, если файл отладки находится в папке запуска (из-за чего файл будет воссоздаваться при каждом перезапуске системы). В этом случае удаление файла из папки автозагрузки может решить проблему.
Решение 6. Удалите папку Crashpad.
Файл отладки на рабочем столе вашей системы может отображаться, если папка Crashpad, связанная с Chrome, повреждена. В этом контексте удаление папки Crashpad может решить проблему.
Решение 7. Чистая загрузка Windows
Ваша система может отображать файл отладки на своем рабочем столе, если какое-либо из системных приложений создает файл при запуске системы. В этом контексте чистая загрузка системы может решить проблему.
Решение 8. Удалите новое обновление Microsoft Edge.
Известно, что Microsoft выпускает обновления с ошибками, и одним из таких обновлений является KB4576754 (последнее обновление Microsoft Edge). В этом случае проблему может решить удаление обновления, содержащего ошибки.
Решение 9. Переустановите браузер
Вы можете столкнуться с данной ошибкой, если установка вашего браузера повреждена. В этом случае переустановка браузера может решить проблему. Вам следует попытаться переустановить Microsoft Edge и браузер Chrome (мы обсудим процесс переустановки Chrome), поскольку проблема возникает в браузерах на основе Chromium (вам также следует переустановить все браузеры на основе хрома).
Решение 10. Создайте другую учетную запись пользователя
Вы можете столкнуться с данной ошибкой, если профиль пользователя вашей системы поврежден. В этом контексте создание другой учетной записи пользователя может решить проблему.
Решение 11. Скройте файл и сделайте его доступным только для чтения
Если ни одно из решений не помогло решить проблему, то сокрытие файла (чтобы вас не беспокоило существование файла) и его доступность для чтения (приложение, создающее файл, не сможет его редактировать или воссоздавать) может решить проблема.