☰

사용자가 로그아웃한 후 `User=` 지시어를 사용하는 Systemd 서비스가 정리되지 않도록 확인하세요.

tag-icon • tag-icon systemd
사용자가 로그아웃한 후 `User=` 지시어를 사용하는 Systemd 서비스가 정리되지 않도록 확인하세요.

세부 사항

systemd다음과 같은 관련 지시어가 포함된 서비스 파일이 있습니다 .Type=forking User=me Restart=always

WantedBy이 지시어는 아직 설정되지 않았습니다.

실행할 cron 작업이 있습니다 su –l me –c '<some command>'.

전제조건

우리는 다음을 발견했습니다:

  • 서비스가 시작되었습니다
  • 사용자 me는아니요로그인 시스템

관찰 결과

cron 작업 실행이 완료될 때마다 System V IPC 대기열이 사라지고 서비스가 다시 시작됩니다. 대기열에서 읽기/휴면 중인 프로세스가 깨어나서 대기열이 사라져서 실패 상태가 된 것을 발견하기 때문입니다.

cron 작업이 완료된 후 시스템 로그에서 다음 내용을 확인했습니다.
… systemd[1]: Stopped User Manager for UID XXX

가능한 해결책

우리의 installed파일은 다음과 같습니다:

$ cat /etc/systemd/logind.conf.d/my-service.conf
[Login]
KillUserProcesses=no
RemoveIPC=no

질문

읽고 나서시스템 변경 로그 230, 위에서 언급한 가능한 솔루션이 충분한지 여부는 여전히 혼란스럽습니다.

우리가 특히 혼란스러워하는 것은additional steps are necessary to allow intentionally long-running processes to survive logout.

보고된 서비스 부모는 서비스 시작을 위해 규정된 단계가 여기에 적용되지 않는다고 우리를 믿게 systemd-cgls만듭니다 . 이것이 사실입니까? 현재 서비스를 출시하고 있습니다system.slicesystemd-runsystemctl start my-service.service

여전히 lingering사용자를 위해 이를 활성화 해야 합니까 me?

도와 주셔서 감사합니다.

답변1

그럴 필요도 없습니다 KillUserProcesses=no. RemoveIPC=no그 정도면 충분합니다.

사용자에 대해 지연을 활성화하는 것이 me대안입니다. 차이점은 systemd --user인스턴스가 항상 실행되도록 유지한다는 것입니다.

이 동작은 logind.conf의 KillUserProcesses= 설정에 의해 제어됩니다. 이전 기본값인 "no"는 이제 "yes"로 변경되었습니다. 이는 사용자 세션이 나중에 적절하게 정리되지만 의도적으로 장기 실행 프로세스가 로그아웃 상태에서 유지되도록 하려면 추가 단계가 필요함을 의미합니다.

이 인용문은 KillUserProcesses=yes인 경우에만 로그아웃 후에도 GNU Screen이 계속 실행되도록 하려면 "추가 단계"가 필요하다는 의미입니다. 추가 단계는 기본적으로 systemd-run --user --scope COMMANDAND 지연 활성화입니다.

그것은 당신의 희망과는 아무 관련이 없습니다. 서비스 프로세스가 로그인 세션 내에서 실행되고 있지 않기 때문입니다.

systemd-cgls를 보고 얻은 결론은 절대적으로 정확합니다.

또 다른 접근 방식은 사용자로 로그인하지 않는 것입니다 me. su한 번의 로그인으로 간주됩니다. 사용자의 crontab은 로그인된 것으로 간주될 수 있습니다(/etc/pam.d/cron이 pam_systemd에 대한 직접 또는 간접 호출을 방지하지 않는 한). 예를 들어 su의 사용을 대체 setpriv하거나 cron 대신 systemd 타이머 장치를 사용하여 User=me.

관련 정보