Repository navigation
research: validate Dots lifecycle, recovery, and proxy compatibility #20
Description
2026-10-23 현재 진행
검토용 Draft PR: #46. 현재 설치 네 소스·manifest가 v0.4.0과 일치하고 기존 SSH 호스트 키가 유지됨을 새 strict SSH로 확인했습니다. 복구 후와 같은 부팅 환경에서 자원 기준값을 수집했습니다. 2026-10-23 10:46 KST부터 10-24 10:46 KST까지 24시간·5분 간격 읽기 전용 관찰을 진행 중입니다. 상한에 도달하면 수집기만 종료합니다.
같은 부팅의 프로세스 종료 복구, 다른 부팅 문맥에서의 Dots 시작 명령 실행, 완전 무인 자연 장애 복구를 구분합니다. 마지막 항목은 여전히 미검증이며, VM 재부팅/교체의 정확한 플랫폼 의미와 workspace 전체 보존도 단정하지 않습니다. watchdog은 사용자 요청에 따라 중지된 상태를 유지합니다.
목적
dots-tailscale의 상태 보존, 재기동, 실행 위치별 접근 차이, 장시간 연결 복구 및 플랫폼 프록시 의존성을 증거 기반으로 확인합니다. 다섯 주제를 하나의 리서치 이슈로 추적하고, 재현된 결함이나 구체적인 구현 과제는 관련 이슈와 중복되지 않도록 분리합니다.
이 이슈는 지원 가능한 조건과 한계를 정리하기 위한 연구입니다. 자동 복구 구현이나 특정 릴리스 포함을 약속하지 않습니다.
현재 문서에 기록된 사실과 미검증 사항
한국어 사용 가이드의 2026-10-15 검토 기준:
- 설치 파일·Tailscale state·SSH identity는
/workspace, socket·PID·로그는/tmp에 둡니다. - 이전 버전에서 24시간 이상 동작하고 환경 교체 후 수동으로 재기동한 사용자 관찰이 기록돼 있습니다.
- 2026-10-14 수정 shim 배포 후 DERP ping과 엄격한 호스트 키 검증을 유지한 SSH 공개키 로그인·명령 실행은 확인됐습니다. 수정본으로 이후 환경 교체를 거친 복구는 아직 관찰하지 않았습니다.
- 자동 시작·Dots 자동화 등록 기능은 구현되지 않았고, Dots 자동화로 기동하는 방식도 시험하지 않았습니다.
- 로그는 재기동 시 1 MiB 초과 파일을 한 세대 회전합니다. 계속 실행 중인 로그 크기에는 상한이 없습니다.
- HOME 관찰 marker 변화만으로 HOME 전체 초기화나 VM 교체를 입증할 수 없습니다.
실제 배포본과 현재 소스의 일치 여부, 새 환경에서의 자동화 실행 가능성, 장기 단절 후 복구·자원 추이는 이번 이슈 등록으로 검증된 것이 아닙니다.
조사 범위
1. 환경 교체 후 상태 보존
/workspace, HOME, runtime 파일의 유지·소실 조건과 Tailscale 장치 신원·SSH 호스트 키 연속성을 확인합니다.- 단순 프로세스 재시작, HOME 파일 변화, 실제 환경 교체를 구분합니다.
- 비밀을 포함하지 않는 관찰 결과를 환경 밖에 보관하고 전후 비교합니다.
- 결과에 따라 보존 조건, 인증 상태 소실 시 중단 조건, 수동 복구 절차를 정리합니다.
2. 자동 재기동 가능성과 독립적인 실행 경로
- Tailscale이 정지된 새 환경에서도 플랫폼 측 실행 경로로
start.sh를 호출할 수 있는지 확인합니다. - 호출 자체가 Tailscale 연결에 의존하는지, 필요한 권한·파일·인증 상태가 무엇인지 확인합니다.
- 중복 호출과 실패 시 동작을 구분하고, 지원 가능한 자동 시작 범위 및 독립적인 수동 복구 경로를 정리합니다.
- 자동화 등록·상시 서비스 도입은 연구 결과와 별도의 구현 결정으로 남깁니다.
3. 실행 위치별 접근 차이
- 동일 버전·설정을 기준으로 Dots 에이전트, GUI 터미널, SSH의 UID, 파일 소유권·접근, PATH, socket, 프록시 및 네트워크 접근을 비교합니다.
- “터미널에서는 되지만 에이전트에서는 안 되는” 경우를 관찰 가능한 차이로 설명합니다.
- 접근 제한은 우회하지 않고 지원 조건과 제한으로 기록합니다. 실행 환경 차이로 확인할 수 없는 항목은 미검증으로 남깁니다.
4. 장시간 연결과 자동 복구
- 격리 환경에서 프록시·DERP 연결 단절과 복구를 시험합니다.
- 복구 시간, 연결 수, 프로세스·스레드·파일 디스크립터 및 로그 증가를 기록합니다.
- 장기 관찰 기간, 부하, 단절 시나리오, 성공·중단 조건은 시험 전에 정합니다.
- 자동 복구되는 조건과 재시작이 필요한 조건을 구분합니다. 기존 연결의 생존과 새 연결 성공도 별도로 확인합니다.
5. 플랫폼 프록시 변경에 대한 호환성
- shim이 의존하는 HTTP CONNECT, TLS, Upgrade/WebSocket 동작과 단계별 실패 지점을 문서화합니다.
- 격리 fixture로 호환성 회귀 확인 절차를 마련하고, 현재 플랫폼에서 관찰된 동작과 가정을 구분합니다.
- 지원 조건과 실패 시 진단·복구 안내를 정리합니다. 미래 플랫폼 변경에 대한 호환성을 보장하지 않습니다.
완료 조건
- 다섯 주제별로 시험 조건, 소스·배포 리비전, 재현 절차, 관찰 결과, 한계 및 미검증 사항이 정리돼 있습니다.
- 상태 보존 결과는 실제 환경 교체 증거와 구분됩니다. 교체를 관찰하지 못했다면 관찰 대기로 명시하고 검증 완료로 처리하지 않습니다.
- 자동 재기동의 가능·조건부 가능·불가 또는 근거 부족 판정과 독립적인 수동 복구 경로가 정리돼 있습니다.
- 실행 위치별 차이를 비교하고, #17의 CLI·doctor 설계에 필요한 진단 근거를 연결합니다.
- 사전에 정한 관찰 범위에서 연결 복구와 자원 증가를 평가하고 재시작 필요 조건·알려진 한계를 정리합니다.
- 플랫폼 프록시의 지원 조건, 단계별 실패 지점 및 격리 호환성 점검 절차를 제공합니다.
- 확인된 결과와 복구 안내를 영어·한국어 문서에 반영하고, 미실행 시험이나 관찰 대기 항목을 명확히 남깁니다.
- 후속 구현이 필요하면 근거와 범위를 정리해 기존 관련 이슈에 연결하거나 별도 제안으로 분리합니다.
안전 및 범위 제한
- 상태·개인키를 삭제하거나 복제하지 않습니다. 공개 결과에는 자격 증명, 실제 내부 호스트·tailnet 식별자, 민감한 로그를 포함하지 않습니다.
- 격리 시험을 우선합니다. 서비스 중단을 유발하는 실환경 시험은 별도 승인, 제한된 범위, 독립적인 복구 경로 및 롤백 계획을 확보한 뒤 수행합니다.
- 플랫폼 보안·네트워크 제한 우회, 전역 프록시 변경, Exit Node 구현은 범위 밖입니다.
- 이슈 등록 자체는 코드 실행, 실환경 장애 주입, 자동화 등록 또는 배포 승인을 의미하지 않습니다.
관련 작업
- feat: add socket-aware CLI and layered doctor diagnostics #17: socket-aware CLI·doctor 구현. 본 연구의 실행 위치·실패 계층 관찰 결과를 제공하되 구현을 중복하지 않습니다.
- research: investigate Dots exit-node forwarding under platform egress restrictions #16: Exit Node forwarding 연구. 별도 목적과 검증 범위를 유지합니다.
- feat: add opt-in localhost SOCKS5 and HTTP outbound proxy #18, docs: add private HTTP API recipe with least-privilege access #19: opt-in outbound proxy와 private HTTP API recipe. 별도 기능·사용 사례로 유지합니다.
- fix: 파일을 열어 둔 프로세스를 shim·sshd 실행으로 오인하지 않도록 식별 강화 #4, fix: shim TLS·Upgrade 준비 단계에 deadline과 연결 정리 추가 #5, fix: WebSocket 101 응답의 Accept·Upgrade 헤더를 검증 #6: 종료된 프로세스 식별·연결 준비 deadline/정리·WebSocket handshake 검증 작업. 미해결 결함으로 다시 주장하지 않고 현재 버전의 회귀·장기 검증 배경으로 참조합니다.
Activity
abruption commentedon Oct 15, 2026
1차 조사 결과 — 2026-10-15
현재 소스의 정적 조사와 실제 Dots 클라우드 GUI 터미널의 읽기 전용 관찰을 진행했습니다. 배포된 setup/shim은 검토 소스와 hash가 다릅니다. 따라서 아래 소스 분석과 실환경 관찰을 구분합니다.
검토 기준과 배포 비교
검토 커밋:
643484b35dadd46ce4a257b4256717e16d6b99d9. 조사 시점 default branch의 setup/shim/probe 파일 blob이 해당 커밋과 각각 일치했습니다. 소스 본문의 SHA-256과 배포 파일의 SHA-256을 비교했습니다.SHA-256 비교 결과:
배포 hash 원문은 생략합니다. 정확한 배포 리비전과 차이의 원인은 아직 확인하지 못했습니다. wrapper 일치만으로 배포된 setup/shim이 현재 main 또는 v0.2.0과 같다고 판단하지 않습니다.
1. 환경 교체 후 상태 보존
소스에서 확인한 내용
/workspace, runtime socket·로그는 UID별/tmp경로를 사용합니다.근거: 기본 경로, 기동 전 상태 확인, 관찰 도구의 판정과 쓰기.
현재 환경 관찰
2. 자동 재기동과 독립적인 실행 경로
소스에서 확인한 내용
근거: wrapper와 구성요소 기동, lock·인증 분기·종료 상태.
현재 환경 관찰
3. 실행 위치별 접근 차이
소스에서 확인한 내용
근거: socket·CLI, preflight, 프로세스 환경.
현재 환경 관찰
4. 장시간 연결·자원·복구
소스에서 확인한 내용
근거: timeout 정책, blocking 전환, 종료 정리·listener, 로그 회전.
현재 환경에서의 짧은 관찰
이 결과는 해당 짧은 정상 관찰 구간의 안정 상태입니다. 장기 안정성, 누수 부재, 프록시/DERP 단절 후 복구, 새 원격 연결 성공 또는 SSH 인증 성공을 검증한 결과가 아닙니다.
5. 플랫폼 프록시 호환성
소스에서 확인한 내용
근거: shim 설계·TLS 설정, proxy URL 처리·자식 환경.
현재 플랫폼의 실패 응답·단절·호환성 변경을 주입하지 않았습니다. 현재 배포 shim도 검토 소스와 다르므로 이 정적 설명을 배포본의 전체 동작이나 미래 호환성 보장으로 해석하지 않습니다.
남은 검증과 다음 순서
이번에는 코드·설정·서비스·인증 상태를 변경하지 않았고, 장애 주입·VM 교체·새 원격 연결·인증 시험·자동화 등록을 수행하지 않았습니다. 이슈의 완료 체크박스와 마일스톤도 변경하지 않습니다.
abruption commentedon Oct 17, 2026
Research update — 2026-10-18
Priority: high. Assigned to Research. Investigate the independent restart path and execution contexts first; treat long-duration and replacement observations as continuing research.
Confirmed observations
bwrap, with UID mapping1000 0 1./workspaceis writable and the per-user Tailscale socket is visible. cron/crond/crontab and the user systemd bus are absent, consistent with the earliersystemctl --useroffline result.Independent scheduling path
Official Dots documentation describes recurring work with saved schedules and cloud-computer execution. This makes a platform-scheduled recovery task a candidate worth testing. The consulted docs do not establish a VM-creation hook, guaranteed access to the same workspace after replacement, or guaranteed unattended execution of this startup script. The inspected dot action menu exposes reboot, but no startup-hook setting was observed there; this limited UI observation does not establish that no such feature exists elsewhere.
Sources: Dots tasks and memory, computers and apps, scheduled tasks.
Next bounded experiment
No schedule or permanent background loop was created, no VM replacement was forced, and no long-duration recovery claim is made. The application-proxy research in #18 can proceed alongside this investigation; its resulting diagnostics feed #17.
abruption commentedon Oct 17, 2026
Execution-context comparison — 2026-10-18
Performed the next bounded read-only experiment at approximately 08:50–08:54 KST. The same probe inspected code-file metadata/hashes, namespace fingerprints, tool availability and the local Tailscale socket. No key or authentication-state content was read; no daemon was restarted and no scheduled task was registered.
Provenance
functions.exec → tools.exec_command,/bin/bash,login=false, and returned the JSON stdout. This is agent-reported execution evidence, not a separately captured raw tool trace.Results
All three report the same effective UID/GID; equal UID alone therefore does not establish identical execution context or socket visibility. The agent also reported proxy/CA environment variables present, whereas SSH had those variables absent. Values were not collected.
A second direct-Bash read-only
statvfs(...).f_flag & ST_RDONLYcheck reported/workspaceand the installation directory read-only, and its own/tmpwritable. No write attempt, permission change, namespace entry or remount was used to test/override that restriction.Implications for recovery and #17
start.shalone is insufficient evidence that the current startup procedure can recover the GUI/SSH environment from this context.Remaining work
Official product documentation describes cloud-computer and recurring-task entry points, but does not establish a VM-start hook or guarantee the execution namespace: computers and apps, tasks and memory.
abruption commentedon Oct 18, 2026
후속 이슈 연결 — 2026-10-18
논의한 구현 과제를 별도 등록했습니다. 이 이슈는 예약 실행·독립 복구 경로·환경 교체·장시간/단절 복구 연구를 계속 담당하며 동일 연구 이슈를 중복 생성하지 않습니다.
Next release는 차기 계획 묶음이며 버전 번호나 출시일은 확정하지 않았습니다. 자동 업데이트는 VM 교체 뒤 실행 주체가 없는 문제의 해결책으로 간주하지 않습니다. 이번 등록에서 예약·상시 서비스·실환경 장애 주입은 수행하지 않았습니다.
abruption commentedon Oct 19, 2026
Bounded watchdog trial started — 2026-10-19
User-authorized 24-hour trial began at 2026-10-19 13:12:59 KST, planned completion 2026-10-20 13:12:59 KST. This is an operational experiment, not a package feature or a completed stability result.
/workspace, detached from the SSH session in the GUI/SSH execution environment. Single-instance flock; approximately 60-second observations; three-minute failure grace.start.sh, with a bounded startup/readiness period, installation lock checks, 15/30/60-minute cooldown and at most three attempts. Authentication-required states do not trigger login. Pending/uncertain proxy changes defer recovery.Evaluation: observation continuity, duplicated/repeated actions, local and external readiness, resource/log growth, and any natural recovery attempts. No-fault operation would establish observation stability only, not fault recovery. VM replacement can end this watchdog and is not automatically repaired by it. Results will be evaluated after the observation window.
Current service-manager inspection: PID 1 is bwrap; systemctl system/user both report offline; cron/crond/crontab are absent; system directories are not writable in this context. A userspace scheduler could be investigated separately but would still need a post-replacement bootstrap.
abruption commentedon Oct 19, 2026
Observation extended to continuous mode — 2026-10-19
At the maintainer's request, removed the planned next-day termination. The original bounded watchdog was explicitly stopped and its records retained; this is an early transition, not a completed 24-hour trial. No recovery attempts had occurred before transition.
A new continuous watchdog started at 2026-10-19 15:04:01 KST, reporting continuous=true, planned_end_utc=null, healthy backend/components/local SSH and zero attempts. Only the watchdog process was replaced; Tailscale was not restarted.
Natural faults/recovery and replacement survival still require evidence; healthy observation alone does not prove those properties. The scripts remain an operational experiment outside the published package.
abruption commentedon Oct 20, 2026
Continuous watchdog results and runtime loss — 2026-10-20
Follow-up to the continuous observation started on 2026-10-19 at 15:04:01 KST. The watchdog remains an operational experiment outside the published package. This investigation used existing logs, strict-host-key SSH, process metadata and the local experimental scripts; no fault was injected and no watchdog or daemon was restarted by this investigation. The maintainer separately reported manually restoring connectivity.
Timeline (KST, UTC+09:00)
/proc/uptime.bwrap) start estimated from process start ticks and uptime.The current kernel's uptime is much shorter than the previous watchdog's measured lifetime. Together with the lost process and newly started runtime, this strongly supports runtime reboot/replacement. It does not identify the platform trigger or distinguish every kind of VM replacement, reboot or restored runtime. There is no stored pre-event boot ID for direct before/after comparison. Times derived from wall clock/uptime are estimates.
Workspace persistence: older log contents returned
Current Dots
heartbeat.jsonandevents.jsonlend at 17:39:43, but external observations prove that the same watchdog remained alive until 18:39. The external events snapshot includes records through 18:33:45.A byte comparison shows that the entire current events file is an exact prefix of the external snapshot: 1,597 current records versus 1,651 snapshot records, with 54 later records absent on Dots. This is stronger than an mtime-only observation. It is consistent with older persisted contents being restored or a different older workspace view becoming active; the storage mechanism is unverified.
Consequently, the current remote file's last timestamp must not be treated as the watchdog death time. An initial investigation inference of a 17:39 termination was corrected using the external evidence. File presence under
/workspacealso must not be interpreted as a guarantee that every latest write survives a runtime change. No authentication-state or private-key contents were inspected, and this result does not establish that those files rolled back.Stability before loss
The preserved external observations contain 326 successful live-watchdog samples, all healthy, and zero recovery attempts. This establishes sampled observation stability for approximately 27h 35m, not successful fault recovery or uninterrupted application traffic between samples.
Daemon log size increased from 57,247 to 684,123 bytes; SSH log size from 13,072 to 188,017 bytes. Watchdog memory/thread/FD observations show no sustained growth in this window. This is not a general memory-leak guarantee.
What the remaining logs cannot establish
Concrete follow-up work
state=running. The current observer's summary can otherwise display running for a dead process. Retain a bounded, sanitized SSH error classification as well as exit status.Sanitized evidence snapshots and the detailed local investigation notes were preserved separately before periodic observer snapshots could overwrite them. Raw private operational logs and host identifiers are not attached to this public issue. Keep #20 open: long-duration observation now has evidence, while persistence semantics, independent startup and actual fault recovery remain incomplete. No claim that the deployed package was upgraded to the latest release is made by this watchdog-only investigation.
abruption commentedon Oct 21, 2026
Watchdog follow-up: boot changed and the new run directory disappeared — 2026-10-21
After the maintainer manually restarted Tailscale, strict-host-key SSH works again and the local daemon reports Running/online. The watchdog itself is absent: no visible watchdog process exists, and the entire directory for the Oct 21 run (script, identity, heartbeat and logs) is missing. Older Oct 19 watchdog directories remain in the writable workspace.
Evidence and timeline (KST)
Unlike a heartbeat timestamp alone, the independently saved before/after boot IDs establish a boot/runtime change. They do not identify the platform trigger or storage restore mechanism. The missing new directory while older directories remain is consistent with an older restored workspace view; it does not prove that all workspace contents were lost.
Why no automatic recovery can be claimed
The existing recovery action invokes start.sh, which normally reuses apparently running components. Adding a connectivity probe alone would not establish that a Running-but-isolated daemon is restarted or reconnected.
Follow-up needs both a bounded connectivity-aware policy for a surviving runtime and a supported independent bootstrap after runtime loss. Preserve boot metadata, fresh heartbeat/liveness, and external evidence across each run. Sanitized observations and source snapshots were retained outside Dots. No new watchdog, daemon restart, configuration change or fault injection was performed by this investigation.
abruption commentedon Oct 21, 2026
Bounded monitoring and recovery validation plan — 2026-10-21
The maintainer authorized monitoring-accuracy improvements and recovery-scope validation before starting v0.4.0 implementation.
Monitoring: keep external peer ping and fresh strict-host-key SSH separate from local backend readiness. Derive watchdog state from boot identity, PID/start ticks, heartbeat age and run sequence. Explicitly report missing scripts/metadata, dead process, stale heartbeat, changed boot, sequence regression, SSH authentication/host-key rejection and unavailable external transport. The Mac probe must still run when the watchdog directory disappears. Save sanitized evidence outside the VM every sample.
Recovery tests: one fault at a time, exact same-UID executable/script/config identity revalidated with a pidfd. Send one SIGTERM to the shim or daemon for a bounded one-shot installed-start.sh recovery test; do not remove sockets, credentials or state. Separately stop only the SSH listener to exercise the continuous watchdog's real 60-second polling / 180-second grace. Preserve existing SSH sessions where OpenSSH supports this. No SIGKILL, forced VM replacement, route/ACL change, or authentication operation is part of these cases.
Independent recovery: the maintainer confirmed that their cloud GUI terminal is controllable. This agent's browser control path has not worked, so that distinction will be recorded. Before each fault, arm a detached, single-attempt installed-start.sh fallback (180 seconds for a one-shot case; 420 seconds for the policy case). Stop further faults if graceful termination, local recovery, invariants, or fresh external SSH validation fails.
Acceptance: same boot and public node identity, unchanged static configuration/code and public host-key fingerprint, new identity only for the deliberately terminated component, local readiness, and a new strict-host-key authenticated SSH command from the Mac. One-shot cases validate recovery mechanics, not production grace/backoff. Offline policy tests cover cooldown, attempt limit, auth-required and uncertain-process conditions; the listener case exercises the normal loop. Local readiness alone is not external recovery.
Limits: an all-processes-present connectivity failure is observed externally but does not trigger a blind local restart. VM destruction still requires an independent bootstrap. Missing post-outage evidence remains unknown rather than zero attempts. The experimental scripts remain outside the released package.
abruption commentedon Oct 21, 2026
2026-10-21 감시 정확도 및 제한된 복구 실측
시험 범위
실측 결과
각 구성요소 복구에서 같은 부팅, 같은 Tailscale 공개 노드 식별 정보, 동일 정적 파일 및 SSH 공개 호스트 키, 대상 프로세스만 교체, 다른 구성요소 PID 유지 조건을 확인했습니다. 비밀키/상태 파일은 해시하지 않았습니다.
첫 자동 복구 실패 원인과 수정
설치된 프로세스 검사기가 읽을 수 없는 같은 UID의 /proc 항목을 발견하면 전체 검사에 불확실성이 남습니다. SSH 리스너가 종료돼도 결과가 not_running 대신 unknown이 되어, 이번에 추가한 실험용 watchdog의 보수적 중단 조건이 복구를 막았습니다.
수정한 감시자는 같은 부팅에서 직접 확인한 기존 PID/시작 시각/실행 파일의 종료를 입증하고, 대체 프로세스가 없고, IPv4/IPv6 리스너까지 없을 때만 해당 구성요소를 not_running으로 판정합니다. 접근 권한 오류만으로 종료를 추정하지 않습니다. 설치 스크립트의 독립적인 안전 검사도 유지합니다.
이 원인은 이번 실험용 감시 코드의 실패를 설명합니다. 과거 VM 교체/실행 디렉터리 소실 사건의 원인으로 소급해서 단정하지 않습니다.
감시 운영 및 남은 한계
abruption commentedon Oct 21, 2026
2026-10-21 추가 실측: 업데이트 시험 전 외부 연결 단절과 새 부팅 확인
external_unreachable로 기록했습니다.bash /workspace/.dots-tailscale/start.sh를 실행한 뒤, Mac에서 새 엄격 SSH 접속과 DERP ping이 성공했습니다.이전 watchdog 기록과 현재 상태 구분
/workspace에 이전 실행 디렉터리는 남아 있었습니다. 그러나 그 heartbeat는 이전 boot/run의state=running이므로 현재 프로세스가 실행 중이라는 증거가 아닙니다.특히 복구된 heartbeat 파일은 12:13:45 / sequence 72였고, Mac 외부 감시는 같은 실행의 12:43:46 / sequence 101까지 이미 관측했습니다. 즉, 복구 후 보이는 해당 파일은 마지막 외부 관측보다 과거 내용입니다. 이 차이를 VM 밖에 보존했으며,
/workspace전체의 스냅샷·복원 정책이나 다른 파일의 손실까지 단정하지 않습니다. 남아 있는 로컬 로그만으로 실제 종료 직전 상태나 추가 복구 시도 유무를 확정할 수 없습니다.후속 운영
이후 사용자 승인하에 검토된 v0.4.0 개발 후보의 정상 적용·기동 실패 원복 시험을 수행했고, 두 경우 모두 별도 외부 SSH/ping을 확인했습니다. 이 시험은 위 단절보다 뒤의 별도 사건입니다.
13:23:40 KST, 새 부팅 환경에 새 watchdog 실행을 시작했습니다. 60초 간격의 연속 실행이며 외부 관측도 새 실행으로 전환했습니다. 이전 부팅의 monotonic 시간 기반 정책 원장을 재개하지 않고 이전 기록을 보존한 채 새 실행의 예산을 시작했습니다. 13:24:38 KST 외부 관측은
verified_running입니다.결론은 유지됩니다. 같은 VM에서 식별 가능한 개별 프로세스 종료 복구는 검증됐지만, 실행 환경이 사라지고 새 부팅이 시작된 뒤 watchdog 자체를 자동 기동하는 경로는 없습니다. #20은 계속 열린 연구 과제로 유지합니다.
abruption commentedon Oct 21, 2026
2026-10-21 야간 추가 관측을 기록합니다. 시각은 KST입니다.
복구 후 /workspace에 남은 이전 heartbeat는 18:25:47 / sequence 303이었습니다. 같은 run을 Mac이 20:31 / sequence 429까지 관측한 기록보다 과거 내용입니다. 이전 부팅의 state=running은 현재 실행 증거가 아니며, 현 부팅에서 이전 watchdog 프로세스는 없었습니다. 해당 메타데이터·이벤트와 외부 기록을 VM 밖에 보존했습니다. 단절 이후 복구 시도 유무는 오래된 원격 기록으로 재구성할 수 없으며, /workspace 전체의 지속성 정책도 이 사례만으로 확정하지 않습니다.
실제 현재 프로세스의 시작 시각은 shim 21:17:43, tailscaled·sshd 21:17:46으로 확인했습니다. start.sh의
running: Tailscale and local SSH ready는 start_all 이후 출력되는 성공 상태이며, 기존 프로세스 재사용과 신규 기동을 그 문구만으로 구분할 수 없습니다. 이 메시지는 watchdog 실행 상태도 포함하지 않습니다.21:19:39, 새 부팅에 새 watchdog 실행을 시작했습니다. 60초 간격·자동 종료 없는 연속 실행이며 이전 부팅의 monotonic 정책 원장은 재개하지 않았습니다. 외부 감시 대상도 새 실행으로 변경했고, 21:21:36 관측은 verified_running, 복구 시도 0회였습니다.
현재 확인된 복구 범위는 계속 같은 부팅에서 식별 가능한 개별 프로세스 종료입니다. 실행 환경이 사라진 뒤 watchdog 자체를 자동 시작하는 경로는 여전히 미해결입니다.
abruption commentedon Oct 21, 2026
2026-10-21 22시대 재발 관측입니다. 시각은 KST입니다.
/workspace에서 보이지 않았습니다. 이전 원격 identity/heartbeat/이벤트를 복구할 수 없으므로 최초 단절 원인이나 단절 이후 복구 시도 유무를 확정하지 않습니다. Mac의 단절 전후 외부 기록은 별도로 보존했습니다./workspace전체의 지속성은 구분해야 합니다.로컬에 보존한 실험용 감시 코드를 전송해 22:18:24, 새 부팅에서 새 watchdog 실행을 시작했습니다. 60초 간격·자동 종료 없는 연속 실행이며 새 실행 예산은 0회에서 시작합니다. 외부 감시도 새 실행을 보도록 전환했습니다. 과거 부팅의 monotonic 원장은 재개하지 않았습니다.
이번에도 확인된 한계는 동일합니다. Tailscale 수동 시작은 복구됐지만, 새 실행 환경에서 watchdog 자체를 자동 기동하거나 사라진 감시 파일을 자동 복원하는 경로는 아직 없습니다.
abruption commentedon Oct 23, 2026
수명 주기·상태 보존·자원 관찰 현행화 — 2026-10-23
Draft PR #46에 영어·한국어 연구 문서, 비밀 없는 기준값 및 제한된 수집기를 추가했습니다.
24시간 관찰은 10월23일 10:46:20 KST 시작 → 10월24일 10:46:20 종료 예정, 300초 간격입니다. 시작 기한은 먼저 저장돼 재실행해도 연장되지 않습니다. 원격 명령15초/전체20초, stdout64KiB·증거10MiB 및 자원·로그 상한을 적용했습니다. 상한에서는 수집기만 종료하고 Dots 서비스는 조작하지 않습니다. 설치 소스만 해시하고 키·인증 state 내용은 수집/해시하지 않습니다.
수집기11개 검증은 실제 과다 stdout·stderr 및 장시간 대기 자식의 종료·회수를 포함합니다. 현재 첫 정상 표본과 지속 실행을 확인했습니다. 장기 결과와 다음 무인 자연 장애는 아직 진행 중이므로 #20은 열린 연구 과제로 유지합니다.
abruption commentedon Oct 25, 2026
Additional lifecycle observations — 2026-10-25 (KST)
The boot ID changed in each case and the local watchdog remained stopped. This supports recovery after a new boot, but does not establish VM replacement. Times are external sampling boundaries, not exact execution timestamps or webhook latency.
Dots reported one startup invocation and successful result recording for each case. The external observer independently confirms restored connectivity; this check did not reread the protected broker claim ledger, so exact execution counts are not independently established here.
The Oct 24 03:10:47–09:46:40 interval was blocked by the former three-claims-per-day policy and required manual resumption; exclude it from unattended recovery statistics.
A separate Mac relay interruption followed replacement/removal of its running Homebrew Python runtime. A fresh interpreter delivered successfully and a relay-only restart restored fresh ACKs at Oct 25 12:02:36, with active subscription and zero consecutive failures. The exact swallowed child exception is unavailable; see #43 for evidence and remaining runtime-maintenance work. The current findings do not close all lifecycle/recovery scenarios in this issue.
abruption commentedon Oct 25, 2026
v0.5.0 scope decision: PR #46 will deliver the current experimental research implementation, operational documentation and validated package metadata/artifacts. This issue remains open; its uncompleted acceptance criteria move to v0.6.0 rather than being marked complete. Repeated boot-change recovery is evidence for the experiment, not a guarantee of arbitrary VM replacement, general-account setup or unattended operation under every monitoring-host failure.
abruption commentedon Oct 26, 2026
v0.6.0은 #49/#51 범위로 준비합니다. 이 이슈는 지속적인 수명 주기·복구 범위 연구이므로 Research 마일스톤으로 이동하고, 특정 릴리스의 전체 해결 조건으로 취급하지 않습니다. 기존 실측과 미검증 범위는 유지합니다.