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

Различия

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

Ссылка на это сравнение

Следующая версия
Предыдущая версия
Последняя версия Следующая версия справа и слева
wiki:как_писать_баг_репорт [2010/01/09 02:01]
создано
wiki:как_писать_баг_репорт [2010/04/16 17:09]
Строка 1: Строка 1:
 ====== Как писать баг репорт или давайте соберём грамотный анамнез ====== ====== Как писать баг репорт или давайте соберём грамотный анамнез ======
-На форуме,​ куда вы обращаетесь за помощью сидят люди, которые часто искренне хотят Вам помочь :-) И чтобы не огорчать их фразами "у меня ничего не работает!"​ давайте грамотно и профессионально опишем проблему! Тогда, как максимум,​ возможно вы сами уведите, где ошибка. Ну или, как минимум,​ вы можете рассчитывать на вежливый ответ.+На форуме,​ куда вы обращаетесь за помощью сидят люди, которые часто искренне хотят Вам помочь :-) И чтобы не огорчать их фразами "у меня ничего не работает!"​ давайте грамотно и профессионально опишем проблему! Тогда, как максимум,​ возможно вы сами увидите, где ошибка. Ну или, как минимум,​ вы можете рассчитывать на вежливый ответ. 
 + 
 +===== Сеть ===== 
 +Тема общая... поэтому и рекомендации общие 
 + 
 +1. Описать структуры сети. Например,​ "у меня 3 компьютера,​ ОС "​такая-то",​ главный получает интернет от провайдера по VPN|PPPOE|NAT|ещё что-нибудь,​ с главного интернет раздаётся через NAT|(прокси-сервер),​ файрволы стоят в режиме всё пропускать"​ или "у меня 2 компа, ОС "​такая-то"​ и роутер марка такая-то"​ и далее... 
 + 
 +2. Выводы команд ifconfig, route, cat /​etc/​resolv.conf,​ sudo iptables -L. Также стоит попытаться провести проверку соединения утилитой ping подобную пункту 2 раздела,​ посвящённого Samba. 
 + 
 +Файлы с настройками (если больше 5 строк) следует очистить от паролей и важных для вас адресов и приложить к сообщению вложением. 
 ===== Проблемы с Samba. Расшаривание файлов по сети ===== ===== Проблемы с Samba. Расшаривание файлов по сети =====
-1. берём ​конфигурационный файл ​samba+1. Тест конфигурационного ​файла Samba.
  
 Выполните команду "​testparm"​ и сохраните вывод этой команды. ​ Выполните команду "​testparm"​ и сохраните вывод этой команды. ​
Строка 8: Строка 18:
 Эта команда диагностирует файл /​etc/​samba/​smb.conf на синтаксические ошибки,​ а также, что более важно, показывает как видит samba файл с настройками. Эта команда диагностирует файл /​etc/​samba/​smb.conf на синтаксические ошибки,​ а также, что более важно, показывает как видит samba файл с настройками.
  
-2. пингуем машины в сети+2. Проверяем соединение компьютеров ​в сети ​с помощью утилиты ping.
  
-Попытайтесь выполнить следующие ​комбинации ​пингования+Попытайтесь выполнить следующие проверки:
  
-2.1 ping server (c машины ​client)+2.1 ping server (c компьютера client)
  
-2.2 ping client (c машины ​client)+2.2 ping client (c компьютера client)
  
-2.3 ping ip_адрес_server (c машины ​client)+2.3 ping ip_адрес_server (c компьютера client)
  
-2.4 ping ip_адрес_client (c машины ​client)+2.4 ping ip_адрес_client (c компьютера client)
  
-Где server - имя машины, где установлена ​samba, a ip_адрес_server - ip адрес этой машины. Для client аналогично ​;)+Где server - имя ​компьютера, где установлена ​Samba, a ip_адрес_server - ip адрес этого компьютера. Для client ​проверка проводится ​аналогично.
  
-3. пытаемся залогинется на сервер разными способами :)+3. Проверка доступа к ресурсам сервера.
  
-3.1 с машины ​server выполним smbclient -L \\server+3.1 С компьютера server выполним smbclient -L \\server
  
-3.2 с машины ​client выполним smbclient -L \\server+3.2 С компьютера client выполним smbclient -L \\server
  
-3.3 с машины ​client выполним smbclient -L \\ip_адрес_server+3.3 С компьютера client выполним smbclient -L \\ip_адрес_server
  
 Аккуратно записываем результаты тестов и [[http://​forum.ubuntu.ru/​index.php?​action=post;​board=27.0|на форум в раздел сети]]! Аккуратно записываем результаты тестов и [[http://​forum.ubuntu.ru/​index.php?​action=post;​board=27.0|на форум в раздел сети]]!
 +
 +
 +===== Железо. Периферия =====
 +
 +Проблемы с железом... когда-то бич линукс систем. И судя по тому, что вы читаете этот раздел,​ то не повезло и вам. Печально. И так возможно не всё потеряно,​ что нам потребуется:​
 +
 +1. Версия ядра (именно в нём находятся все драйвера) — вывод команды uname -a.
 +
 +2. Если устройство usb — вывод консольной команды lsusb и dmesg | tail после подключения устройства
 +
 +Если устройство pci — вывод lspci
 +
 +
 +===== Железо. Видеокарты =====
 +
 +1. Какая используется версия ядра, вывод команды uname -a
 +
 +2. Вывод lspci | grep VGA
 +
 +3. Приложить лог xserver'​а из /​var/​log/​Xorg.0.log ​
 +
 +
 +===== Программа перестала работать =====
 +1. Запускаем программу из терминала и ищем сообщения об ошибках.
 +
 +2. Часто проблемы бывают скрыты в настройках,​ которые мы сделали. Найдите директорию с настройками в своей домашней папке и переименуйте её. При следующем запуске будет создана новая директория с настройками по умолчанию.
 +
 +===== Копаемся в системных журналах =====
 +
 +==== Что такое системные журналы ====
 +У всех у нас есть на компьютере замечательная папка ​ /​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
 +    1 root      20   0 19300 1552 1132 S  0.0  0.3   ​0:​00.16 init
 +    2 root      15  -5     ​0 ​   0    0 S  0.0  0.0   ​0:​00.00 kthreadd
 +    3 root      RT  -5     ​0 ​   0    0 S  0.0  0.0   ​0:​00.00 migration/0
 +................................
 +</​file>​
 +Верхний процесс в списке процессов (в данном примере - init) - затребовал больше всех ресурсов непосредственно перед тем, как система зависла. В зависимости от того, что это был за процесс вы можете спланировать процесс дальнейшей отладки системы.
 +
 +{{tag> Tips Можно_улучшить}}