☰

/dev/null로 전송되는 내용을 모니터링하시겠습니까?

tag-icon • tag-icon monitoring devices open-files
/dev/null로 전송되는 내용을 모니터링하시겠습니까?

재미삼아
작성 중인 내용을 모니터링/캡처/덤프할 수 있는 방법이 있나요 /dev/null?

Debian이나 FreeBSD에서는 중요한 경우 다른 운영 체제별 솔루션도 환영합니다.

답변1

명명된 파이프를 만드는 것이 /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에서 작동합니다.

답변2

나는 한때 /dev/null이 하지 않는 어려운 방법을 발견했습니다.가지다특수 개발 파일이 됩니다. 오래 전에 /dev/null은 작동 중인 Ultrix 시스템에서 제거되었으므로 다음에 프로그램이 /dev/null로 리디렉션될 때 프로그램의 출력으로 채워진 일반 파일이 되었습니다. (제 생각에는 "해당 파일이나 디렉터리가 없습니다"라고 생각합니다. 이는 우리가 이 작업을 수행 cat /dev/null하고 무슨 일이 일어나고 있는지 알아내려고 할 때 알려주는 내용을 의미 no such file or directory하므로 혼란스럽습니다.)

그래서 내 제안은 이를 명명된 파이프로 바꾸고 파이프에 프로그램을 연결하여 읽고 모니터링하는 것입니다.

답변3

나는 /dev/null이 파일 설명자에 대한 심볼릭 링크가 될 수 있다는 아이디어를 생각해 냈지만 추가된 코드 메커니즘을 사용하여 작업이 읽기인지 쓰기인지 확인한 다음 읽은 경우 실제로 다음에서 생성되어야 합니다. 별도의 /dev /actualnull은 mknod를 읽고, 기록된 경우 호출 프로그램을 기록하고 쓰기에 /dev/null을 사용하는 프로그램을 분석하기 위해 로그/카운트를 시도합니다. 하지만 성능면에서는 큰 비용이 든다고 생각합니다. 어쨌든 대부분의 쉘 프로그램이나 코드는 리디렉션을 사용하기 때문에 이것이 비실용적이라고 생각합니다. /dev/null의 사용량을 모니터링하기 위해 inotify를 사용할 수 있습니까? 또는 1:3 장치를 처리하는 커널 코드를 다시 작성하고 다시 컴파일하고 다시 설치하여 실험할 수 있습니다.

관련 정보