기본 콘텐츠로 건너뛰기

추천 가젯

Tmux 환경에서 Vim 컴파일 시 발생하는 termio/termios 감지 오류 해결 방법

 리눅스 환경에서 소스코드를 직접 빌드하다 보면 의외의 환경 변수나 터미널 세션 설정 때문에 엉뚱한 빌드 에러를 마주할 때가 있습니다. 대표적인 예로 Tmux 세션 내부에서 Vim 소스를 컴파일할 때 발생하는 termio/termios 감지 오류 가 있습니다. 이번 글에서는 해당 에러가 발생하는 원인과, 단순한 clean 으로는 해결되지 않는 이유 및 올바른 해결 방법을 정리합니다. 1. 문제 원인 Vim의 소스 코드 빌드 과정( configure )은 시스템이 System V 계열인지 Linux 계열인지 판별하기 위해 termio.h 와 termios.h 헤더 파일 및 터미널 인터페이스를 검사(Probe)합니다. 하지만 Tmux 내부(세션 안)에서 컴파일을 진행할 경우 , Tmux가 제공하는 PTY(Pseudo-Terminal) 환경과 TERM=screen 등의 특수한 환경 변수 영향으로 인해 Autoconf가 터미널 인터페이스를 검출하는 과정에서 오동작을 일으킵니다. 그 결과, 실제 시스템 조건과 무관하게 설정 에러를 발생시키게 됩니다. 2. 왜 make clean 으로는 해결되지 않을까? 일반적인 개발 과정에서는 빌드가 꼬였을 때 make clean 을 실행하곤 합니다. 하지만 make clean 은 컴파일된 오브젝트 파일이나 바이너리( .o 파일 등)만 삭제할 뿐, Autotools가 시스템 환경을 탐색한 결과로 남긴 캐시( config.cache 또는 내부 매크로 변수)나 설정 파일들은 그대로 유지 합니다. 일반적인 상황에서는 시스템의 하드웨어/OS 정보가 바뀌지 않기 때문에 이 잔여물이 문제가 되지 않습니다. 그러나 Tmux나 Screen 같은 터미널 멀티플렉서 환경에서 탐색된 왜곡된 정보가 캐시에 박혀버리면, 나중에 Tmux 외부(일반 터미널)로 나와서 빌드를 시도해도 이전의 오염된 캐시 때문에 계속해서 오류가 발생하게 됩니다. 3. 해결 방법 이 문제를 해결하기 위해서는 반드시 Tmux 외부 환경 에서 기존의 오염된 설정 파일을 ...

연구실 서버에 gridengine(구 sun grid engine)을 깔려다가 안되서 멘붕. 대신 로컬머신 task-spoler를 찾았다.



hostname이 이상해서 메세지가 제대로 안가서 안되는 줄 착각하다가,
결국은 원인을 발견했으나... 해결방법이 없다. 내가 만든 코드가 아닌데 제공해주는 패키지에서 segmentation fault가 나오니 방법이 없다.

디버그 패키지를 제공해주면 어디서 에러가 났는지도 확인이 가능하겠지만,... 별 도움되는 정보가 없다. core dump  읽어보니 무슨 명령어에서 일이 발생한건지는 알겠는데... 역시 소스를 까봐야 하는거고 내가 이거 까는거 하는 사람이 아니니... 참...  나중에 centOS 가상화PC에다가 구축을 해봐야겠다.

다른 주요한 클러스터들이 centOS쓰는건 이유가 있겠지...

패키지만 깔아도 되는 상태를 만드는게 목적일 것 같으니까...




저 sgmentation fault가 spool머시기에서 문제가 생기는 거라
관련검색어로 검색을 하다보니

로컬환경에서 일반 작업 spooling 하는 도구를 알게 되었다.
다른 컴퓨터한테 일시키는건 수동으로 할 수 있을 것 같고, 순차적으로 일을 하게하는건 이 친구를 사용하면 될듯...

일단 기본 사용법은 간단함.

일단 맨페이지를 보면
NAME
      ts - task spooler. A simple unix batch system

SYNOPSIS
      tsp [actions] [options] [command...]

      Actions:  [-KClhV]  [-t [id]] [-c [id]] [-p [id]] [-o [id]] [-s [id]]
      [-r [id]] [-w [id]] [-k [id]] [-u [id]] [-i [id]]  [-U  <id-id>]  [-S
      [num]]

      Options: [-nfgmd] [-L <label>] [-D <id>]

DESCRIPTION
      ts  will  run by default a per user unix task queue. The user can add
      commands to the queue, watch that queue at any moment,  and  look  at
      the task results (actually, standard output and exit error).

요렇게 되어 있는데 tsp와 command 사이는 tsp의 옵션이고 command부터는 내가 할 작업을 넣어주면 된다.

액션과 옵션은 사실 tsp에게 주는 똑같은 파라미터라고 생각할 수 있지만 옵션은 command와 관련한 것이고
    표준 입출력 파일을 만들거냐 말거냐(-n)
    gzip으로 압축해서 내보낼거냐   (-g)
    백그라운드 작업으로 안보내고 할거냐 (-f)
    결과를 이메일로 보낼거냐 (-m)
    작업에 라벨을 붙일까?   (-L label)
     전 작업과 관련이 있는데 잘 모르겠다. (-d)
     id 옵션까지 주어서 같은 터미널에서 안해도 할수 있는드 (-D )
     작업이 꽉찾을 때, 원래는 대기하고 있으나 이 옵션을 쓰면
      메인 리턴 값을 2로 주고 즉시 종료 된다.   (-B)
와 같은 것들이 있는데 사실 -L옵션말고는 쓸일이 없을 것 같고,

액션쪽은 쓸게 몇개 있는데 일단 -S [num] 코어수를 정하는 옵션  등이다.

음 작업이 여러개 들어갈 때, 그리드엔진처럼 작업을 대기상태로 올려놓을 수 있는 거면 좋겠는데 저기위 설명을 봤을 때는 아닌 것 같아서 테스트가 필요할 듯...


10초뒤 수정 정보 ... 이거 개인 사용자들 압축 작업을 한다거나 하는 사람들이 쓰면 참 좋을듯...
 Label마다 따로 slot수 지정하는 기능만 있어도 굉장히 행복할 수도...



댓글

  1. 지금은 연구실에 있던 컴퓨터들을 모아서 Sun Grid Engine 으로 구축했다.

    답글삭제

댓글 쓰기