기술 · 실용 가이드
systemctl --user가 “Failed to connect to bus”라고 하나요? 변수를 내보내기 전에 세션 문맥을 확인하세요
유효 사용자, runtime directory, bus socket, user manager를 맞춘 뒤 login, 원격 관리, linger 중 실제 실행 모델에 맞는 해결책을 고릅니다.
user bus 오류는 명령 실행 identity와 service manager를 소유한 login context가 어긋날 때 흔히 발생하므로 먼저 문맥을 보존합니다.
안전한 절차는 네 layer를 증명하고 lifecycle을 분류한 뒤 한 가지 원인만 고쳐 원래 실패 경로를 다시 시험하는 것입니다.
context mismatch로 다루기
`systemctl --user`는 한 login user의 service manager와 통신합니다. bus error는 transport symptom이며 unit file이나 전체 D-Bus 고장의 증거가 아닙니다.
command, effective UID, target user, launcher, 환경, 전체 error를 기록하고 SSH, sudo, su, cron, CI, Ansible, container, login을 구분합니다.
네 layer를 만들지 않고 확인
target UID와 `/run/user/UID/bus`의 존재, owner, mode, type을 외부에서 보고 loginctl로 user와 session을 확인합니다.
흔한 path를 무조건 export하지 마세요. identity, runtime, socket, manager가 일치해야 합니다.
세 execution model 분리
interactive login은 실제 session에서, one-off 관리는 target manager를 명시하고, persistent user service만 linger를 검토합니다.
enable-linger는 logout 이후와 boot 시 manager lifecycle을 바꾸는 정책입니다.
package 변경 전 layer 분류
wrong UID는 sudo/su/automation, missing runtime/manager는 login/PAM/logind, wrong socket은 session lifecycle을 가리킵니다.
package install, reboot, linger, shell file은 다른 layer를 바꿀 수 있으므로 한 번에 한 evidence-backed change만 합니다.
같은 launcher로 재시험
수정 뒤 같은 SSH, automation, cron, admin route로 재실행하고 네 layer를 다시 확인합니다.
read-only manager command와 target unit을 확인하며 다른 shell에서만 성공한 결과는 closure가 아닙니다.
audit 경계 이해
이 audit은 user/system unit, linger 승인, PAM 수정, runtime file 삭제, bus 생성을 결정하지 않습니다.
원래 launcher가 올바른 manager에 도달하고 필요할 때만 logout/reboot persistence를 증명해야 완료입니다.
