기술 · 실용 가이드
systemd status=216/GROUP인가요? Group= 삭제 전에 관리자와 ID를 점검하세요
216/GROUP는 프로그램 실행 전 그룹 자격 증명 단계의 실패입니다. 관리자와 실제 unit, NSS 해석을 확인하고 입증된 불일치만 고친 뒤 PID 자격을 검증하세요.
systemd는 그룹 자격 증명을 결정하거나 바꾸지 못하면 216/GROUP를 반환합니다. 애플리케이션이 실행되지 않았을 수 있으므로 인수부터 디버깅하면 잘못된 분기로 갑니다.
User=나 Group= 삭제를 만능 해결책으로 쓰지 마세요. 보안 경계만 사라질 수 있습니다. PID 1과 사용자 관리자 중 누가 unit을 읽었는지 먼저 확인하세요.
관리자·unit 경로·첫 오류 보존
status, 실패 invocation journal, FragmentPath, DropInPaths를 저장하고 systemctl인지 --user인지 기록합니다.
216/GROUP가 첫 자격 단계 실패인지 확인하고 반복 뒤 start-limit-hit와 분리합니다. 정확한 unit 이름과 로드 경로를 남깁니다.
실제 ID 지시문 전체 확인
실제 User=, Group=, SupplementaryGroups=, DynamicUser=와 관련 샌드박스를 확인합니다.
시스템 서비스는 ID를 선택하지만 일반 사용자 관리자는 다른 사용자로 바꿀 수 없습니다.
편집 전에 NSS 해석 입증
getent passwd, group, initgroups로 사용자, 기본 그룹, 추가 그룹을 확인합니다. 미발견은 증거이며 임의 숫자 ID를 만들 근거가 아닙니다.
생성 순서와 범위를 확인합니다. 정적 ID는 시작 전에 있어야 하며 컨테이너, chroot, 원격 NSS는 셸과 다를 수 있습니다.
격리를 지키는 최소 수정
계정 생성, 오타 수정, 잘못된 추가 그룹 제거, 올바른 관리자 이동, 의도적 DynamicUser= 중 입증된 것만 고칩니다.
오류만 없애려고 ID 지시문을 지우지 마세요. 기본 ID를 쓰면 파일, 소켓, 자격, 쓰기 경로를 다시 검토합니다.
다시 읽고 한 번 시작해 자격 검증
같은 관리자에서 daemon-reload하고 필요할 때만 제한 상태를 지운 뒤 한 번 시작해 새 journal을 봅니다.
주 PID의 UID, 기본 GID, 추가 그룹을 의도와 비교하고 권한 확대 없이 실제 요청이나 작업 하나를 완료합니다.
