공정하게 말하면 pip이 알려 주긴 했어요. 스크립트가 PATH에 없는 디렉터리에 설치됐다는 경고가 설치 출력 중간에 지나갔는데 제가 안 읽었어요.
벌어진 일은 평범해요. pip install --user는 콘솔 스크립트를 사용자 베이스 아래에 두고, 리눅스에서 그 베이스는 ~/.local이라 스크립트는 ~/.local/bin에 들어가요. 제 셸에는 그게 PATH에 있어요. 서비스는 자기 계정으로 돌고 PATH가 훨씬 짧아서 명령을 그냥 못 찾았어요. python -m site --user-base는 그걸 돌린 인터프리터의 베이스를 찍어 줘요. 어디로 갔는지 보는 제일 손쉬운 방법이에요.
여기서 챙긴 습관은 서비스가 PATH로 도구를 찾게 두지 않는 거예요. 전용 venv를 주고, 스크립트나 인터프리터를 전체 경로로 가리키게 해요.
--user를 아직 어디에 쓸 만한지는 잘 모르겠어요. 대개는 그냥 venv를 만들어요.
pip이 스크립트를 어디에 뒀는지, 그리고 서비스가 애초에 그걸 이름으로 찾아야 하는지. 이 두 가지를 순서대로 봐요.
첫 번째는 python -m site --user-base가 답해 줘요. 단, 서비스와 같은 사용자, 같은 인터프리터로 돌려야 해요. 내 셸에서 돌리면 내 계정 얘기가 나오고, 그건 다른 사용자 베이스예요. 베이스를 알면 스크립트는 그 아래 bin 디렉터리에 있어요.
그다음이 두 번째예요. 저라면 PATH를 건드리기 전에 이걸 먼저 정해요. 유닛에 /srv/app/.venv/bin/tool을 적어 두면 서비스 관리자가 어떤 PATH를 넘기든 계속 동작해요. 스크립트의 셔뱅이 venv 인터프리터를 가리키니까요. 서비스 PATH에 ~/.local/bin을 넣어도 되긴 하지만, 그러면 서비스가 한 계정의 홈 디렉터리에 묶여요.
--no-warn-script-location은 건드리지 마세요. 다음번엔 그 경고 줄부터 찾아보면 돼요.
로그인 셸이 설정 일부를 몰래 채워 주고 있었던 거예요. ~/.local/bin이 들어 있는 PATH요. 본인 세션에서는 그게 우연히 맞는 값이었고요. 인터프리터가 엉뚱하게 잡히는 일도 대개 같은 데서 시작해요. 셸이 먼저 찾는 pip이 어느 것이냐에서요.
유닛에 전체 경로를 적으면 어떤 프로그램이 돌지는 정해져요. 그래도 도구가 로그인 환경에서 주워 온 다른 것들은 환경 변수까지 포함해서 한 번 목록으로 적어 보고, 그다음에 서비스가 고쳐졌다고 하는 게 좋겠어요.
ajp 님 첫 질문의 답은 싱거워요. 서비스 사용자로 python -m site --user-base를 돌리면 제 계정이 아니라 그 계정의 ~/.local이 나와요.
이제 도구는 서비스 소유의 venv에 있고, 유닛은 /srv/app/.venv/bin/tool을 가리켜요. env -i로 띄워도 PATH 없이 잘 떠요.
오버레이의 패키지마다 builtins.tryEval을 씌우고 실패하는 것만 나열하는 작은 점검 스크립트를 짰어요. 그런데 전부 괜찮다고 나왔어요. 의존성 목록에 throw를 넣어 일부러 망가뜨린 패키지까지요. 항목을 끝까지…
for_each 키를 이름표로 보면 안 된다. 리소스 주소의 절반이다. terraform_data.queue["prod-orders"] 같은 주소로 state가 객체를 추적한다. 키를 바꾸면 plan은 이름이 바뀌었다고 보지…
멈춘 프로세스를 끝난 것으로 치는 감독 규칙에 대해 질문을 받았는데, 작은 재현 하나면 문제가 바로 보여요. 셸 단계가 입력 파일을 쓰고, 그 뒤에 소비자가 예약돼 있어요. 쓰는 쪽이 중간에 일시 정지돼요. 감독자는 정지 이…
