답변:
응용 프로그램에 따라 다릅니다. 응용 프로그램마다 로깅 시스템이 다릅니다. 시스템에서 실행되는 모든 프로그램의 모든 출력을 포함하는 하나의 중앙 로그가 없습니다.
많은 프로그램이 로그 파일을 디렉토리에 넣습니다 /var/log. 특히 파일 /var/log/syslog(또는 /var/log/messages)은 "시스템 로거"의 출력을 포함하는데, 이는 시스템이 로깅을 위해 사용할 수있는 시스템에서 제공하는 서비스입니다. 그러나 모든 프로그램이이를 사용하는 것은 아닙니다. 대부분 일반적으로 사용하는 그래픽 응용 프로그램이 아니라 해당 파일에서 하위 수준 시스템 서비스의 메시지를 찾습니다.
표준 로그 파일의 위치에 대한 자세한 내용 을 읽을 수 있습니다 .
충돌 파일은 /var/log/crashes/apport와 함께 사용하여 버그를보고합니다. 을 사용하여 코어 덤프를 추출하고 apport-unpack해당 코어 덤프를 gdb를 통해 넣은 다음 프로그램 충돌 원인을 확인할 수 있습니다.
이것은 모두 당신이 프로그래머라고 가정합니다. 당신이하지 않으면 ... 어쨌든 충돌을 해결할 수 없습니다!
bt full"아무런 기호가없는 백 트레이스를 보아라 .... 추적 기호를 설치하고 충돌을 재현해야한다." 중단 점 ... 그것이 내가 얻은 가장 진보 된 것입니다.
일부 응용 프로그램에는 -d, -D, --debug 등과 같은 디버깅을 설정하는 데 사용할 수있는 플래그가 있습니다. 응용 프로그램 설명서 페이지 ( man [my-app])를 확인하거나 -h 플래그로 응용 프로그램을 실행하여 선택권.
많은 GUI 앱이 $ HOME / .xsession-errors에 쓰므로 출력을 확인하기에 좋습니다.
maco의 apport는 아마도 좋은 디버그 정보를 얻는 가장 확실한 방법 일 것입니다. 때로는 충돌을 포착하지 못합니다.
다른 모든 방법이 실패하면 gdb에서 앱을 실행하여 정보를 강제로 제거 할 수도 있습니다. 다음과 같습니다.
$ gdb my-app
(gdb) run
... 충돌에 필요한 것은 무엇이든한다 ...
(gdb) bt full
거기에서 가십시오.
gdb 경로를 사용하는 경우 앞에서 언급 한대로 기호를 설치해야합니다. 핸드 홀딩 조언 은 https://wiki.ubuntu.com/DebuggingProgramCrash 를 참조 하십시오 .
.desktop 실행기 파일에서 응용 프로그램을 시작하는 경우 Terminal=true.desktop 파일에 옵션 을 추가 하십시오. 이것은 프로그램을 실행할 때 터미널을 열고 터미널의 출력은 처음에 명령 줄을 통해 프로그램을 실행했는지 여부와 비슷합니다. 이런 방식으로 GUI가 충돌하거나 중단되면 어떤 텍스트 출력이 GUI로 연결되는지 확인할 수 있습니다.