백그라운드 프로세스가 무엇인지 더 잘 이해하고 싶습니다. 이 코드 줄을 읽고 나면 다음과 같은 질문이 생깁니다.
/usr/sbin/rsyslogd -niNONE &
문서는 다음과 같이 말합니다.
-i pid file Specify an alternative pid file instead of the default one. This option must be used if multiple instances of rsyslogd should run on a single machine. To disable writing a pid file, use the reserved name "NONE" (all upper case!), so "-iNONE". -n Avoid auto-backgrounding. This is needed especially if the rsyslogd is started and controlled by init(8).
앰퍼샌드는 &명령이 백그라운드에서 실행되도록 요청하는 것을 의미하는 것 같습니다.여기.
내 이해가 정확하다면 pid 파일데몬과 함께 사용즉, 프로그램이 백그라운드에서 실행 중일 때입니다.
따라서 표면적으로 문제의 명령은 먼저 프로그램이 백그라운드에서 실행되지 않도록 지시한 다음 pid 파일에 NONE을 지정 하여 데몬 1 이 -n아님 을 나타냅니다. 배경.&
나는 이것을 이해할 수 없다. 프로세스가 일반적으로 다른 컨텍스트를 사용하여 입력하는 컨텍스트가 로 전송됩니까 &? 내가 읽은 모든 것에서 배경 뒤에 숨은 유일한 의미는 쉘이 차단되지 않았다는 것입니다. 이런 점에서 프로세스가 자동으로 배경을 설정하지 않고 배경을 설정하도록 요청하는 것은 의미가 없습니다.
여기서 뭔가 빠졌나요? 구체적인 배경은 무엇인가요? (이때 pid 파일 삭제 책임은 누구에게 있나요?)
1 - 문제가 있는 Docker 컨테이너의 컨텍스트에서 pid 파일이 있으면 컨테이너가 중지되었다가 다시 시작될 때 문제가 발생할 수 있습니다. pid 파일을 삭제하는 원인이 무엇인지 명확하지 않으며 일부 소식통에서는 다음과 같이 제안합니다.systemd와 같은 시스템 초기화, 반면 다른 사람들은프로그램의 책임임을 의미합니다.. 그러나 SIGKILL을 사용하여 프로세스를 종료하면 프로그램이 프로세스를 삭제할 기회가 없을 수 있으므로 pid 파일이 이미 존재하지만 존재할 것으로 예상되지 않으므로 후속 컨테이너 다시 시작이 실패합니다.
답변1
UNIX 백그라운드 프로세스의 개념은 작업 제어의 일부입니다. 작업 제어는 터미널 세션 프로세스를 중심으로 구성됩니다.
데몬은 일반적으로 터미널 세션 내에서 실행되지 않으므로 Unix 작업 제어 측면에서 백그라운드 프로세스가 아니며 시스템의 일부인 "보이지 않는" 활동이라는 일반적인 컴퓨팅 측면에서 볼 때 그렇습니다. 이는 rsyslogd문서에서 언급하고 있는 내용일 가능성이 높습니다 . 이는 작업 제어 데몬이 아니라 데몬 프로세스가 되는 것을 의미합니다.
대화형 터미널 세션에서 사용자 관리일하다. 각일하다일부 소프트웨어(보통 작업 제어 셸)에 의해 그룹으로 예약되는 프로세스 그룹(아마도 하나)입니다. 세션의 각 작업에는 터미널이 있습니다.제어 터미널.
백엔드/프론트엔드 개념은 이러한 작업 간의 최종 장치 공유와 관련이 있습니다. 언제든지 프로세스 그룹 중 하나가 포그라운드 프로세스 그룹으로 지정됩니다. 터미널에서 문자를 읽고 출력을 터미널로 보낼 수 있습니다. 다른 프로세스 그룹은 백그라운드 프로세스 그룹입니다.
작업 제어 셸은 TTY의 신호를 특정 기능(예 tcsetpgrp: .
포그라운드 프로세스 그룹은 터미널에서 읽고 쓸 수 있을 뿐만 아니라 TTY에서 생성된 신호(예: SIGINT에서 CtrlC및 SIGTSTP로부터) 도 수신할 수 있습니다 CtrlZ.
일반적으로 CtrlZ작업을 백그라운드로 일시 중단한 다음 작업 제어 명령을 사용하여 bg백그라운드에서 실행되도록 합니다.
을 실행하면 CtrlZ포그라운드 프로세스 그룹의 모든 프로세스가 SIGTSTP신호를 수신하고 일시 중지됩니다. 작업 제어 셸은 이 변경 사항을 감지하고 라이브러리 호출을 통해 작업을 백그라운드로 이동하고그 자체포그라운드 프로세스 그룹. 따라서 쉘은 이제 다시 전경에 있으며 TTY로부터 명령을 받을 수 있습니다.
이제 입장할 수 있습니다배경, 쉘은 백그라운드 작업 실행을 일시 중지합니다.
이것퍼그명령을 실행하면 쉘이 전경에서 자신을 제거하고 백그라운드 작업을 다시 전경으로 가져옵니다.
백그라운드 작업은 TTY(예: SIGINT에서) 로부터 문자 기반 신호를 수신하지 않습니다 CtrlC. 그러나 터미널에서 읽거나 쓰려고 시도하면 유사한 신호를 수신 SIGTTOU하고 해당 작업 수행이 차단됩니다.
직무 통제는 터미널 접근을 보호하는 교통경찰과 같습니다.
GUI의 창 관리와 유사합니다. 일반적인 GUI에서 창에는 "키보드 포커스"가 있습니다. 키를 누르면 이런 창이 뜹니다. 작업 제어도 마찬가지입니다. 포그라운드 프로세스 그룹에는 말하자면 "터미널 포커스"가 있습니다.
문서 rsyslogd에서는 실제로 "데몬이 되다" 또는 "데몬화하다"를 의미하기 위해 "백그라운드"라는 용어를 사용하는 것이 거의 확실합니다. 이는 POSIX 작업 제어의 "백그라운드 작업"과 다릅니다.
서버 애플리케이션이 자동으로 데몬화되면 이는 터미널 세션에서 실행 중인 경우 해당 세션에서 자신을 제거하기 위한 조치를 취한다는 의미입니다. 자식과 손자를 포크합니다. 자식 프로세스가 종료되므로 손자는 고아가 되어 init데몬의 자식이 됩니다. 이것은 그것의 일부입니다. 다른 부분은 Sun Tzu가 표준 입력, 출력 및 오류 파일 설명자를 닫는 것입니다. 따라서 TTY와의 연결이 끊어집니다. 특정 작업 디렉터리로 변경하는 등의 다른 작업도 수행될 수 있습니다.
rsyslogd에 의해 실행되면 자체적으로 데몬화되지 않습니다. 이는 init분리할 터미널 세션이 없기 때문에 의미가 있습니다. (단, rsyslogd터미널 세션의 일부가 아닌 것으로 감지될 수 있으며 이 경우 플래그가 필요하지 않습니다 -n.)
따라서 실제로 서버에서 do-not-daemonize 명령줄 옵션의 주요 용도는 다음과 같은 이유로 디버깅을 위한 것입니다.
어쩌면 데몬에 디버그 추적 모드가 있고 메시지가 표준 출력으로 전송될 수도 있습니다. 콘솔에서 이러한 메시지를 보려면 데몬이 표준 출력 파일 설명자를 닫는 것을 원하지 않습니다.
디버거에서 데몬을 디버깅하려는 경우 그냥 종료되면 실제 데몬 활동이 분기된 손자에서 발생하므로 불편합니다.
CtrlC테스트할 때 를 사용하여 데몬을 종료 하거나 를 사용하여 일시 중지하는 등 데몬에 작업 제어를 적용할 수 있습니다 CtrlZ.
때때로 사람들은 서버가 터미널 세션에서 실행되는 터미널 멀티플렉싱 소프트웨어(예: GNU Screen 또는 Termux)에서 서버를 실행하기를 원합니다. 자동 데몬은 자신의 목적을 무너뜨립니다.
PID 파일 삭제 책임이 있는 사람: 주로 서비스 애플리케이션 자체(완전히 종료된 경우). 일부 마스터 프로세스가 서비스를 관리하는 경우 PID 파일의 경로를 알고 파일을 삭제하지 않고 종료되면 정리할 수 있습니다. PID 파일은 일반적으로 재부팅 시 지워지는 디렉터리에 배치됩니다. 따라서 /var/run예를 들어 시스템에 심각한 오류가 발생하여 재부팅해야 하는 경우 재부팅 시 PID 파일이 처리됩니다.