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

Эта страница только для чтения. Вы можете посмотреть исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== Как писать баг репорт или давайте соберём грамотный анамнез ======
На форуме, куда вы обращаетесь за помощью сидят люди, которые часто искренне хотят Вам помочь :-) И чтобы не огорчать их фразами "у меня ничего не работает!" давайте грамотно и профессионально опишем проблему! Тогда, как максимум, возможно вы сами уведите, где ошибка. Ну или, как минимум, вы можете рассчитывать на вежливый ответ.
===== Сеть =====
Тема общая... поэтом у и рекомендации общие

1. Описать структуры сети. Например, "у меня 3 компьютера ОС "такая-то", главный получает интернет от провайдера по VPN|PPPOE|NAT|ещё что-н, с главного интернет раздаётся через NAT|(проски-сервер), файрволы стоят в режиме всё пропускать" или "у меня 2 компа ОС "такая-то" и роутер марка такая-то" и далее

2. Выводы команд ifconfig, route, cat /etc/resolv.conf, sudo iptables -L. Также стоит попытаться провести пингование подобное пункту 2 раздела, посвящённого Samba.

Файлы с настройками (если больше 5 строк) следует очистить от паролей и важных для вас адресов и приложить к сообщению вложением.

===== Проблемы с Samba. Расшаривание файлов по сети =====
1. берём конфигурационный файл samba

Выполните команду "testparm" и сохраните вывод этой команды. 

Эта команда диагностирует файл /etc/samba/smb.conf на синтаксические ошибки, а также, что более важно, показывает как видит samba файл с настройками.

2. пингуем машины в сети

Попытайтесь выполнить следующие комбинации пингования

2.1 ping server (c машины client)

2.2 ping client (c машины client)

2.3 ping ip_адрес_server (c машины client)

2.4 ping ip_адрес_client (c машины client)

Где server - имя машины, где установлена samba, a ip_адрес_server - ip адрес этой машины. Для client аналогично ;)

3. пытаемся залогинется на сервер разными способами :)

3.1 с машины server выполним smbclient -L \\server

3.2 с машины client выполним smbclient -L \\server

3.3 с машины client выполним smbclient -L \\ip_адрес_server

Аккуратно записываем результаты тестов и [[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}}
Как писать баг репорт или давайте соберём грамотный анамнез Правка
