MSS 사용 중 에러 mss.exception.ScreenShotError: XGetImage() failed

1       원인 및 상황

원격으로 vnc server를 켜고 :0 display에서 작업을 하고 있었기에 ‘혹시 원격에서만 나타나는 현상일까?’싶어서 부팅 시 run level을 여러 단계로 조작해보며 시도해보기도 하고 직접 모니터를 연결해 시도해보았지만 결과는 똑같았다. 문제는 여기에 있지 않았던 셈.

…이라고 원인을 잘못 짚고 있었다. 나흘이 넘는 시간 동안에 온 웹사이트를 다 뒤지고 다니다가… 사사롭게 넘겼던 깃허브의 한 코멘트에서 얻은 조언을 응용하다가 결국 원인을 찾아내고야 말았다. 원인은 ‘화면의 크기보다 더 큰 사이즈를 grab하려 할 때 발생한 에러’이다.

현재 실행되고 있는 데스크톱의 display resolution이 철저하게 1920x1080이라고 믿고 있었다. 그런데 이 방법으로 얻은 이미지 파일의 크기는 1900x1200이었다. 설마 싶어서 grab()을 할 때 잘라낼 영역을 1000x1000으로 설정해보았더니 너무나도 잘 작동하는 것이었다.

 

2       해결 방법

튜토리얼의 코드를 따라 실행하되, 반드시 실행될 수 있을거라 확신하는 해상도를 입력해보길 바란다. 예를 들자면
sct.grab({"top": 10, "left": 20, "width": 100, "height": 200})
와 같은 코드를 실행해본다.

만약 위의 방법이 통하지 않는다면 세컨드 모니터 설정을 시도해보거나, x11 사용 설정을 고려해보는 것도 좋다.

 

3       잡설

아래는 에러를 해결해가며 알게 된 소소한(?) 내용을 함께 적어둔 것이다..

 

Ubuntu 20.04 LTS 버전에서 파이썬의 mss 라이브러리가 작동하지 않는 상태이다. 이에 관한 문제를 스택오버플로우에서 확인할 수 있었고, 이에 관한 해결책을 따라해보며 기록해보았다.

이 원인은 아마도 mss가 xWayland 대신에 x11을 사용하고 있는 것 같다. xWayland는 페도라의 기본값이고, mss는 화면을 캡쳐하는 데에 x11을 사용하는 것 같다고 한다.

그래서 이를 해결하기 위해 이 링크에서 제시하는 방법을 따라보았다. sudo nano /etc/gdm3/custom.conf 를 연다. 참고로 우분투 20.04 버전에서는 gdm 대신 gdm3로 들어가야 한다.

#WaylandEnable=false
를

WaylandEnable=false
로 주석 해제한 다음

[daemon] 섹션에 아래의 문장을 추가했다.

DefaultSession=gnome-xorg.desktop

저장.

 

그런데 이 방법은 앞선 상황에서 전혀 빛을 보지 못했다고 전해진다.

 

nvcc와 nvidia-smi 명령어가 보여주는 CUDA 버전이 다를 때

1       말하자면 아래와 같은 희안한 상황

nvcc --version 명령어는 10.1을 보여주는 데에 반해, nvidia-smi는 11.2를 보여주고 있는 상황.

 

2       원인

이는 CUDA가 두 개의 기본 API를 가지고 있기 때문이다. CUDA는 런타임 API와 드라이버 API를 가지고 있는데, 각각의 버전이 서로 상이할 수 있다.

예를 들어서 리눅스의 libcuda.so같은 드라이버 API에 필수적인 것들은 GPU driver installer에 의해 설치된다. 한편 libcudart.so나 nvcc같은 런타임 API들은 CUDA toolkit installer에 의해 설치된다.

항상 모든 경우에 있어서 driver API 버전과 runtime API 버전이 같아야만 하는 것은 아니다. nvidia-smi 명령어는 GPU driver installer에 의해 설치된 정보를 반환하며, CUDA toolkit installer에 의해 설치된 정보는 일체 반환하지 않는다.

이보다 더 상세한 내용은 스택오버플로우 게시물 및 NVIDIA 홈페이지에서 확인할 수 있다.

  

3       영향은

nvidia-smi가 ncvv --version보다 같거나 더 높은 CUDA 버전을 표시하는 것은 대수롭게 여기지 않아도 된다. 이는 CUDA에 정의된 호환성 경로 때문이다. 예를 들어서 위의 사진처럼 nvidia-smi가 CUDA 11.2를 보여주고 있고, nvcc --version이 CUDA 10.1을 표시하고 있더라도 더 최신의 드라이버가 구형의 CUDA toolkit 및 runtime API를 지원하기 때문에 문제가 되지 않는다.

다만 Command ‘nvcc’ not found가 출력되는 경우엔 CUDA 설치가 정상적으로 이루어지지 않은 것이므로 CUDA 11 linux install guide를 적절히 수행하여 해결해야 한다.

 

파이썬 import tkinter 에러 ModuleNotFoundError: No module named '_tkinter'

1       원인

이번엔 사용 환경이 독특하다. 시스템 기본 파이썬이 존재하지만, 별도로 파이썬 소스 코드로부터 컴파일해서 파이썬 바이너리 파일을 생성한 경우에 import tkinter 시 에러가 발생한다. 꼭 tkinter를 사용하지 않더라도 Matplotlib이나 OpenCV 등 많은 라이브러리에서 tkinter를 임포트하기 때문에, 해당 라이브러리를 사용하다가도 같은 문제를 만나게 될 수 있다.

시스템 기본 파이썬은 /usr/bin/python3 에 위치하고 있으며, 컴파일한 파이썬은 임의의 디렉토리(예를 들어서 ~/p/Python-3.9.1/ 등)에 위치하고 있다. 물론 컴파일 후에 sudo make install을 통해 /usr/local/bin/python3 으로 복사될 것이다. 그러므로 make install을 하기 전에 컴파일한 디렉토리에서 ./python 으로 실행을 시켜보고, 파이썬 인터프리터가 나타나면 import tkinter를 해서 제대로 컴파일이 되었는지를 확인하면 된다.

시스템 기본 파이썬을 실행시킨 후 인터프리터에 import tkinter를 입력하면 에러 없이 정상적으로 실행되지만, 컴파일한 파이썬에서는 제목과 같은 ModuleNotFoundError가 발생한다. 이는 컴파일 과정에서 tkinter가 포함되지 않은 것 같다.

 

2       사용 환경

지난 포스트와 동일한 환경이다. 해당 글을 참조하는 것으로 대체하였다.

 

3       해결 방법

(for deb)
sudo apt-get install python-tk python3-tk tk-dev

(for arch/manjaro)
sudo pacman -S tk

파이썬을 소스 코드로부터 컴파일 하기 전에 필요한 패키지가 있다. python-tk와 python3-tk는 많이 언급이 되었는데 tk-dev는 언급이 별로 없었다. 특히 마지막 패키지를 설치해주어야 컴파일 시 파이썬이 tk를 정상적으로 포함하게 된다.

 

파이썬 pip install 에러 Could not fetch URL. There was a problem confirming the ssl certificate

1       원인

사용하고 있는 환경에서 SSL 모듈이 사용 불가능한 경우이다. 에러 메시지에서도 알 수 있듯이 SSLError라고 적혀 있다. 직접 컴파일한 파이썬을 사용하는 경우에는 파이썬을 빌드할 때 해당 컴퓨터에 SSL 모듈이 설치 되어있는지 꼭 확인하여야 한다.

 

 

2       사용 환경

l  OS: Ubuntu 20.04 LTS

l  Python 3.8.5가 기본적으로 설치되어 있는 상태에서 이 링크를 따라 수동으로 3.9.1을 설치한 상태
(하지만 중간에 sudo apt install ~, ~, ~ 등을 생략하고 진행하였음. 문제의 원인)

l  직접 컴파일을 하는 경우엔 /usr/local/bin에 파이썬 바이너리 파일이 생성된다.
(하지만 sudo make altinstall 대신에 install을 해버렸다. 문제의 원인 2)

l  PyCharm에서 프로젝트를 생성할 때 해당 바이너리 파일을 base interpreter로 설정하였다.

l  PyCharm의 Terminal에서 pip install ~를 입력하면 볼 수 있는 에러가 위의 에러이다.

 

 

3       해결 방법

sudo apt install build-essential zlib1g-dev libncurses5-dev libgdbm-dev libnss3-dev libssl-dev libreadline-dev libffi-dev libsqlite3-dev wget libbz2-dev

위의 명령어로 파이썬 빌드에 필요한 패키지를 설치해준 다음에, 파이썬을 다시 컴파일하고 make install하면 문제가 해결된다. 물론 PyCharm의 프로젝트도 새로 생성하는 수고로움이 있었지만, 그래도 문제는 해결되었다.

위의 사용 환경에서 altinstall 대신에 install을 하면 시스템의 기본 python3 바이너리 파일을 덮어쓰게 된다! 여러 환경을 독립적으로 운용하고자 한다면 반드시 altinstall을 하도록 하자.

 

 

에러 - gcc versions later than 8 are not supported in cmake

 

0.     선요약 및 원인

이 게시물(2020년 4월)을 따라 문제를 해결하였다. 해당 게시물의 내용을 그대로 가져와 번역하였다.

문제는 해당 소프트웨어를 컴파일하기 위한 gcc의 버전이 ‘너무 높다’는 것이었다. 우분투 20.04 LTS 버전에서 현재 gcc를 설치하면 기본적으로 gcc 9를 설치해버린다. 이럴 때엔 gcc 하위 버전을 설치하고 컴파일하는 동안에만 해당 gcc로 업데이트해주면 된다.

이 과정은 Ubuntu 20.04 LTS Focal Fossa 버전에서 실행되었다. 하지만 다른 버전의 리눅스에서도 충분히 따라할 가치가 있으므로 참고하면 좋다.

 

1.     단계

여러 개의 C/C++ 컴파일러 버전을 설치해준다.

sudo apt install build-essential
sudo apt -y install gcc-7 g++-7 gcc-8 g++-8 gcc-9 g++-9

 

2.     단계

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 7
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-7 7
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8 8
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-8 8
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-9 9
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-9 9

여러 버전의 GCC와 G++ 컴파일러를 사용할 수 있도록 update-alternatives 툴에 리스트를 추가한다.

 

3.     단계

sudo update-alternatives --config gcc

위의 명령어를 통해 사용 가능한 C/C++ 컴파일러를 확인한다. 반응형 선택지가 나오면 0~3 중에서 원하는 gcc 버전을 선택하면 된다.

 

4.     단계

gcc –version
g++ --version

위의 명령어로 gcc와 g++의 버전이 임시적으로 변경되었는지 확인한다.

 

PyCharm 디버거 기능(Step Over, Step Into, Step Into My Code)

 

 

(출처: JetBrains)

 

0.     PyCharm에서 디버깅을 할 필요성

간혹 코딩을 하다가 보면 한 줄씩 차례대로 실행시키고 싶을 때가 있다. 이를 Stepping이라고 하는데, PyCharm에서는 디버깅 툴을 통해 단계별로 코드를 실행시킬 수 있다.

해당 코드에서 더 깊숙이 들어가고 싶을 때도 있고, 관심이 별로 없는 코드라서 빠르게 훑고 싶을 때도 있다. 이렇게 상황에 따라 다른 조작을 지원하고 있으므로 프로그래머가 필요에 따라 선택할 수 있어 매우 편리하다.

 

1.     버튼 및 의미

A. Step Over (F8)

Step Over는 코드의 현재 라인에서 그 다음 라인으로 이동한다. 하이라이트 표시된 라인이 메서드를 호출하고 있다 하더라도 다음 줄로 넘어가게 된다. 호출되고 있는 메서드는 내부적으로 실행된다.

다만, 내부적으로 실행되는 메서드라 하더라도 해당 메서드에 breakpoints가 존재할 경우, 디버거는 해당 위치에서 정지하게 된다. 메서드에 breakpoints가 있더라도 강제로 skip하고 싶은 경우엔 Force Step Over를 사용하면 된다.

 

B. Step Into (F7)

Step Into는 메서드 내에서 무슨 일이 일어나고 있는지를 보여준다. 호출한 메서드가 올바른 결과를 반환하고 있는지 확신할 수 없을 때에 이 기능을 사용해서 메서드 내부를 관찰할 수 있다.

만약 여러 개의 메서드가 한 번에 호출되고 있다면 PyCharm은 당신에게 어느 메서드로 들어갈 것인지를 물어보게 된다. 이 기능을 Smart Step Into라고 부른다고 한다. Smart Step Into는 메서드 다중호출 시에 기본적으로 사용하도록 되어있지만, 이 기능을 끄고 싶다면 Settings/Preferences – Build, Execution, Deployment – Debugger – Stepping에 들어가서 Always do smart step into를 체크 해제한다. 이 설정창에서는 Step Into 시에 skip할 목록들도 원하는 대로 관리할 수 있다. 또한 라이브러리 스크립트는 skip하고 싶을 땐 Do not step into library scripts에 체크하면 된다.

 

C. Step Into My Code (Alt+Shift+F7)

나의 코드에 집중하고 싶을 때, 라이브러리 클래스로는 stepping하지 않고 Step Into를 수행하는 기능이다.

 

D. Force Step Into (Alt+Shift+F7)

일반적인 Step Into에서는 skip되어야 했을 메서드에 강제로 진입한다.

 

E.  Step Out (Shift+F8)

메서드를 호출하던 바깥 코드로 빠져나온다.

 

F.  Run to Cursor (Ctrl+Alt+F9)

커서 깜빡이가 위치한 곳까지 실행을 진행시킨다. 중간에 breakpoints를 만나더라도 모두 무시된다.

 

2021년이 내게 와서 인사를 했다.

최근엔 집중해야 할 일도 많이 생기고

허튼짓(?)에 시간을 보낼 수 있는 기회도 줄어들고 있다.

어쩌면 훨씬 더 일찍부터 이랬어야만 했던 것일지도 모르겠다.

미루기보다는 생각 난 즉시 처리하기로 마음먹은지 어언 두어 달이 지나고 있다.

누가 그랬더라, 습관을 들이는 데에는 최소 21일이 걸린다고 했다.

하지만 누구보다 느리게 변하는 내겐 그보다 더 많은 시간이 필요했던 것 같다.

새해를 맞이하면서 또다시 지켜지지 않을 각오를 다지는 것보다는

실현 가능하고 장벽이 낮은 세부계획을 잘 수립해서 실천하는 것이

그 무엇보다도 성공 확률을 높일 수 있다는 점에 매우 공감하고 있다.

가볍게 운을 떼는 노래 가사처럼, 하지만 다 듣고 난 뒤엔 결코 가볍지 않았던 노래 가사처럼

나의 새로운 한 해도 가볍게 시작해, 12월 즈음엔 후회 없는 시간을 보냈다고 자신할 수 있는

그런 2021년이 되길 희망한다.

Bye 2020, Hello 2021.