Различия

Здесь показаны различия между двумя версиями данной страницы.

--- wiki:как_писать_баг_репорт [2010/01/09 02:25]
+++ wiki:как_писать_баг_репорт [2016/05/20 15:27] (текущий)
переиндексация тегов
@@ Строка 1: / Строка 1: @@
 ====== Как писать баг репорт или давайте соберём грамотный анамнез ======
-На форуме, куда вы обращаетесь за помощью сидят люди, которые часто искренне хотят Вам помочь :-) И чтобы не огорчать их фразами "у меня ничего не работает!" давайте грамотно и профессионально опишем проблему! Тогда, как максимум, возможно вы сами уведите, где ошибка. Ну или, как минимум, вы можете рассчитывать на вежливый ответ.
+На форуме, куда вы обращаетесь за помощью сидят люди, которые часто искренне хотят Вам помочь :-) И чтобы не огорчать их фразами "у меня ничего не работает!" давайте грамотно и профессионально опишем проблему! Тогда, как максимум, возможно вы сами увидите, где ошибка. Ну или, как минимум, вы можете рассчитывать на вежливый ответ.
 ===== Сеть =====
-Тема общая... поэтом у и рекомендации общие
+Тема общая... поэтому и рекомендации общие
-. Описать структуры сети. Например, "у меня 3 компьютера ОС "такая-то", главный получает интернет от провайдера по VPN|PPPOE|NAT|ещё что-н, с главного интернет раздаётся через NAT|(проски-сервер), файрволы стоят в режиме всё пропускать" или "у меня 2 компа ОС "такая-то" и роутер марка такая-то" и далее
+. Описать структуры сети. Например, "у меня 3 компьютера, ОС "такая-то", главный получает интернет от провайдера по VPN|PPPOE|NAT|ещё что-нибудь, с главного интернет раздаётся через NAT|(прокси-сервер), файрволы стоят в режиме всё пропускать" или "у меня 2 компа, ОС "такая-то" и роутер марка такая-то" и далее...
-. Выводы команд ifconfig, route, cat /etc/resolv.conf, sudo iptables -L. Также стоит попытаться провести пингование подобное пункту 2 раздела, посвящённого Samba.
+. Выводы команд ifconfig, route, cat /etc/resolv.conf, sudo iptables -L. Также стоит попытаться провести проверку соединения утилитой ping подобную пункту 2 раздела, посвящённого Samba.
 Файлы с настройками (если больше 5 строк) следует очистить от паролей и важных для вас адресов и приложить к сообщению вложением.
 ===== Проблемы с Samba. Расшаривание файлов по сети =====
-. берём конфигурационный файл samba
+. Тест конфигурационного файла Samba.
 Выполните команду "testparm" и сохраните вывод этой команды.
@@ Строка 17: / Строка 18: @@
 Эта команда диагностирует файл /etc/samba/smb.conf на синтаксические ошибки, а также, что более важно, показывает как видит samba файл с настройками.
-. пингуем машины в сети
+. Проверяем соединение компьютеров в сети с помощью утилиты ping.
-Попытайтесь выполнить следующие комбинации пингования
+Попытайтесь выполнить следующие проверки:
-.1 ping server (c машины client)
+.1 ping server (c компьютера client)
-.2 ping client (c машины client)
+.2 ping client (c компьютера client)
-.3 ping ip_адрес_server (c машины client)
+.3 ping ip_адрес_server (c компьютера client)
-.4 ping ip_адрес_client (c машины client)
+.4 ping ip_адрес_client (c компьютера client)
-Где server - имя машины, где установлена samba, a ip_адрес_server - ip адрес этой машины. Для client аналогично ;)
+Где server - имя компьютера, где установлена Samba, a ip_адрес_server - ip адрес этого компьютера. Для client проверка проводится аналогично.
-. пытаемся залогинется на сервер разными способами :)
+. Проверка доступа к ресурсам сервера.
-.1 с машины server выполним smbclient -L \\server
+.1 С компьютера server выполним smbclient -L \\server
-.2 с машины client выполним smbclient -L \\server
+.2 С компьютера client выполним smbclient -L \\server
-.3 с машины client выполним smbclient -L \\ip_адрес_server
+.3 С компьютера client выполним smbclient -L \\ip_адрес_server
 Аккуратно записываем результаты тестов и [[http://forum.ubuntu.ru/index.php?action=post;board=27.0|на форум в раздел сети]]!
-===== Железо. Переферия =====
+===== Железо. Периферия =====
-Проблемы с железом... когда-то бич линукс систем. И судя по тому, что вы читаете этот раздел, то не повезло и вам. Печально. И так возможно не всё потеряно, что нам будет надо
+Проблемы с железом... когда-то бич линукс систем. И судя по тому, что вы читаете этот раздел, то не повезло и вам. Печально. И так возможно не всё потеряно, что нам потребуется:
-. Какая используется версия ядра (именно в нём находятся все драйвера), вывод команды uname -a
+. Версия ядра (именно в нём находятся все драйвера) — вывод команды uname -a.
-. Если устройство usb Вывод консольной команды lsusb и dmesg | tail после подключения устройства
+. Если устройство usb — вывод консольной команды lsusb и dmesg | tail после подключения устройства
-Если устройство pci, то вывод lspci
+Если устройство pci — вывод lspci
@@ Строка 62: / Строка 63: @@
+===== Программа перестала работать =====
+. Запускаем программу из терминала и ищем сообщения об ошибках.
+. Часто проблемы бывают скрыты в настройках, которые мы сделали. Найдите директорию с настройками в своей домашней папке и переименуйте её. При следующем запуске будет создана новая директория с настройками по умолчанию.
+===== Копаемся в системных журналах =====
+==== Что такое системные журналы ====
+У всех у нас есть на компьютере замечательная папка  /var/log  в которой размещены различные системные журналы. Большая часть приложений серверного уровня (таких как  apache, samba  и т.д.) и многие пользовательские приложения регулярно сбрасывают отчеты о своей активности в соответствующие log-файлы. Помимо этого, там же можно найти отчеты о работе различного оборудования и системы в целом. Основной файл называется syslog, и имеет полный путь  /var/log/syslog.\\
+Для просмотра системных журналов можно использовать встроенное в Ubuntu приложение, //Система -> Администрирование -> Программа просмотра журналов//, или воспользоваться командой((через CLI или терминал)):
+<code>
+sudo tail /var/log/[имя_log_файла]
+</code>
+Например, для просмотра файла авторизаций  auth.log:
+<code>
+sudo tail /var/log/auth.log
+</code>
+Команда  tail  выводит на экран последние 10 строк файла. Более подробно про нее см.:
+<code>
+man tail
+</code>
+По сути - log файлы - это обычные текстовые файлы, и смотреть их, соответственно, можно любым удобным текстовым редактором. Однако, стоит заметить, что файлы журналов часто бывают достаточно большие по объему и по числу строк, а большинство текстовых редакторов открывают файл с начала, а не с конца, поэтому и удобно пользоваться утилитой  tail. Если вы примерно представляете себе, что именно вы ищете - вы можете выполнить поиск по словам, например, для уже упомянутого  auth.log  - поиск авторизаций пользователей через команду  sudo  :
+<code>
+sudo cat /var/log/auth.log | grep sudo
+</code>
+==== Поиск неисправностей при помощи журналов ====
+Как уже было сказано, большая часть программ комментирует свою работу в системных журналах. При этом, наибольшее значение, как правило, уделяется именно сообщениям об ошибках в работе. Поэтому, если вдруг вы столкнулись с необъяснимыми на первый взгляд проблемами (например, у вас перестала запускаться графическая подсистема X11) - вы можете изучить соответствующие log-файлы((в данном примере, скорее всего это будет файл Xorg.0.log)). Сложно посоветовать заранее необходимый вам log-файл, но из контекста неисправности зачастую понятно, в какую сторону нужно копать. Однозначно можно сказать, что большая часть различных ошибок, помимо специфичных log-файлов попадает в /var/log/syslog, так что выполнение:
+<code>
+sudo tail /var/log/syslog
+</code>
+сразу после проявления неполадки скорее всего даст вам необходимые данные об ошибке.\\
+После того, как вы найдете подозрительное сообщение, можете смело копировать его текст в Google, и, скорее всего, вы тут же найдете описание своей проблемы и возможные методы решения.
+===== Если система зависает =====
+Если ваша система произвольно зависает, и анализ log-файлов не позволяет выяснить, в чем проблема, вы можете попробовать следующий способ. Откройте терминал и выполните:
+<code>
+top -b > ~/my.log
+</code>
+После чего **не закрывайте терминал** и продолжайте работать до зависания системы. После перезагрузки откройте файл my.log в своей домашней папке - выглядеть он будет примерно так((тут приводится пример с нормальной, не зависшей системы)):
+<file>
+top - 10:46:54 up 17:36,  1 user,  load average: 0.00, 0.00, 0.00
+Tasks:  59 total,   1 running,  58 sleeping,   0 stopped,   0 zombie
+Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
+Mem:    504108k total,    46616k used,   457492k free,     2588k buffers
+Swap:   999032k total,        0k used,   999032k free,    14860k cached
+  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
+root      20   0 19300 1552 1132 S  0.0  0.3   0:00.16 init
+root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd
+root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0
+................................
+</file>
+Верхний процесс в списке процессов (в данном примере - init) - затребовал больше всех ресурсов непосредственно перед тем, как система зависла. В зависимости от того, что это был за процесс вы можете спланировать процесс дальнейшей отладки системы.
+{{tag>Tips Можно_улучшить}}

Как писать баг репорт или давайте соберём грамотный анамнез Сравнение версий

Различия