프로토콜에 관한 한 systemd-journald…
- …라는 스트림 소켓의 리스너입니다
/run/systemd/journal/stdout. systemd는 원시 표준 출력 및 서비스의 오류 (기본값으로 또는 명시 적으로 StandardOutput=journal/가있는 StandardError=journal)를이 소켓에 연결합니다. 따라서 줄 바꿈으로 종료 된 가변 길이 자유 형식 레코드의 프로토콜을 수신합니다.
- ...라는 이름의 데이터 그램 소켓의 청취자입니다
/run/systemd/journal/dev-log상징적에 링크된다 /dev/log. 이것은 syslog()어플리케이션에 링크 된 GNU C 라이브러리 의 라이브러리 기능이 말하는 프로토콜을 수신합니다 .
- …라는 데이터 그램 소켓에서 수신 대기하는 다른 서비스의 클라이언트가 되려고합니다
/run/systemd/journal/syslog. 이것은 또한 syslog()GNU C 라이브러리 의 라이브러리 함수가 말하는 프로토콜을받습니다 ( systemd-journald실제로 다른 라이브러리와 다른 함수를 사용하여 말하기도 함).
- …라는 문자 장치의 리더입니다
/dev/kmsg. 이것은 Linux 커널이 말하는 프로토콜을 수신하는데, 이는 가변 길이, 대부분 자유 형식의 레코드로 줄 바꿈으로 종료 된 프로토콜입니다.
- …라는 데이터 그램 소켓의 리스너입니다
/run/systemd/journal/socket. 이것은 애플리케이션이이 소켓에 특정 프로토콜을 말하는 라이브러리에 링크한다는 점에서 GNU C 라이브러리의 경우와 유사합니다. 함수가 sd_journal_sendv()인 경우를 제외하고는 응용 프로그램이 연결되는 시스템 C 라이브러리에 있으며 프로토콜은 표준화되어 있지 않지만 각 데이터 그램에서 키 = 값 쌍의 배열과 선택적으로 읽을 수있는 파일 설명자를 포함하는 시스템 전용 프로토콜입니다 .
syslog()GNU C 라이브러리 의 함수가 사용하는 프로토콜 은 RFC 5424 또는 RFC 3164가 아니며 사실상 자체 표준입니다. RFC 5424가 아닙니다. 올바른 양의 공백이없고 대시가 NIL 값이있는 선택적 필드를 지정하기 때문입니다. RFC 3164가 아닌 PROCID필드 가 있으므로 RFC 3164가 아닙니다 HOSTNAME.
몇 년 전에 시스템 운영 체제는 다음을 수행했을 것입니다.
systemd-journald위의 모든 (그리고 프로토콜 과 관련이없는 것들 )을 수행하고 GNU C 라이브러리와 시스템 C 라이브러리가 각각의 프로토콜을 사용하여 통신하는 서버- 선택적인 syslog 또는 rsyslog 또는 syslog-ng 프로그램, 무언가가 열려있는 파일 디스크립터로서 소켓에 메시지를 보내고 소켓을 수신 하려고 할 때
xinetd/ inetd-style /run/systemd/journal/syslog또는 해당 파일을 열고 청취하도록 구성된 직접 서비스 /run/systemd/journal/syslog(/ rsyslog) imuxsock모듈; GNU C 라이브러리 프로토콜 말하기
- RFC 5426 트래픽을 수신 대기하는 선택적 syslog 또는 rsyslog 또는 syslog-ng 또는 udp-syslog-read 서비스
요즘 시스템 운영 체제에는 다음이 있습니다.
systemd-journald 위의 모든 작업을 다시 수행하고 GNU C 라이브러리와 시스템 C 라이브러리가 통신하는 서버 - 선택적 rsyslog 프로그램은 소켓을 통하지 않고 직접 서비스로 호출되며
imjournal모듈을 사용하여 시스템화 된 저널 파일에서 직접 내용을 읽습니다.
- RFC 5426 트래픽을 수신 대기하는 선택적 syslog 또는 rsyslog 또는 syslog-ng 또는 udp-syslog-read 서비스
추가 자료