# runner lock

v2.136.0+ (#178). Toda operação que mexe numa app (deploy, fetch, env set, rollback…) segura um lock por app em /opt/runner/state/<app>.lock. Uma segunda operação no mesmo app recebe lock_contended. Desde a 2.136.0 a mensagem diz quem está usando:

lock_contended: outra operação está usando `minha-app` agora: deploy (origem: cli), pid 2303868.
  em andamento há 10 s; fase atual: healthcheck; última atividade há 9 s.
  situação: em andamento (processo vivo, com atividade recente). Tente de novo quando terminar.
  detalhes: `runner lock show minha-app` · histórico: `runner logs history minha-app`

# Uso

runner lock show <app>              # quem segura, origem, pid, fase, há quanto tempo
runner -o json lock show <app>      # verdict, holder, elapsed_s, idle_s
runner lock release <app> --force   # remove o lock (o processo dono continua rodando)

# Situação (`verdict`)

O runner libera sozinho um lock cujo processo morreu, ou que está há 15 min sem atividade. A idade conta da última troca de fase, não do início: um deploy longo que avança não perde o lock.

# Origem

Vem do comando que pegou o lock: --trigger (o CCS passa api e --actor <usuário>; o webhook passa webhook). Sem ele, fetch é cron e o resto é cli.

# Fetch e auto-pause

O fetch que encontra o app ocupado grava a mensagem em logs/deploy.log da app e não conta essa falha para o auto-pause: ela passa sozinha.