단지 재미를 위해 :
무엇을 쓰고 있는지 모니터 / 캡처 / 덤프하는 방법이 /dev/null있습니까?
데비안 또는 FreeBSD에서는 중요하다면 다른 OS 특정 솔루션도 환영합니다.
답변
/dev/null명명 된 파이프를 만드는 것이 가장 쉬운 방법 일 것입니다. 일부 프로그램은 (경고한다 sshd, 예를 들어) 비정상적으로 행동하거나 (또는 그들이 읽을 수는 특수 파일이 아닌 것을 발견 할 때 실행 실패 /dev/null가 반환 기대 EOF).
# Remove special file, create FIFO and read from it
rm /dev/null && mkfifo -m622 /dev/null && tail -f /dev/null
# Remove FIFO, recreate special file
rm /dev/null && mknod -m666 /dev/null c 1 3
이것은 모든 Linux 배포판과 모든 주요 BSD에서 작동합니다.
답변
한 번은 / dev / null이 특별한 dev 파일 일 필요 가없는 어려운 방법을 발견했습니다 . 오래 전 직장에서 Ultrix 시스템의 / dev / null이 삭제되었으므로 다음에 프로그램이 / dev / null로 리디렉션 될 때 해당 프로그램의 출력으로 가득 찬 일반 파일이되었습니다. (나는 그것이 그런 파일이나 디렉토리가 아니라고 생각한다. 그것은 우리가 무슨 일이 일어나고 있는지 알아 내려고 할 때, 우리를 지옥에서 혼란스럽게 만든 것을 알고 cat /dev/null들었다 no such file or directory.)
그래서 내 제안은 명명 된 파이프로 교체 한 다음 파이프를 읽고 모니터링하는 프로그램을 파이프에 연결하는 것입니다.
답변
나는 / dev / null이 파일 디스크립터에 대한 심볼릭 링크가 될 수 있지만 작업을 읽거나 쓰도록 결정하는 코드 메커니즘을 추가 한 다음 읽은 경우 실제로는 / dev / actualnull에서 별도로 읽어야한다고 생각합니다. mknod를 작성하고 작성중인 경우 호출 프로그램을 기록하고 / dev / null을 사용하여 작성하는 프로그램을 분석하기 위해 로그 / 카운트를 시도하십시오. 그러나 성능면에서 많은 비용이 듭니다. 어쨌든 대부분의 쉘 프로그램이나 코드가 리디렉션을 사용하기 때문에 실용적이지 않은 것 같습니다. inotify를 사용하여 / dev / null 사용법을 모니터링 할 수 있습니까? 또는 1 : 3 장치를 처리하는 커널 코드를 다시 작성하고 다시 컴파일하고 다시 실험 할 수 있습니다.
