수집기 원격 접속으로 일시키는 법

~/raker/ # raker 스크립트 모음 디렉토리

~/raker_b_eu_hist_europeana_image1.py # 개별 raker 스크립트(역할.py)

~/raker_b_eu_hist_europeana_image1.md # 그 raker의 운용법 문서(역할.md 짝)

~/raker_out/ # 수집 결과물이 쌓이는 곳

~/disk_sensor.sh # 정거장 임계치 센서(05법 제2조)

~/station_sensor/{라벨}.status # 최신 사용률 1줄

~/station_sensor/{라벨}.log # 이력

ssh lin1 "cat ~/station_sensor/*.status"

3단계 — 실제로 일 시키기(raker 실행)

기존 raker 스크립트를 재사용하는 경우(가장 흔함):

ssh lin1 "cd ~ && nohup python3 raker_b_eu_hist_europeana_image1.py \

--collect --limit <건수> --country '<국가>' --provider '<기관명>' \

> raker_out/<라벨>/log.txt 2>&1 &"

맞춰 현실적인 수치로 잡는다.

4단계 — 배정 후 모니터링

1. 착수 전 목표(수집량·예상 소요 시간) 기록

2. 완료 후 실행·문제점·개선점 4항목 기록

3. 민감/재수집난이도 높은 소스는 5~10분 주기로 점검(05법 제2조④) —

일반 소스는 15~30분 주기로 충분.

5단계 — 작업 종료·정리

ssh lin1 "pkill -f raker_b_eu_hist_europeana_image1.py" # 특정 raker 종료

ssh lin1 "ps aux | grep raker | grep -v grep" # 잔여 확인

제1조의3(30~40G 청크 단위 회수) 원칙대로 회수한다.

---

🔴 실패 사례로 배우기 — vps-in 이중 watchdog 사고 (2026-09-13)

무슨 일이 있었나: vps-in에 raker를 배치했는데, **서로 다른 시점에

존재를 모른 채** 같은 디스크를 각자 기준으로 감시하고 있었다.

밑으로 내려가면 자동 재개, 완전히 죽어있으면 자동 재시작까지 함

결과: 이미지 raker를 죽여도 영상 raker가 살아남아 있다가 디스크가 조금만

비면 바로 다시 채워서, **2026-09-11부터 2026-09-13까지 이틀 넘게 50~97%를

반복 진동**했다. 아무도 이 반복을 알아채지 못했다 — 로그엔 남았지만 사람에게

가는 알림이 없었기 때문이다.

교훈(수집 배정 시 반드시 확인):

1. 그 기기에 이미 다른 watchdog/자동화가 돌고 있는지 먼저 확인한다 —

보이는 곳에서 서로 다른 자동화가 충돌할 수 있다.

2. "일시정지 후 자동재개" 방식의 watchdog은 위험하다 — 완전 종료가

아니라 재개 조건이 있으면, 사람이 개입해 데이터를 치우기 전에 자동으로

다시 채워버릴 수 있다.

3. 로그만 쌓이고 알림이 안 가는 자동화는 있으나 마나다 — 70%

경고 단계에서 실제로 사람(세션)에게 알림이 가는지 확인한다.