직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 Linux6 systemd 설정이 반영되지 않을 때: daemon-reload·reload·restart 구분 systemd 유닛 파일을 수정했다면 daemon-reload로 관리자에게 다시 읽게 해야 합니다. 그러나 이것만으로 실행 중인 서비스가 새 실행 조건으로 바뀌지는 않습니다. 서비스 자체 설정 재읽기와 프로세스 재시작을 구분하세요.적용 환경: systemd 255 공식 문서 기준; 설치 버전과 배포판 정책은 적용 전 확인. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 서로 다른 설정 파일을 같은 방식으로 반영동작대상daemon-reloadsystemd 관리자와 유닛 구성reload서비스 자체의 지원되는 설정 재읽기restart서비스를 중지한 뒤 다시 시작웹 서버 설정과 systemd 서비스 유닛은 담당하는 프로그램이 다릅니다. 변경한 파일이 어느 쪽.. 2026. 10. 26. journalctl -b -1 로그가 없을 때: 이전 부팅 기록과 저장 방식 점검 이전 부팅 로그가 안 보인다면 먼저 보유 중인 부팅 목록과 조회 권한을 확인하고, journald 저장 방식과 보존 정책을 살펴보세요. 지금 영구 저장을 켜도 이미 사라진 과거 기록이 다시 생기지는 않습니다.적용 환경: systemd 255 공식 매뉴얼 기준 Linux; 배포판 설정과 설치 버전 별도 확인. 공식 문서 확인일: 2026-10-23. 아래 내용은 문서 기반 점검 가이드이며 운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 조회할 기록이 남아 있는지 먼저 봅니다journalctl --list-boots는 현재 읽을 수 있는 저널의 부팅 번호·ID·시간 범위를 보여 줍니다. -b -1은 이전 부팅을 고르는 옵션이지, 없어진 로그를 복구하는 명령이 아닙니다. 권한 부족 안내가 있으면 승인된.. 2026. 10. 24. rsync 복사 경로가 한 단계 달라질 때: 소스 끝 슬래시와 dry-run 확인 rsync의 소스 디렉터리 끝에 슬래시가 있으면 보통 그 안의 내용을 복사하고, 없으면 디렉터리 이름을 포함하는 차이가 생깁니다. 목적지 상태와 파일 수에 따른 다른 규칙도 있으므로 실행 전 dry-run 결과에서 실제 상대 경로를 확인하세요.원인: 복사하려는 범위와 입력 경로가 다르다같은 파일이 들어 있는 폴더라도 “폴더 자체”와 “그 안의 내용”은 목적지 구조가 다릅니다. 소스 끝의 /를 장식처럼 취급하면 배포 파일이 예상보다 한 단계 아래에 놓일 수 있습니다. 반대로 경로 차이를 고친다며 운영 목적지를 삭제하면 별개의 손실을 만들 수 있습니다.소스 입력빈 목적지의 예읽을 범위sourcewhole/source/demo.txt디렉터리 이름 포함source/contents/demo.txt안의 내용1. 버.. 2026. 10. 22. Linux 용량이 남는데 No space left on device: inode와 실제 저장 경로 확인 No space left on device가 나오는데 df -h에 여유가 있다면 실패한 경로의 파일시스템을 기준으로 df -i도 확인하세요. 데이터 블록과 inode 여유는 다른 정보입니다. 홈 디렉터리의 여유 공간을 보고 다른 마운트나 컨테이너의 저장 경로도 괜찮다고 판단하면 원인을 놓칠 수 있습니다.원인: 용량 수치 하나가 모든 자원을 뜻하지 않는다파일시스템은 파일 내용뿐 아니라 파일을 관리하는 정보도 필요합니다. 작은 파일이 많이 쌓이면 총 바이트만으로는 상태를 설명하기 어려울 수 있습니다. 또한 /tmp, 데이터 볼륨, 컨테이너 저장 경로가 서로 다른 파일시스템일 수 있습니다. 오류가 난 정확한 경로와 실행 환경을 먼저 적어야 합니다.관찰다음 확인주의블록 여유 있음같은 경로 df -i다른 마운트 .. 2026. 10. 19. systemd start-limit-hit 해결: 최초 실패를 고친 뒤 reset-failed로 복구 start-limit-hit나 Start request repeated too quickly가 보이면 먼저 제한에 도달하기 전의 최초 실패 로그를 찾으세요. reset-failed는 실패 상태와 시작 제한 카운터를 정리하지만 프로그램의 오류를 수정하지 않습니다. 원인을 고친 다음 대상 서비스만 재개하고 재발 여부를 확인해야 합니다.원인: 마지막 메시지는 시작을 막은 결과일 수 있다서비스가 짧은 시간에 여러 번 시작되면 systemd의 시작 횟수 제한에 걸릴 수 있습니다. 자동 재시작뿐 아니라 수동 시작도 해당 제한과 관계되므로 같은 start 명령을 연속 실행해 해결하려고 하면 진단이 더 어려워집니다. 마지막 제한 메시지 앞에 설정 누락, 실행 파일 오류, 의존 대상 접근 실패 같은 실제 원인이 있는지 .. 2026. 10. 18. systemd 203/EXEC 해결: 실행 경로·권한·shebang·noexec 점검 순서 status=203/EXEC는 systemd가 지정한 프로그램을 실제로 실행하는 단계에서 실패했다는 단서입니다. 애플리케이션 설정을 먼저 바꾸거나 재시작을 반복하기보다 journal의 오류 문구를 읽고 실행 경로, 접근 권한, 스크립트 인터프리터와 마운트 조건을 확인하세요. 파일이 존재하는 것만으로 실행 가능하다고 판단할 수 없습니다.자료 확인 기준일은 2026년 10월 13일입니다. 아래 예시는 공식 문서를 바탕으로 작성한 설계·점검 예이며, 이 글에서 실제 계정이나 서버에 실행한 시험 결과는 아닙니다.원인: 프로그램이 시작되기 전의 실패입니다systemd 매뉴얼은 203/EXIT_EXEC를 실제 프로세스 실행, 구체적으로 execve 호출의 실패로 설명합니다. 누락되거나 접근할 수 없는 실행 파일이 .. 2026. 10. 14. 이전 1 다음
