현재까지 풀지 못한 숙제들...허허..

1. 주의사항

읽으시는분들께는 외람되고 실례되는 말이옵니다만,

저는 일반적인 질문이나, 방법이 있는 것은 질문을 올리지 않습니다.

충분히 찾아 본듯한데,  아직도 찾지 못한 방법이 있을 가능성이있기에,

혹은 제가 게을러 찾지 못한 또 다른 방법이 어딘가 존재할 가능성도 있기에

그리고 여러분의 머릿속에 더욱 심오한 방법이 존재하기에 여러분의 답변을 기다립니다.

다만 실험 및 경험에 의한 답변이 아닌 이상 답변은 자제해 주시기 바랍니다.

미리 답변에 대한 감사의 말씀을 드립니다.

2. 해당 조건

   a. use only the bash shell script for Kernel & System Independence

      c code라면 쉽게 결론을 도출해 낼수 있습니다. (make utility or device driver)

      제가 사용하기 위해서가 아니라 사용자측에서 수정이 쉽게 하기 위해서 shell script를 채택했습니다.

   b. rebuild 및 edit 없는 적용이 가능해야함

3. 질문들

[1] pid 및 ppid 들

수행방식에 대해서..

   실행 : a.sh "control-commands"

   a.sh에서 control-command에 의하여 여러가지 조건 분기를 통하여 b.sh등을 background forking을 수행함

   이때, control-command와 그 외 조건 분기에 의하여 b.sh등의 수행에 사용될 control-command를 remake

   b.sh "remaked-control-command"에 의하여 c.sh등의 스크립트를 다시 background forking을 통해 수행

   결론적으로 프로세스에 남는 스크립트는 c.sh뿐이게 됨 (아주 여러개가 남음)

   이때, pid와 ppid의 도출을 통한 프로세스에 command 제어가 가능한 방법이 없을지요?

   (주, 프로세스 이름과 실행인자는 같은데, 각각의 내부에 고유한 상태값을 가지고 있게 됩니다.)

   pid와 ppid만 알게 된다면, /proc을 통해 간단히 처리할수 있을 거라고 생각됩니다만..

   pid나 ppid를 잡을 때, process grep으로 처리하라는 것은 명확한 방법이 되지 않습니다.

   (보통 proc을 이용하거나 file을 이용하라는 답번을 다실것으로 예상되는데, 명확치 못합니다.)

   (단시간내 여러 프로세스가 background forkiing 처리가 진행되므로 process indexing 방법이 옳다고 볼수는 없습니다.)

   (또한 그 내부값이 어떻게 변해있는지는 아무도 모릅니다. 오직, 메모리만 압니다. )

결론적으로 알고 싶은 것..

    pid와 ppid를 얻되, 부하나 지연없이 사용할수 있는 ps를 사용하지 않는 다른방법이 존재하는가? 입니다.

[2] message grepper

수행방식에 대하여...

   /var/log/about-message_files이 존재하는데,  이 로그 파일들에 여러가지 메시지가 1초에 수천개씩 찍힙니다.

  이때, 필요한 메시지를 pattern-matching하여 뽑아냈습니다. 헌데, 이를 특정 다른 파일에 저장을 하고 싶습니다만,

  해당 서버가 실제 부하를 아주 많이 가지는 서버이며, 불안정해질 가능성이 높습니다.

  이로 인하여 redirection을 해도, 마지막에 buf에 남는 값과 cache에만 적용된 값은 저장되지 않습니다.

  (파일자체에 남기기는 하는데, 이는 cache된 memory에 남는거지 실제로는 delayed-write 입니다.)

  (수천억 분의 1이 될지도 모르는 하나의 error를 위해서 delayed-write를 포기할 수도 없고..)

  (이때 서버 부하도를 고려하면, delayed-write를 고집해야하고..)

  (Disk I/O의 지연 시간으로 인하여 , 실제 존재하는 오류부분이 불안정성의 오류를 범하고 있기도 합니다.)

  (물론, char device를 작성하여, 즉시 다른서버로 Send 시킬수있는 방법도 있기는 하지만,  조건에 위배됩니다.)

  kernel 튜닝 관련 job을 할때, 서버는 core file도 남기지않고 auto-reboot되어있는데, 그 원인이 되는 부분에 메시지가

  찍히지 않는 일은 흔히 겪는 일이겠지요. 그래서 적어도 line 단위로 about-message_file의 내용을 take 하고 싶습니다.

미래에..

   this process -> kernel hardenning -> report to other log server

   부족한게 많기는 한데 가능할지요.. (심심할때 가끔 공부중)

머나먼 장정같은 길이라 읽으시는데, 수고많으셨습니다.

차분한 마음으로 답변을 기다리도록 하겠습니다.

읽어주셔서 감사합니다.