반응형

테스트한 OS: Ubuntu 12.04

쉘(shell): bash



* grep만 이용하는 방법


리눅스에서 파일 내에 있는 특정 문자열을 검색할 때 쓰는 grep에 옵션을 더하면 현재 위치에서 하위 디렉토리에 있는 파일들까지 검색을 수행할 수 있다. Ubuntu에서는 grep가 하위 폴더 검색까지 지원하기 때문에 아래와 같이 간단하게 해결할 수 있다.


$ grep -rn "찾고자 하는 문자열" *


-r 옵션은 하위 디렉토리에 있는 파일까지 검색하겠다는 것이고,

-n 옵션은 라인 번호를 보여주는 것이다.

그리고 검색하는 문자열에 공백이 있다면 앞뒤에 따옴표가 반드시 있어야 한다.


그냥 저렇게 실행하면 검색결과보다 "No such file or directory"와 같은 오류 메세지가 더 많이 뜨는 경우도 있다. 이 때는 명령에 "2> /dev/null"을 붙여서 검색 결과만 남겨 두고 에러 메세지는 보이지 않도록 처리할 수 있다. 아래 그림은 openwrt의 build_root 디렉토리 하위의 모든 파일들에 대해서 "setup_fname_info(struct"라는 문자열을 검색한 결과이다.





* find와 grep를 같이 이용하는 방법


그런데 리눅스 배포판에 따라서 grep의 하위 디렉토리 검색이 안되는 경우도 있다고 한다. 어디서 안되는지는 사실 모르겠다. 라우터에 들어가는 매우 가벼운 OpenWRT에서조차 -rn 옵션이 작동하는데 어디서 안되는 것일지?

어쨌든 조금 길고 복잡하지만 같은 목적을 갖는 다른 방법으로 find를 같이 이용하는 방법이 있다.


$ find . -name "*" | xargs grep -n "찾고자 하는 문자열"


참고로 grep와는 달리 find를 쓸 때의 좋은 점은 정규식을 통해서 검색할 파일의 범위를 지정할 수 있는 것이다. 예를 들면, 하위 디렉토리의 모든 .c 또는 .h 파일에 대해서만 검색을 수행하고자 할 때 아래와 같이 할 수 있다.


$ find . -name "*.[ch]" | xargs grep -n "찾고자 하는 문자열"



앞선 예제와 같은 조건에 대해서 find를 이용한 검색 화면은 아래와 같다. 참고로 맨 끝에 붙인 "--color=auto" 옵션은 텍스트와 라인 번호, 키워드 강조 색상을 주기 위해서 필요하다. "--color=auto" 옵션이 없으면 그냥 단색의 결과만 나타난다.




참고로 위의 grep -rn과 달리 검색결과가 3개만 나오는 이유 2가지는 다음과 같다.

 

 - 확인 결과 grep에서 나온 첫번째와 두번째 검색 결과는 같은 파일이다. 경로상에서 보면 build_dir/toolchain-mips_34kc_gcc-4.6-linaro_uClibc-0.9.33.2/linux-3.10.32는 실제로 존재하는 경로이고, build_dir/toolchain-mips_34kc_gcc-4.6-linaro_uClibc-0.9.33.2/linux는 같은 위치에 대한 바로가기 링크이다. 즉, grep는 링크도 무시하지 않고 똑같이 하위 디렉토리로 간주하고 검색한다는 얘기.


 - "xmit.c~" 파일은 xmit.c의 백업 파일인데 확장자가 "c~"기 때문에 c와 h 파일만 찾는 정규식에 의해 검색에서 제외되었다.



반응형
블로그 이미지

Bryan_

,
반응형

<테스트한 환경>

OS: Ubuntu 11.04 Desktop (32bit, kernel 2.6.38-8-generic)

네트워크 인터페이스: TP-LINK TL-WN722N (802.11b/g/n)



연구실험 목적으로 와이파이 무선 애드혹 네트워크를 구성해서 쓰면서 유난히 연결이 안되는 경우가 자주 있었는데, 경험을 바탕으로 몇 가지 원인을 나열해 보고자 한다.



(1) Ubuntu desktop의 Network Manager 서비스와 /etc/network/interfaces 파일 간의 설정 불일치


고정IP와 채널 설정 등 가장 확실하게 설정할 수 있는 방법은 우분투(Ubuntu)를 기준으로 /etc/network/interfaces 파일을 수정하는 것이다. 그런데 Ubuntu desktop에서 쓰는 서비스인 network-manager는 /etc/network/interfaces 파일을 참고하지 않고 별도로 설정을 보관한다. 즉, network manager에서 그래픽 유저 인터페이스(GUI)를 이용해서 설정을 변경하더라도 /etc/network/interfaces 파일에 반영되지는 않는다.

반대로 /etc/network/interfaces 파일을 수정하면 network-manager의 상태 메세지가 그 변경 내역을 반영하는 것 같지만, 별로 신뢰가 가지 않는다. 가끔 network-manager가 오작동을 하면서 시스템 전체가 다운되는(커널 패닉; kernel panic) 현상도 겪었다.


개인적으로는 network-manger 서비스를 삭제해 버리고, 오직 /etc/network/interfaces 파일을 통해서만 모든 네트워크 설정을 하는 것을 추천한다. 그래픽 인터페이스가 아니라서 직관적이지는 않겠지만, 이것이 오작동 없이 설정하는 가장 확실한 방법이다. 우분투에서 network-manger 서비스 삭제는 아래와 같이 할 수 있다.

$ sudo apt-get remove network-manager


만약 network-manager를 삭제하는 대신 일시적으로 서비스를 중단하고 싶다면 service disable 명령어를 이용한다.

$ sudo service network-manager disable




(2) 다른 유선/무선 네트워크 설정과 같은 IP주소 대역을 쓰는 경우


별 생각 없이 애드혹 네트워크를 구성하면서 고정IP 주소를 192.168.0.X 또는 192.168.1.X를 쓰는 경우가 많이 있다. 하지만 대부분의 경우 공유기를 통해 연결하는 유선랜 연결에서 할당받는 유동 IP 주소가 대부분 192.168.0.X 또는 192.168.1.X라는 사실을 염두에 둬야 한다.

필자의 경우 무선 와이파이는 애드혹 네트워크로 설정하고 유선랜은 원격 ssh 접속 및 디버그 용도로 쓰려고 했는데, 공교롭게도 유선과 무선이 같은 대역의 IP 주소를 쓰는 바람에 기대하던 대로 연결되지 않는 현상을 겪었다.

애드혹 네트워크를 고정IP로 쓰는 경우, (게다가 애드혹 모드에서 고정 IP를 쓰지 않으면 제대로 연결되지도 않음) 다른 네트워크과 서브넷(subnet) 주소가 겹치지 않도록 주의하자. (예를 들어, 192.168.3.X 대역을 쓰는 식으로 주소를 확실하게 구분할 것)




(3) Cell 정보가 잘못되어서 생기는 문제


애드혹 네트워크의 경우 고정된 게이트웨이(공유기의 역할)가 따로 있지 않지만, 설정상으로는 가상의 게이트웨이처럼 Cell 정보를 갖고 있다. 콘솔에서 iwconfig를 입력하면 맥 주소 형태로 된 cell 정보를 확인할 수 있다. 같은 애드혹 네트워크에 있는 모든 노드가 같은 cell 정보를 공유한다.


(iwconfig 명령을 통해서 확인할 수 있는 애드혹 네트워크의 각종 정보. 밑출 친 부분이 Cell 정보이다.
Cell 값은 특정 노드의 맥주소는 아니고, 재구성할 때마다 임의의 값을 할당받는 것으로 보인다.)


아직 정확한 원인은 모르지만, 설정상 전혀 이상이 없는데도 갑자기 애드혹 네트워크 상의 노드들끼리 전혀 통신을 못하는 경우가 있다. 그래서 각 노드를 하나씩 네트워크 재설정도 해 보고,  (sudo /etc/init.d/networking restart) 각 노드를 재부팅도 해 봤으며, USB 무선랜 카드를 뽑았다가 다시 연결하기도 했지만 여전히 되지 않았다.


확인해본 결과 노드를 하나씩 재설정/재부팅해서는 안 된다. 아마 Cell 정보에 문제가 있었던 것 같은데, 장비를 하나씩 재시작하면 네트워크가 켜져 있는 다른 노드가 계속 기존의 설정을 유지하고 있기 때문에, 그 노드로부터 잘못된 정보를 받아 와서 다시 공유하게 된다. 그러므로 확실하게 하려면, 모든 노드가 다같이 전원을 껐다가 켜야 한다. (애드혹 네트워크를 완전히 없앴다가 다시 만들자는 얘기) 이렇게 하면 iwconfig를 통해서 Cell 정보가 변경된 것을 확인할 수 있으며, 다시 노드들끼리 정상적으로 통신이 된다.




(4) 신호 세기와 물리적인 공간 특성으로 인한 문제


필자의 경우 넓은 지역에 먼 거리를 두고 노드를 배치할 필요가 없어서 이 문제가 치명적이지 않았다. 하지만 건물 안에서 멀티홉(multi-hop) 네트워크를 구성하기 위해 복도와 방을 이용해서 배치해본 결과, 벽과 코너의 구조로 인해서 신호를 받지 못하거나 신호가 미약한 상황을 만들어낼 수는 있었다. (사족: 하지만 결국은 실내 공간에서 물리적인 배치만 가지고 멀티홉 네트워크 만들기는 실패했다. 왜냐하면 어떻게든 미약한 신호가 닿을 경우 한번에 연결하려고 하지 중간 노드를 통해서 가려는 시도를 안하기 때문이다. ㅠㅠ 결국 라우팅 프로토콜에 약간의 예외처리를 해서 소프트웨어적으로 멀티홉을 구성해야 했다.)


필요에 따라 신호 세기를 조정해서 전송 범위(transmission range)를 바꿀 수 있다. 신호 세기가 세면 당연히 전송 범위가 늘어난다. 신호 세기는 아래와 같이 조정할 수 있다.

$ sudo iwconfig [네트워크_인터페이스_번호] txpower [신호세기]


신호 세기의 단위는 dBm이며, 0~20 사이의 값만 허용된다.


(iwconfig를 이용해서 신호 세기를 4dBm으로 설정한 경우)


또한 무선랜에서는 data rate가 낮을 수록 또한 전송 거리가 늘어나기도 한다. 그러나 아쉽게도 애드혹 모드에서는 data rate 설정을 변경할 수 없으니 참고하자.







반응형
블로그 이미지

Bryan_

,
반응형

이 글에서는 리눅스 커맨드 라인에서 특정 디렉토리의 용량을 확인하고, 이를 활용하여 특정 용량 이상의 디렉토리를 검색하는 방법을 설명한다.



특정 디렉토리의 용량 확인하기


리눅스에서 특정 디렉토리의 용량을 확인하려면 du 명령어를 쓰면 된다.


$ du -s [디렉토리_이름]


참고로 -s 옵션은 디렉토리의 하위 디렉토리에 있는 파일들의 용량을 합산하여(summarize) 보여주는 옵션이다. "-s" 옵션을 빼면 디렉토리 내부의 모든 하위 디렉토리의 용량을 보여준 후, 마지막으로 검사하는 디렉토리의 용량을 보여준다.


아래 그림은 du -s를 이용하여 "mc_sc" 디렉토리의 용량을 얻어온 결과이다.


다음 그림은 du만 가지고 "mc_sc" 디렉토리를 검사하였다. 그 결과, 하위 디렉토리를 모두 검사하여 용량을 표시한 후에 마지막으로 mc_sc의 용량을 계산하였다.





특정 용량 이상의 디렉토리 찾기


앞서 살펴본 du -s를 응용하여 wildcard 문자(*)를 쓰면, 현재 위치에 있는 모든 디렉토리의 용량을 찾을 수 있다. 앞서 예제로 확인한 위치에서 du -s * 명령을 친 결과는 아래 그림과 같다. ILQR_exp_data 디렉토리 바로 하위에 있는 디렉토리들에 대해서 각각 합산된 용량을 보여주는 것을 알 수 있다.



그러면 이 중에서 100MB 이상의 용량을 가지는 디렉토리만 보려면 어떻게 할까?

파이프라인(|)으로 awk 명령을 추가해서 출력 결과를 필터링함으로써 이 목적을 달성할 수 있다. 출력 결과의 첫번째 열이 용량을 보여주는 숫자로 되어 있으므로, 첫번째 열의 변수 값($1)이 특정 숫자보다 크도록 조건을 걸면 된다.


아래 명령은 현재 위치에서 100MB 이상의 용량을 갖는 디렉토리를 보여준다. 참고로 뒤의 숫자는 킬로바이트(KB, kilobyte) 단위이다.


$ du -s * | awk '$1 > 100000'


위 명령을 실행한 결과는 다음 그림과 같다.



반응형
블로그 이미지

Bryan_

,
반응형

OS: Linux 11.04 (32bit)

확인해본 USB 무선랜카드: IPTIME (Ralink) RT2501/RT2573 Wireless Adapter, IPTIME N150UA (Ralink RT3070)


노트북에 USB 무선랜카드를 하나씩 추가해서, 멀티 라디오 라우팅을 테스트하다 보면 가끔 USB 무선랜카드로부터 아무 패킷도 받지 못하는 현상이 발생한다.

이 때 ifconfig를 통해서는 무선랜 인터페이스가 정상적으로 인식되며, 고정IP도 정상적으로 세팅되어 있다. 하지만 프로그램 상에서 테스트해 보면 아무 패킷도 받지 못할 뿐더러 아무 패킷도 보내지 못한다.


확실치는 않지만, 그 때마다 iwconfig를 통해서 보면 애드혹 네트워크에서 ESSID 영역이 "Not associated"로 되어 있었던 것 같다. 단순히 노트북을재부팅하는 것만으로는 여전히 위와 같이 먹통인 상태인 것을 확인했다.


현재로써는 두 가지 해결방법이 가장 무식하지만 가장 확실하다.

1) USB 무선랜카드를 분리하고 잠시 있다가 다시 연결 (USB plug out + plug in)

2) 노트북을 재부팅하지 말고, 아예 전원을 완전히 껐다가 다시 부팅 (shutdown + turn on)


전공이 전자과도 아니고 장비에 익숙하지 않아서 원인을 알 수 없지만,

굳이 추측하자면 컴퓨터에 연결된 채 오랫동안 많은 명령(사실 많은 트래픽도 아니다. 나는 단지 라우팅 프로토콜을 구현해서 plain text 형태의 라우팅 메세지, ping 메세지 정도만 반복적으로 주고받았으니까.)을 보내다 보면 여전히 낮은 확률이지만 먹통 현상이 발생한다.




반응형
블로그 이미지

Bryan_

,
반응형

간혹 시스템에서 아주 긴~ log파일 같은 것을 확인해야 할 때가 있는데, vi를 굳이 열어서 맨 끝까지 이동하는 것보다는 계속 기록되고 있는 log파일의 맨 끝부분만 화면을 통해 보는 것이 더 편할 때가 있다.
그럴 때는 tail [filename]을 치면 파일의 맨 끝에서부터 10줄을 화면에 보여준다. 보여지는 줄 수를 변경하고 싶으면 -n 옵션을 통해서 조정 가능하다.

$ tail [filename] -n [라인 수]


추가로, 실시간으로 갱신되어 저장되는 로그 파일의 경우에 변경된 내용을 실시간으로 화면상에서 보고 싶으면 옵션에 "-f"를 추가해 준다.

tail [filename] -f -n [라인 수]

반응형
블로그 이미지

Bryan_

,