시작 시 getaddrinfo()를 호출하는 프로세스가 잘못된 /etc/resolv.conf로 인해 영구적으로 고착됩니까?

pianod저는 Arch Linux ARM을 사용하여 Raspberry Pi에서 Pandora 클라이언트/서버를 실행하고 있습니다. pianod시작 시 서비스로 실행되도록 설정했습니다 . 네트워크 스택보다 먼저 시작되므로 getaddrinfo()실패합니다. pianod60초마다 네트워크 로그인을 다시 시도하도록 설정하면 됩니다 .

systemd(여담: 시작하기 전에 네트워크 스택을 기다리는 몇 가지 확실한 방법을 시도했지만 pianod작동하지 않았습니다. systemd목록에는 실제로 네트워크를 사용할 수 없을 때 프로세스가 제대로 작동하도록 노력해야 한다는 제안이 있었습니다. 요점을 이해할 수 있습니다. 시작 중에 프로세스를 잠자기 상태로 만드는 다른 트릭이 있습니까? 어떤 이유로 실제로 표준적인 트릭이 있다면 관심이 있지만 깨끗한 솔루션을 선호합니다.)

pianod시작 시 초기 실패 후 60초마다 네트워크를 다시 시도 하더라도 getaddrinfo()이 오류가 발생합니다 EAI_NONAME. 프로세스를 수동으로 다시 시작하면 모든 것이 제대로 작동합니다.

getaddrinfo()문제는 start 에 대한 첫 번째 호출이 res_init()호출되어 로드를 시도할 때인 것 같습니다 /etc/resolv.conf. DHCP가 아직 올바른 DNS 정보(?)로 파일을 초기화하지 않았으므로 프로세스의 내부에 잘못된 DNS(localhost라고 생각합니다) 정보가 로드됩니다. 전역 _res변수. 그러면 프로세스가 중단될 것입니다 EAI_NONAME.

res_init()호출 실패 후 DNS 정보를 다시 로드하기 위한 수동 호출을 추가하면 getaddrinfo()모든 것이 올바르게 작동합니다. 즉, getaddrinfo()부팅 후 60초 후에 첫 번째 로그인 재시도가 성공했습니다.

그런데...이게 문제라니 놀랍네요. 기본적으로 동일한 작업을 수행하고 매뉴얼이 필요하지 않은 다른 서비스가 있습니다 res_init(). 다른 프로세스는 훨씬 더 많은 작업을 수행 하지만 나쁜 큰 그림 fork()에서 벗어나는 부분이 어디인지 모르겠습니다 . _res전반적으로 Linux에 이런 문제가 있다는 사실에 놀랐습니다.

그래서 내가 놓친 것이 무엇인지 물어봐야겠다고 생각했습니다. 내 설명이 맞는 것 같나요? 그렇다면 업스트림이 이를 더 잘 처리하지 못하는 이유는 무엇입니까? 그렇지 않다면 또 무엇을 조사해야 합니까? 이 문제를 처리하는 더 나은 표준 방법이 있습니까?

업데이트: 요청 시 현재 서비스 단위 설명은 다음과 같습니다. 나는 After=network.target또한 추가를 시도했습니다 Requires. 사람들에 따르면 systemd이것은 한 릴리스에서 다음 릴리스로 신뢰할 수 없습니다.

[Unit]
Description=Pandora Client Daemon
After=syslog.target

[Service]
EnvironmentFile=/etc/pianod.env
ExecStart=/usr/sbin/pianod $INITSCRIPT $USERFILE $PORT $LOGGING -nroot
Restart=on-abort

[Install]
WantedBy=multi-user.target