xxxxx@main.gjssm 의 메일계정으로 메일을 보낸 박성수님.
gmail로 제게 문의하셨는데, 이메일 주소가 이상해서 찾아보니
광주삼성멤버쉽의 약자더군요. 그런데 제가 답장을 보냈습니다만, 도착하지 않았을 거라고 생각하고 있는데요.
C:\Documents and Settings\usr0100023>nslookup
Default Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
> main.gjssm
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
*** gmogrp01.gmogrp.local can't find main.gjssm: Non-existent domain
> set type=mx
> main.gjssm
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
*** gmogrp01.gmogrp.local can't find main.gjssm: Non-existent domain
>
일반 인터넷 네트웍으로는 main.gjssm의 MX주소를 찾을 수 없어요.
메일 헤더에 이런 내용이 있어서
Received: from main1.main.gjssm (u73.e3.xgate.co.kr [210.118.73.3])
by mx.google.com with ESMTP id 29si9691858pzk.85.2009.11.24.06.54.56;
Tue, 24 Nov 2009 06:54:57 -0800 (PST)
u73.e3.xgate.co.kr가 SMTP였을 거라고 따라가 보았습니다만
C:\Documents and Settings\usr0100023>tracert u73.e3.xgate.co.kr
racing route to u73.e3.xgate.co.kr [210.118.73.3]
ver a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.30.3 2 <1 ms <1 ms <1 ms 192.168.2.5 3 <1 ms <1 ms <1 ms 192.168.4.5 4 6 ms 1 ms 1 ms ceru-nat2.interq.or.jp [210.172.128.225] 5 2 ms 3 ms 2 ms g-svc1-e-0-4.interq.or.jp [210.172.130.78] 6 1 ms 1 ms 1 ms b5-e-2-4.interq.or.jp [210.172.191.193] 7 2 ms 2 ms 2 ms AS15412.ix.jpix.ad.jp [210.171.224.139] 8 31 ms 31 ms 31 ms so-0-3-0.0.ejr03.seo002.flagtel.com [62.216.128.18] 9 35 ms 33 ms 32 ms 80.77.1.178 10 32 ms 32 ms 32 ms 157.197.66.5 11 32 ms 32 ms 33 ms user233.s163.samsung.co.kr [203.241.163.233] 12 34 ms 33 ms 32 ms u78.ppp80.unitel.co.kr [157.197.80.78] 13 32 ms 32 ms 32 ms u174.gpu47.samsung.co.kr [203.244.223.174] 14 250 ms 225 ms 184 ms 121.253.214.234 15 199 ms 203 ms 195 ms u73.e3.xgate.co.kr [210.118.73.3]
C:\Documents and Settings\usr0100023>nslookup
Default Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
> set type=ns
> u73.e3.xgate.co.kr
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
xgate.co.kr
primary name server = red.samsung.co.kr
responsible mail addr = root.wyt.co.kr
serial = 2006122101
refresh = 21600 (6 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 300 (5 mins)
>
> server red.samsung.co.kr
Default Server: red.samsung.co.kr
Address: 203.241.135.111
> set type=ns
> u73.e3.xgate.co.kr
Server: gmogrp01.gmogrp.local
Address: 192.168.1.41
xgate.co.kr
primary name server = red.samsung.co.kr
responsible mail addr = root.wyt.co.kr
serial = 2006122101
refresh = 21600 (6 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 300 (5 mins)
> server u73.e3.xgate.co.kr
Default Server: u73.e3.xgate.co.kr
Address: 210.118.73.3
> set type=mx
> main.gjssm
Server: u73.e3.xgate.co.kr
Address: 210.118.73.3
local
primary name server = nis.dacom.co.kr
responsible mail addr = dnsadm.bora.net
serial = 2008052301
refresh = 3600 (1 hour)
retry = 1800 (30 mins)
expire = 604800 (7 days)
default TTL = 86400 (1 day)
> exit
역시나 네임서버를 u73.e3.xgate.co.kr를 쓰지 않으면 인식할 수 없는 도메인(또는 mx)이에요.
아무래도 메일이 도착하지 않았을 경우에는 답장가능한 메일 주소로 다시한번 연락해 주세요.
김동현.
Tuesday, November 24, 2009
Friday, October 23, 2009
Thursday, October 8, 2009
마이크로소프트 Tech ed 2009 (요코하마편) 레포트
[정보공유]
시스템본부 미팅과 더불어 마이크로소프트의 Tech ed 2009 참석자의 레포트가 있었는데,
기존의 IIS는 불필요한 것들도 들어가 security문제가 빈번히 발생
(으로 인해 간단한 사용으로는 가능하지만, IT업계에서는 퇴역화 라고 말해졌습니다.)
IIS7을 소개하며 필요한 것만 load하도록 Apache처럼 모듈화가 된다는 군요.
더불어 여러가지 cgi 언어의 모듈도 가능하기 때문에
php모듈, python모듈.. 처럼 여러 언어의 스크립트도 서포트 가능. 이랍니다.
(유닉스 유저를 끌어들이기 위한 전략.)
유닉스 유저를 끌어들이기 위한 전략의 또 하나로,
Powershell.
(명령어 실행시키기로는 불편하고 별로 쓸모 없는 툴이라고 생각했었는데)
이는 기존의 GUI 위주로 설정을 변경하던 것을(CUI로도 몇몇은 가능했지만) CUI화 지원으로,
설정변경등을 스크립트화 하는 것. 이 큰 목적인 툴이랍니다.
또 가상화
Hyper-V 2.0
게임관련으로 윈도우즈 서버를 사용하는 시스템에서는 연구해 봐도 좋을 듯합니다.
특히 Live Migration 기술(복수개의 가상화서버가 움직이고 있는 어떤 Host서버에서 다른 Host서버로, down time 없이 실시간으로 이동하는 것).
그리고 VHD(Virtual Hard Disk) <--> Physical Hard Disk 간의 변환이 자유로움
은.
(참석자가 호스팅이 메인사업인 호스팅 사업부 멤버였기 때문에)
아직 윈도우즈 호스팅이 없는 일본 호스팅업계에서,
수 년 후, 윈도우즈 호스팅이 매우 늘어날(그리고 MS에서 이에 대해 서포트전략을 세우고 있다는) 전망의 얘기가 나왔습니다.
윈도우즈 엔지니어라면 눈여겨봐둬도 좋을 내용.
시스템본부 미팅과 더불어 마이크로소프트의 Tech ed 2009 참석자의 레포트가 있었는데,
기존의 IIS는 불필요한 것들도 들어가 security문제가 빈번히 발생
(으로 인해 간단한 사용으로는 가능하지만, IT업계에서는 퇴역화 라고 말해졌습니다.)
IIS7을 소개하며 필요한 것만 load하도록 Apache처럼 모듈화가 된다는 군요.
더불어 여러가지 cgi 언어의 모듈도 가능하기 때문에
php모듈, python모듈.. 처럼 여러 언어의 스크립트도 서포트 가능. 이랍니다.
(유닉스 유저를 끌어들이기 위한 전략.)
유닉스 유저를 끌어들이기 위한 전략의 또 하나로,
Powershell.
(명령어 실행시키기로는 불편하고 별로 쓸모 없는 툴이라고 생각했었는데)
이는 기존의 GUI 위주로 설정을 변경하던 것을(CUI로도 몇몇은 가능했지만) CUI화 지원으로,
설정변경등을 스크립트화 하는 것. 이 큰 목적인 툴이랍니다.
또 가상화
Hyper-V 2.0
게임관련으로 윈도우즈 서버를 사용하는 시스템에서는 연구해 봐도 좋을 듯합니다.
특히 Live Migration 기술(복수개의 가상화서버가 움직이고 있는 어떤 Host서버에서 다른 Host서버로, down time 없이 실시간으로 이동하는 것).
그리고 VHD(Virtual Hard Disk) <--> Physical Hard Disk 간의 변환이 자유로움
은.
(참석자가 호스팅이 메인사업인 호스팅 사업부 멤버였기 때문에)
아직 윈도우즈 호스팅이 없는 일본 호스팅업계에서,
수 년 후, 윈도우즈 호스팅이 매우 늘어날(그리고 MS에서 이에 대해 서포트전략을 세우고 있다는) 전망의 얘기가 나왔습니다.
윈도우즈 엔지니어라면 눈여겨봐둬도 좋을 내용.
Wednesday, September 30, 2009
정보공유 : 리눅스 터미널 로그인시 1-2분 걸리는 현상
[정보공유]
리눅스 터미널 로그인시 1-2분 걸리는 현상이 발생하고 있다면?
이전에도 몇 번 경험한 내용이었는데 해결방법을 몰랐다가 이번에 알게 되었음.
sshd에서 정방/역방 IP조회를 하고 있기 때문에 DNS 타임아웃이 발생하는 시간까지 걸리는 것일 듯.
DNS에 정방/역방 등록을 하지 않고서 해결하는 방법으로는.
(A) 우선 sshd설정(/etc/ssh/sshd_config)에서 useDNS를 no로 하는 방법과.
(B) 접속하는 곳이 고정이라면 서버측 /etc/hosts에 이름을 등록하는 방법.
이상 정보공유.
리눅스 터미널 로그인시 1-2분 걸리는 현상이 발생하고 있다면?
이전에도 몇 번 경험한 내용이었는데 해결방법을 몰랐다가 이번에 알게 되었음.
sshd에서 정방/역방 IP조회를 하고 있기 때문에 DNS 타임아웃이 발생하는 시간까지 걸리는 것일 듯.
DNS에 정방/역방 등록을 하지 않고서 해결하는 방법으로는.
(A) 우선 sshd설정(/etc/ssh/sshd_config)에서 useDNS를 no로 하는 방법과.
(B) 접속하는 곳이 고정이라면 서버측 /etc/hosts에 이름을 등록하는 방법.
이상 정보공유.
Friday, September 25, 2009
rxvt on windows
윈도우즈의 cmd로는 뭔가 부족하게 느껴집니다.
1) 프로세스를 백그라운드로 실행시키기 라던가,
2) (default로) ansi가 적용되지 않기 때문에, groovysh할 때 컬러를 쓸 수 없는 것도 그렇고. (음? 이건 장점?),
3) parameter로 묶을 때, single quotation은 사용할 수 없고, double quotation ""만 사용할 수 있는 것
4) cmd에서는 터미널타입이 적당한 것이 없어서 perl로 ssh를 자동화하기도 곤란.
이러한 이유로 rxvt + bash를 사용해 보고 있습니다.
rxvt는 vt102터미널 에뮬레이터입니다. 이번에 GNUstep인스톨할 때 같이 설치된 rxvt를 사용해 보고 있습니다.(이럴 바에는 cygwin을 쓸까 하는 생각도 해보았습니다만, 아직까지는 일반 cmd상에서도 유닉스 커맨드를 사용할 수 있는 linux command for win32 처럼 cygwin의 커맨드를 cmd에서 사용가능한 지, 확인하지 못했습니다.)
유니코드용으로 컴파일된 urxvt와 탭형식으로 된 mrxvt도 있다고 합니다만, 모두 X-windows용으로, 아직 win32용으로 컴파일된 것은 못구했습니다. (시간이 없다는 이유로 아직 직접 컴파일 해보고 있지 않습니다. m(__)m )
그런대로 사용하기는 괜찮을 듯 합니다.
소프트링크도 제대로 사용할 수 있기 때문에, 필요한 경우
/c 이하의 디렉토리를 shell root안으로 가져온다던지 하는 것도 가능했고.
괜찮은 느낌입니다.
좀 더 사용해 보겠습니다.
1) 프로세스를 백그라운드로 실행시키기 라던가,
2) (default로) ansi가 적용되지 않기 때문에, groovysh할 때 컬러를 쓸 수 없는 것도 그렇고. (음? 이건 장점?),
3) parameter로 묶을 때, single quotation은 사용할 수 없고, double quotation ""만 사용할 수 있는 것
4) cmd에서는 터미널타입이 적당한 것이 없어서 perl로 ssh를 자동화하기도 곤란.
이러한 이유로 rxvt + bash를 사용해 보고 있습니다.
rxvt는 vt102터미널 에뮬레이터입니다. 이번에 GNUstep인스톨할 때 같이 설치된 rxvt를 사용해 보고 있습니다.(이럴 바에는 cygwin을 쓸까 하는 생각도 해보았습니다만, 아직까지는 일반 cmd상에서도 유닉스 커맨드를 사용할 수 있는 linux command for win32 처럼 cygwin의 커맨드를 cmd에서 사용가능한 지, 확인하지 못했습니다.)
유니코드용으로 컴파일된 urxvt와 탭형식으로 된 mrxvt도 있다고 합니다만, 모두 X-windows용으로, 아직 win32용으로 컴파일된 것은 못구했습니다. (시간이 없다는 이유로 아직 직접 컴파일 해보고 있지 않습니다. m(__)m )
그런대로 사용하기는 괜찮을 듯 합니다.
소프트링크도 제대로 사용할 수 있기 때문에, 필요한 경우
/c 이하의 디렉토리를 shell root안으로 가져온다던지 하는 것도 가능했고.
괜찮은 느낌입니다.
좀 더 사용해 보겠습니다.
Thursday, September 24, 2009
Record : 'use constant' on perl
perl의 constant는 반드시 먼저 선언해 주어야 하는 듯.
BEGIN으로 컴파일타임시에 정의되도록 해봤지만 잘 되지 않았습니다.
'use constant'는 컴파일타임 이전의 preprocessor가 처리하는 듯?(짐작) 합니다.
evalperl
use constant CONST_SERVICEID_IPADDR => 101;
eeprint(CONST_SERVICEID_IPADDR);
101
-----------------------------
evalperl
eeprint(CONST_SERVICEID_IPADDR);
use constant CONST_SERVICEID_IPADDR => 101;
CONST_SERVICEID_IPADDR
-----------------------------
evalperl
eeprint(CONST_SERVICEID_IPADDR);
BEGIN { use constant CONST_SERVICEID_IPADDR => 101; }
CONST_SERVICEID_IPADDR <- 101 이 아님. orz
-----------------------------
evalperl
eeprint($CONST_SERVICEID_IPADDR);
BEGIN { our $CONST_SERVICEID_IPADDR = 101; }
101 <- 이건 101. orz
어디선가 본 글처럼, perl이나 jscript같은 interpretor에서는, 그냥 constant를 사용하기 보다는 변수로 사용하는 것이 performance면에서도, 정신적인 건강면에서도 좋지 않은가 싶습니다.
# 생각해보면, python에서도 constant가 없긴합니다.
사진은 파키스탄의 10세(2008년기준) 최연소 MCP 인증받은 소녀 프로그래머.
http://www.pakassociationdubai.com/business_details.php?id=55
.
BEGIN으로 컴파일타임시에 정의되도록 해봤지만 잘 되지 않았습니다.
'use constant'는 컴파일타임 이전의 preprocessor가 처리하는 듯?(짐작) 합니다.
evalperl
use constant CONST_SERVICEID_IPADDR => 101;
eeprint(CONST_SERVICEID_IPADDR);
101
-----------------------------
evalperl
eeprint(CONST_SERVICEID_IPADDR);
use constant CONST_SERVICEID_IPADDR => 101;
CONST_SERVICEID_IPADDR
-----------------------------
evalperl
eeprint(CONST_SERVICEID_IPADDR);
BEGIN { use constant CONST_SERVICEID_IPADDR => 101; }
CONST_SERVICEID_IPADDR <- 101 이 아님. orz
-----------------------------
evalperl
eeprint($CONST_SERVICEID_IPADDR);
BEGIN { our $CONST_SERVICEID_IPADDR = 101; }
101 <- 이건 101. orz
어디선가 본 글처럼, perl이나 jscript같은 interpretor에서는, 그냥 constant를 사용하기 보다는 변수로 사용하는 것이 performance면에서도, 정신적인 건강면에서도 좋지 않은가 싶습니다.
# 생각해보면, python에서도 constant가 없긴합니다.
사진은 파키스탄의 10세(2008년기준) 최연소 MCP 인증받은 소녀 프로그래머.
http://www.pakassociationdubai.com/business_details.php?id=55
.
Wednesday, September 23, 2009
programming way of system engineer
이번 기술부 지원 프로젝트에서 경험했던, 'SE의 프로그래밍을 서포트한 2009년 여름 프로젝트'는 굉장히 색다른 느낌이었습니다. 이 이야기를 적어볼까 합니다.
서포트를 나가게 된 배경은 다음과 같습니다.
2008년 리만브러더스 파산과 더불어 시작된 불경기, 그리고 사내 파견사원의 감축과 정사원위주만으로의 운영, 신규프로젝트 발생과 기술부 리소스부족(perl과 python코딩에 대한), 개발부에 지원요청과 해당 경험이 있고 덜 중요한(?!) 리소스(바로 접니다)의 지원제공.
1. 굉장히 간결한 방식을 선호(shell script를 확장한 것과 같은 느낌의 프로그래밍.)
'심플한 것이 아름답다'라는 프로그래밍에서의 정석이 있습니다만, 정말 그것을 실천하려고 애를 씁니다. 특히, 한 줄 코드로 가능할 수 있다면, 그렇게 하려고 애를 씁니다. 여기서 몇가지 지금까지와는 다른 상식으로 진행되었는데, 예를 들면,
1) 가능하면 클래스는 사용하거나 작성하지 않습니다.
어차피 pointer를 tie하는 것에 지나지 않는 클래스를 생성하려고, new하는 한 줄의 코드를 작성하는 것은, 불필요한 리소스 낭비로 여기어 지는 것 같았습니다.
2) parameter는 주로 array of hash reference
hash reference인 것은 이해가 가지만, 그것의 array였다는 것은 좀 색달랐습니다.
3) 리턴값, int형 보다는 (rc, rm)의 배열.
rc는 return code, rm은 return message입니다.(간혹 엔지니어에 따라 rv 즉 return value로 사용하는 경우도 있었습니다.)
리턴이 perl의 subroutine이든, python의 method이든, 실패했을 경우 그 이유를 알기 위한 메시지를 함께 전달합니다. 실패라면 exception을 함께 전달하는 느낌입니다.
문제없이 진행되어 rc가 성공이라면, rm은 해당 리턴값을 가지게 하는 설계가 많았습니다.
4) 리턴값, 0 = 성공, 1 = 실패
이는 시스템 커맨드의 리턴(batch라면 errorlevel)이 대게 에러번호를 리턴하는데 기인합니다.
개발자로서의 인식으로는 non-zero = true, 0 = false 이기 때문에 checkData와 같은 함수의 리턴이 1(true)라면, OK라는 인식이지만, SE에게는 NG라는 인식입니다.
이는 정의하고 진행하면 되는 것이기 때문에 특별히 문제는 없었습니다만, "음? 성공하면 0입니까? (성공하면 false입니까?)"하고 물었을 때, '음? 당연한 것을 왜묻지?'하는 느낌의 반응은 약간의 이질감을 느끼게 되더군요.
2. 놀라운 시스템 관련 지식.
이것은 말할 것도 없습니다. (모든 SE가 다 그렇지는 아니겠지만) 굉장히 정확한 지식을 가지고 있었습니다.
이런 예가 있었습니다. 한번은 '어떤 명령어 | sed xxxxx'와 같은 외부 프로세스를 실행한 결과를 치환해 값을 받도록 실행하는 코드를 작성한 적이 있었습니다. 이때 다른 명령어는 모두 문제가 없었는데 어느 특정 한 명령어는 프로세스가 종료하지 않고 메모리에 남아 있게 되는 일이 있었습니다.
이를 SE에게 문의했는데, 추적하는 것을 보여주더군요. 값진 경험이었습니다.
우선, ps상 이 프로세스가 defunc가 아니었기 때문에(좀비가 아니었기 때문에) 폭주인지, 아니면 무엇을 하고 있는지 strace를 통해 pid에 걸어서 무엇을 하고 있는지 알아보더군요. 지금까지 나 이외에 strace를 사용하는 것을 '직접' 본 두번째 경험이었습니다.)
우선은 표준입력을 기다리고 있는 것을 알아내어 폭주는 아닌 것을 확인했습니다. 그다음 왜 표준입력을 기다리고 있는지 알아보았는데, 그 '특정 명렁어'가 표준 출력으로 출력하는 것을 모두 /dev/null로 돌려놓고 있었더군요. 결국 sed는 뭔가 파이프로 전해져 오는 것이 없었기 때문에 sed가 입력을 기다리고 있었고, child의 pid를 수확하지 못하고 있기 때문에 parent의 '특정 명령어' 및 shell이 살아남아 있는 것이었습니다.
이때 잠깐 질문을 제가 했는데, sed를 echo로 바꾸면 정상종료하는데, 그 차이를 잘 이해하지 못하다라고 얘기했을 때, 설명을 받았습니다.
이때 그는 파이프 처리에 관련된 설명을 하면서 File Descriptor라는 용어를 사용해 설명하였는데, 나는 시스템 프로그래밍 기사나 책을 읽으면서 몇번 본 적은 있지만, file descriptor라는 단어를 내 입으로 조차 발음해 그 소리를 내 귀로 들은 적이 한 번도 없었는데, 이때 설명받으면서 들은 것이 난생 처음이었습니다.(그만큼 그 개념을 직접 말해 설명하는 것을 듣는 것이 굉장히 드믄 일입니다.)
3. 기타
<작성중>
1) 자기가 작성한 코드는 장해 발생때 대응하는 사람이 살펴보고 긴급히 수정해 대응할 수 있어야 하는 코드
2) '로직을 아직 다 못썼습니다.'
3) '단순한 버그이기 때문에 위치를 알면 곧 수정해 대응이 가능합니다.'
대신 환경(장비상의, 또는 시스템상의) 이나 데이타의 대응이 훨씬 더 큰 일.
서포트를 나가게 된 배경은 다음과 같습니다.
2008년 리만브러더스 파산과 더불어 시작된 불경기, 그리고 사내 파견사원의 감축과 정사원위주만으로의 운영, 신규프로젝트 발생과 기술부 리소스부족(perl과 python코딩에 대한), 개발부에 지원요청과 해당 경험이 있고 덜 중요한(?!) 리소스(바로 접니다)의 지원제공.
1. 굉장히 간결한 방식을 선호(shell script를 확장한 것과 같은 느낌의 프로그래밍.)
'심플한 것이 아름답다'라는 프로그래밍에서의 정석이 있습니다만, 정말 그것을 실천하려고 애를 씁니다. 특히, 한 줄 코드로 가능할 수 있다면, 그렇게 하려고 애를 씁니다. 여기서 몇가지 지금까지와는 다른 상식으로 진행되었는데, 예를 들면,
1) 가능하면 클래스는 사용하거나 작성하지 않습니다.
어차피 pointer를 tie하는 것에 지나지 않는 클래스를 생성하려고, new하는 한 줄의 코드를 작성하는 것은, 불필요한 리소스 낭비로 여기어 지는 것 같았습니다.
2) parameter는 주로 array of hash reference
hash reference인 것은 이해가 가지만, 그것의 array였다는 것은 좀 색달랐습니다.
3) 리턴값, int형 보다는 (rc, rm)의 배열.
rc는 return code, rm은 return message입니다.(간혹 엔지니어에 따라 rv 즉 return value로 사용하는 경우도 있었습니다.)
리턴이 perl의 subroutine이든, python의 method이든, 실패했을 경우 그 이유를 알기 위한 메시지를 함께 전달합니다. 실패라면 exception을 함께 전달하는 느낌입니다.
문제없이 진행되어 rc가 성공이라면, rm은 해당 리턴값을 가지게 하는 설계가 많았습니다.
4) 리턴값, 0 = 성공, 1 = 실패
이는 시스템 커맨드의 리턴(batch라면 errorlevel)이 대게 에러번호를 리턴하는데 기인합니다.
개발자로서의 인식으로는 non-zero = true, 0 = false 이기 때문에 checkData와 같은 함수의 리턴이 1(true)라면, OK라는 인식이지만, SE에게는 NG라는 인식입니다.
이는 정의하고 진행하면 되는 것이기 때문에 특별히 문제는 없었습니다만, "음? 성공하면 0입니까? (성공하면 false입니까?)"하고 물었을 때, '음? 당연한 것을 왜묻지?'하는 느낌의 반응은 약간의 이질감을 느끼게 되더군요.
2. 놀라운 시스템 관련 지식.
이것은 말할 것도 없습니다. (모든 SE가 다 그렇지는 아니겠지만) 굉장히 정확한 지식을 가지고 있었습니다.
이런 예가 있었습니다. 한번은 '어떤 명령어 | sed xxxxx'와 같은 외부 프로세스를 실행한 결과를 치환해 값을 받도록 실행하는 코드를 작성한 적이 있었습니다. 이때 다른 명령어는 모두 문제가 없었는데 어느 특정 한 명령어는 프로세스가 종료하지 않고 메모리에 남아 있게 되는 일이 있었습니다.
이를 SE에게 문의했는데, 추적하는 것을 보여주더군요. 값진 경험이었습니다.
우선, ps상 이 프로세스가 defunc가 아니었기 때문에(좀비가 아니었기 때문에) 폭주인지, 아니면 무엇을 하고 있는지 strace를 통해 pid에 걸어서 무엇을 하고 있는지 알아보더군요. 지금까지 나 이외에 strace를 사용하는 것을 '직접' 본 두번째 경험이었습니다.)
우선은 표준입력을 기다리고 있는 것을 알아내어 폭주는 아닌 것을 확인했습니다. 그다음 왜 표준입력을 기다리고 있는지 알아보았는데, 그 '특정 명렁어'가 표준 출력으로 출력하는 것을 모두 /dev/null로 돌려놓고 있었더군요. 결국 sed는 뭔가 파이프로 전해져 오는 것이 없었기 때문에 sed가 입력을 기다리고 있었고, child의 pid를 수확하지 못하고 있기 때문에 parent의 '특정 명령어' 및 shell이 살아남아 있는 것이었습니다.
이때 잠깐 질문을 제가 했는데, sed를 echo로 바꾸면 정상종료하는데, 그 차이를 잘 이해하지 못하다라고 얘기했을 때, 설명을 받았습니다.
이때 그는 파이프 처리에 관련된 설명을 하면서 File Descriptor라는 용어를 사용해 설명하였는데, 나는 시스템 프로그래밍 기사나 책을 읽으면서 몇번 본 적은 있지만, file descriptor라는 단어를 내 입으로 조차 발음해 그 소리를 내 귀로 들은 적이 한 번도 없었는데, 이때 설명받으면서 들은 것이 난생 처음이었습니다.(그만큼 그 개념을 직접 말해 설명하는 것을 듣는 것이 굉장히 드믄 일입니다.)
3. 기타
<작성중>
1) 자기가 작성한 코드는 장해 발생때 대응하는 사람이 살펴보고 긴급히 수정해 대응할 수 있어야 하는 코드
2) '로직을 아직 다 못썼습니다.'
3) '단순한 버그이기 때문에 위치를 알면 곧 수정해 대응이 가능합니다.'
대신 환경(장비상의, 또는 시스템상의) 이나 데이타의 대응이 훨씬 더 큰 일.
Subscribe to:
Posts (Atom)