TIL: Today I Learned

(2017. 10. 18) RefSeq ID의 숫자는 왜 6자리 또는 9자리일까?

Gene annotation을 보다보면 유전자의 RefSeq accession이 NM_000000 또는 NM_000000000과 같은 형식으로 섞여 있는 것을 볼 수 있는데요. 어떤 유전자는 6자리의 숫자를 가지고 있고, 어떤 유전자는 9자리의 숫자로 되어 있습니다. 혹시 무슨 의미가 따로 있는지 찾아봤는데, 특별한 의미는 없었습니다. 단지 6자리의 accession number를 모두 소진했기 때문이라고 나와있습니다. 2004년 봄 NCBI 소식에 RefSeq accession의 자리수를 확장하겠다는 내용이 다음과 같이 있었습니다. 6자리에서 9자리로 길어지면서 기존의 6자리들은 그대로 6자리로 사용하고 앞으로 새롭게 부여되는 ID들은 9자리의 형식으로 배정하겠다는 내용도 있습니다. 아마도 RefSeq을 기반으로 하는 다른 데이터베이스나 프로그램에 주는 영향을 최소화 하기 위한 결정이지 않았을까 싶습니다.

Image 2004년 봄 NCBI 소식에 올라온 RefSeq accession에 관한 내용

아마도 시궁쥐(Rattus norvegicus)에서 protein 동정 연구가 매우 활발했나 봅니다. 그 당시 후각 수용체 단백질인 Olr1386 이 NP_999999라는 accession number를 부여받으면서 이런 뉴스가 나오게 되었나보네요. 마지막 내용에 보면 ‘첫 9자리 RefSeq accession ID를 누가 갖게 될까요?’라고 질문 하면서 이도 역시 시궁쥐의 후각 수용체 단백질이라고 소개하네요. 찾아보니 NP_001000000 에 배정받은 유전자는 Olr1389이었습니다. 잘 살펴보지 않으면 무심고 지나칠 수 있는 내용인데, 혹시라는 마음에 찾아보니 이런 에피소드도 있었습니다.


(2017. 10. 12) 4대 보험 가입확인서 출력 시 IE의 비정상적 종료

각종 연구참여 제출서류로 4대 사회보험 정보연계센터에서 4대보험 가입사실 확인서를 발급해야 할 경우가 종종 있습니다. 여러가지 Active X 때문에 인터넷 익스프로러로 접속을 하게 되는데요. 가입 확인서까지 창에 떴는데 인쇄버튼을 누르는 순간 IE(인터넷 익스프로러)가 비정상적으로 종료될 때가 있습니다. 이럴 땐 저는 아예 그냥 전화를 해서 물어봅니다. 그러니까 다음과 같이 친절하게 알려주네요. 아마도 기존에 깔려 있던 Active X가 제대로 업데이트가 되지 않아 출동하여 발생하는 문제인 것 같습니다.


사용자 지정 디렉토리에 Perl 설치

perl 버전에 따라 모듈을 설치하려고 할 때 예상치 못한 에러가 날 수 있습니다. 원하는 버전의 perl을 사용자 디렉토리에 설치해 사용함으로써 이를 해결할 수 있었습니다.

최근에 perl로 만들어진 프로그램을 사용하여 분석해야 할 일이 있어서 프로그램을 돌렸는데 아래와 같은 에러 메시지를 만났다.

Can't locate Math/CDF.pm in @INC (@INC contains ...)

perl이 Math-CDF라는 모듈을 불러들이는 데 실패했다는 메시지였다. 그래서 이 모듈을 찾아 설치하려고 하였다. README 파일에는 다음과 같이 차례대로 실행하여 설치하라는 안내가 있었다.

perl Makefile.pl
make
make install

모듈의 소스코드를 다운로드 받고 압축을 푼 후 압축을 푼 디렉토리에 들어가 위의 안내대로 따라해 보았다. 하지만 역시나 한번에 되는 건 없다.

$ perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for Math::CDF::cdflib
Writing Makefile for Math::CDF

$ make
cp CDF.pm blib/lib/Math/CDF.pm
AutoSplitting blib/lib/Math/CDF.pm (blib/lib/auto/Math/CDF)
(중략)
make: *** No rule to make target `ExtUtils/xsubpp', needed by `CDF.c'.  Stop.

make 단계에서 ExtUtils/xsubpp 라는 모듈이 존재하지 않아 설치가 중단되었다. perl에 기본적으로 같이 제공되는 모듈인 것 같은데, 현재 시스템인 CentOS에 기본적으로 설치되어 있는 perl의 버전이 낮아 모듈이 제대로 설치되지 않는 것 같았다. 현재 perl의 버전을 확인해 보았다.

$ perl --version
This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi
Copyright 1987-2009, Larry Wall

시스템에 설치된 버전은 5.10.1이고, 사용하고 있는 perl 프로그램의 권장 버전은 5.14.3 이었다. 따라서 CentOS의 perl 버전을 업그레이드 하기 위해서 yum update 를 시도해 보려다가 CentOS는 python 이나 perl 을 이용하여 시스템을 관리하는 부분이 많기 때문에 시스템에서 사용하고 있는 perl 의 버전 업그레이드는 예기치 않은 시스템 에러들이 생겨날 수 있다는 생각이 떠올랐다.

따라서 사용자 디렉토리에 perl을 따로 설치하기로 하였다. 해당 버전의 perl 을 다운로드 받고, configure 를 할 때에 prefix 를 주어서 원하는 디렉토리에 설치되도록 하였다.

./configure --prefix=/home/user/opt/perl-5.14.3
make
make install

사용자 디렉토리에 perl 이 문제없이 설치 되었고, 다시 Math-CDF 모듈을 설치하니 ExtUtils/xsubpp 문제 때문에 모듈이 설치되지 않는 문제는 없었다.

리눅스 시스템에서 원하는 버전의 python 이나 perl 을 사용하기 위해서는 시스템이 사용하고 있는 python 이나 perl 을 업그레이드 하려고 하지 말고 사용자 디렉토리에 따로 설치하여 사용하는 것이 제일 깔끔하고 시스템에 영향을 주지 않는 방법이라는 것을 다시 한번 깨달았다.


(2017. 6. 9) 터미널 화면의 간헐적인 freeze 현상

아예 동작을 하지 않거나 오류를 뿌려주면 손 쉽게 해결되는데, 그렇지 않은 것들은 문제의 원인부터 찾기가 쉽지 않을 때가 많다. 현재 사용하는 리눅스 서버(CentOS)를 재부팅 후 터미널(PuTTY) 환경에서 간헐적으로 커서가 일시정지 하는 현상이 발견되었다. Prompt에서 명령어를 입력하는 도중 혹은 명령어를 입력한 후 출력되고 있는 와중에 몇 초간 화면이 일시정지 된다. 제일 큰 불편은 vi 편집 도중 커서가 멈춰버려서 자주 오타가 났던 점이다.

혹시 터미널 문제인가 싶어 다른 SSH Client를 설치하여 보기도 하고, 서버의 메모리 및 CPU 자원을 수 차례 감시해보기도 하였다. 문제는 동일하게 계속되었다. 그렇게 몇 일을 불편하게 지내다가 한 명령어를 실행해보고 나서 문제의 원인을 찾게 되었다. 바로 df 명령어(현재 마운트 되어 있는 디스크 및 폴더 알려주는 명령어)였다. df 명령어를 치니 현재 마운트가 제대로 되어 있지 않은 디스크의 바로 전 라인까지만 출력이 되고 계속 멈춰있는 것이었다. Ctrl+c를 눌러 멈춰있는 상황을 빠져나왔다.

현재 서버에는 대용량 데이터 저장 목적으로 여러 대의 직접 연결 저장장치(DAS)가 물려있다. 심지어 마운트에 문제가 있었던 저장장치의 파일에는 액세스가 가능하면서도 간헐적으로 끊기는 현상이 지속되었던 것이다. 정상적으로 돌아가는 상황도 아니고 아예 오류가 발생한 상황도 아닌 애매한 상황이었다.

해결은 DAS가 물려 있는 서버의 root 계정으로 가서 네트워크 파일 시스템 데몬(NFS)을 재시작 service nfs restart 해주는 것이었다. nfs 데몬이 재시작 되고 나니 계속 되던 현상이 사라졌다.