Project

General

Profile

GettingLogs » History » Version 12

Wolfgang Wiedmeyer, 05/07/2017 09:42 PM
uppercase ID

1 4 Paul Kocialkowski
h1. Getting logs
2 1 Paul Kocialkowski
3 9 Wolfgang Wiedmeyer
{{>toc}}
4
5 1 Paul Kocialkowski
When some component misbehaves or stops working on Replicant, it is recommended to:
6
# Get logs showing the issue
7 7 Wolfgang Wiedmeyer
# Open a ticket on our tracker to report the issue (*New issue* tab) or submit the logs to an existing issue that already describes the same misbehavior (*Update* at the bottom of the issue)
8 1 Paul Kocialkowski
9 4 Paul Kocialkowski
h2. Buffers
10 1 Paul Kocialkowski
11
The Android logging subsystem uses different log buffers: @events@, @main@, @radio@ and @system@.
12
Generally speaking, when the issue you encountered concerned telephony, including data (3G), the buffer you want is @radio@. In any other case, that's the @main@ buffer you want.
13
14 6 Wolfgang Wiedmeyer
In some cases, the information provided by the Android log buffers is not sufficient and the message buffer of the Linux kernel is additionally required for investigating the issue.
15 1 Paul Kocialkowski
16 6 Wolfgang Wiedmeyer
There are various ways to obtain the logs:
17
18 1 Paul Kocialkowski
h2. Using ADB
19 3 Paul Kocialkowski
20 6 Wolfgang Wiedmeyer
First, you need to [[ToolsInstallation#ADB|install ADB]].
21 1 Paul Kocialkowski
22 6 Wolfgang Wiedmeyer
h3. Retrieving a buffer from the Android logging subsystem
23
24
Display a buffer from the Android logging subsystem:
25
26 3 Paul Kocialkowski
<pre>
27 1 Paul Kocialkowski
adb logcat -b [BUFFER]
28 5 Wolfgang Wiedmeyer
</pre>
29
30
To prepare a new issue report, you need to save the output to a file:
31
32
<pre>
33 1 Paul Kocialkowski
adb logcat -b [BUFFER] -d > path/to/file
34
</pre>
35 6 Wolfgang Wiedmeyer
36
h3. Retrieving the kernel message buffer
37
38
Display the kernel message buffer:
39
40
<pre>
41
adb shell dmesg
42
</pre>
43
44
To prepare a new issue report, you need to save the output to a file:
45
46
<pre>
47
adb shell dmesg > path/to/file
48
</pre>
49
50 1 Paul Kocialkowski
51 4 Paul Kocialkowski
h2. Using aLogcat
52 1 Paul Kocialkowski
53
aLogcat is a (free) Android app that will collect logs and save them to a file, either regularly or when you press the *Save* button from the app menu.
54
You can set the desired buffer from the @Preferences@.
55
56
After saving the log, you can get it from a file stored in the @alogcat@ folder on the root of storage.
57 7 Wolfgang Wiedmeyer
58
h2. Submitting the logs
59
60 10 Wolfgang Wiedmeyer
You can simply attach the log file to the issue report. 
61
62 11 Wolfgang Wiedmeyer
Logs from the @radio@ buffer can contain privacy-sensitive information. If you don't want to have this information publicly available on the issue tracker, you can encrypt the log, so only Replicant developers can view it. Encrypting the logs has the disadvantage that very likely nobody else will be able to contribute in order to solve the issue.
63 7 Wolfgang Wiedmeyer
64
h3. Encrypting logs
65
66
First, you need to retrieve the GPG keys of the active Replicant developers. They are listed on the [[People]] page. It is recommended to retrieve them using
67
<pre>
68
gpg --recv-keys KEY_ID
69
</pre>
70
71 12 Wolfgang Wiedmeyer
and replacing @KEY_ID@ with the listed key IDs. If you have issues retrieving a key of a developer, you can still continue and encrypt the log for the other developers.
72 7 Wolfgang Wiedmeyer
73
Then, you can encrypt the log file:
74
<pre>
75
gpg --recipient KEY_ID_1 --recipient KEY_ID_2 ... --encrypt LOG_FILE
76
</pre>
77
78 12 Wolfgang Wiedmeyer
Replace @KEY_ID_1@ and @KEY_ID_2@ with the key IDs of the developers and add more @--recipient@ options replacing @...@ until the key IDs of all active developers are listed. Replace @LOG_FILE@ with the path to the log file you want to encrypt. The command should produce a file with the same name as your log file, but with the file ending @gpg@. This is the encrypted log file. Attach this file to the issue report.
79 7 Wolfgang Wiedmeyer
80
Replicant developers will not share publicly entire unencrypted logs, but they might include unencrypted snippets of the logs in the issue discussion if it helps to fix the issue. The developers will make sure that these snippets do not contain privacy-sensitive information or that all privacy-sensitive information was removed.