극히 개인적이고 극히 대단하지 않은

환경은 ubuntu 20.04이다. 현장의 장비가 원인없이 reboot되는 경우가 있어서 kdump를 설정했다. 구글링한 정보들을 짜맞춰서 정상적으로 설정이 된 것 같은데 문제가 발생했을 때, reboot이 아니라 hang이 발생하고 crash정보도 생성되지 않아 더 난감한 상황에 빠진 적이 있다. 정상적으로 kdump가 설정된 것은 다음과 같은 정보들로 확인했다. USE_KDUMP가 1이고, current state가 ready to dump이면 kdump가 생성될 조건이 되었을 때, 생성이 되어야 하는 것이다. 이런데도 불구하고 kdump가 생성되지 않는다면, kdump를 위한 메모리 확보가 충분하지 않아 그럴 가능성이 높다. 콘솔에서 다음과 같은 부분이 발견된다면 더더욱... [ 3.598311] ..

언젠가는 좀 상세하게 정리해야 겠지만, 그렇게 할 시간을 내기 전에 간단히, 잊어버리지 않을 정도로 기록을 남길 필요가 있어서 정리해둔다. 다수의 클라이언트에서 주기적으로 같은 시간 대에 데이터를 받아 처리하는 서버를 구현중이다. 클라이언트가 120대 정도 예상하고 있으니 최대 동시에 120 커넥션을 처리해야한다. 이러한 환경에서는 특정 커넥션에서 행이 발생한다던가 그로 인하여 다른 커넥션 및 시스템 전반에도 영향을 준다던가 하는 상황을 만들지 않기 위해, nonblock 소켓을 epoll 로 정확하게 제어하는 것에 매우 신경을 쓰게된다. 기본적인 시험을 통해서는 nonblock 소켓과 epoll 구현이 정확하게 예상대로 잘 동작함을 확인하였고, 120개의 클라이언트를 시뮬레이션할 시뮬레이터를 작성하여 ..

Multithread program을 작성하고 버그를 잡다보면 thread의 pid를 알아야 간지러운 곳이 해결되는 경우가 있다. 특히 gdb를 이용해서 디버깅을 하는 경우에 아쉬울 때가 많다. 그런 경우에는 thread 내부에서 다음과 같은 코드를 수행하면 자신 thread의 pid를 알 수 있다. syscall(__NR_gettid) 예를 들어 다음과 같이 코딩을 하면 thread 이름과 pid를 확보할 수 있다. #include #include #include void *sample_thread (void *arg) { ... printf ("Thread Information :: [%s][%d]\n", __func__, syscall(__NR_gettid)); ... pthread_exit (NU..

C로 프로그램을 작성하고 시험을 하다보면 수없이 많은 core 파일을 만나게 되는 경우가 있다. core 파일은 개발자 입장에서 별로 만나고 싶지 않은 파일이긴 하지만, 정상적으로 동작하지 않는 프로그램과 긴긴 시간을 씨름할 때에 있어서 core 파일은 때로는 사막에서 오아시스를 만나듯이 반가운 경우도 있다. core파일을 얼마나 능수능란하게 다루고 요긴한 명령들을 조합해서 잘 쓰는가에 따라 core파일은 개발자에게 문제를 해결할 수 있는 명쾌하고 직관적인 정보를 주기도 하지만, 그렇지 않은 경우에는 문제점에 더불어 해결해야 할 숙제를 하나 더 떠안은 것 같은 부담으로 작용할 수도 있다. core파이을 분석하기 위해 다양한 명령어를 쓰지만, 흔히 쓰지 않으면서도 알고 있으면 도움이 될만한 명령을 소개한다..

귀차니즘의 극을 달리다가 드디어 정리한다. 뭐 그리 중요하거나 대단한 기술은 아니지만, 더 머리가 굳어가기 전에 남겨두는 게 맞을 것 같아서... 코드를 작성하고 디버깅을 하다보면, 코드 어디 쯤 실행이 되고 있는 것인지 확인하는 가장 좋은 방법이 로그를 찍어보는 것이다. 그런데, 간혹 다른 사람의 코드를 디버깅하다보면 'return NOK!' 라는 출력이 있어 여기 쯤 문제가 있겠구나 하고 추정을 하게되고 'return NOK!' 라는 문자열을 소스에서 찾아보게 되는데, 'return NOK!' 라는 문자열이 이런 저런 소스에 분산되어 한 200군데에 있다면, 정말 짜증이 나지 않을 수 없다. 개인적으로 간단하게 로그의 위치를 확인하기 위해서는 잘 알려진 방법인 __func__와 __LINE__ 매크로..

워낙 밑바닥 코딩을 하다보니, 생성된 바이너리를 정말 맨땅에 부딪히는 느낌으로 까봐야할 때가 종종 있다. 이 경우 유용하게 쓰이는 것이 xxd 명령이다. 제일 간단한 사용방법으로 'xxd 파일이름' 을 입력하면 그 파일을 hexa모드로 덤프해서 출력한다. 폭이 좁아 보기 불편한 경우에는 -c 컬럼수 옵션을 추가하여 컬럼 수를 변경할 수 있다. (입력하지 않으면 default 16) xxd명령은 vi에디터에서도 연결하여 사용할 수 있다. 우선 편집하고 싶은 바이너리 파일을 vi로 연다. 파일을 열면 알수없는 암호코드같은 문자열로 인하여 알아볼 수 없는 화면이 나타난다. 다른 자료에는 hexadump모드로 열기 위해 vi에 -b (binary)옵션을 줘야하는 것으로 설명하는데 굳이 -b 옵션을 주지 않아도 ..

리눅스에서 strace로 프로세스를 추적하다보면 출력문의 길이가 짧아 그 내용을 파악하기가 어려운 경우가 있다. strace 옵션으로 -s 출력문길이를 추가하면 출력문의 내용을 더 길게 출력할 수 있다. 옵션을 주지 않았을 때에는 기본값 32가 적용된다.

dmidecode help 여기서 -t 옵션에 대한 내용만 정리한다. dmidecode에서 관리하는 device type은 아래와 같이 정의되어 있다. -t 옵션과 함께 위의 device type을 지정하면 상당히 유용한 정보들을 획득할 수 있다. dmidecode 명령과 grep, awk 등과 같은 명령을 파이프로 묶으면 매우 편리하게 원하는 값을 프로그램에서 활용할 수 있다. 예제) 시스템에 설치된 메모리 뱅크와 메모리 실장상태 dmidecode -t 17 | grep Size 시스템에 4개의 메모리 뱅크가 있고, 첫번째 뱅크에 8GB 메모리 모듈이 설치되어 있음. 예제) CPU 정보확인 dmidecode -t 4 | grep Version