DongHyeonkaandClaude Opus 5
e9baac21d5
D-4 named the fix and never ran it. Running it:
/etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
#!/bin/sh
nginx -t && nginx -s reload
certbot reports "Hook 'deploy-hook' ran", the master stays at PID 585 and
the worker is replaced 28829 -> 37252, and the served certificate changes.
One trap worth naming: certbot prefixes the hook output with "ran with error
output" whenever the hook writes anything to stderr, and nginx's routine
types_hash warning goes to stderr. Everything inside is success — "test is
successful", "signal process started". A monitor that greps for "error"
would read a working hook as a failure. The worker PID is what to check.
Timing needed a clock correction. test-server has NTP off and runs 106
seconds fast; the dev machine matches Google and the Let's Encrypt ACME
endpoint exactly. Corrected, the hook's nginx -t lands at 12:27:50 UTC
against the new certificate's SCT at 12:27:49.054 — one second. The
correction validates itself: uncorrected, the hook would have run 104
seconds before the certificate existed.
That same skew is why D-4's gap was reported 106 seconds short; corrected to
2305s in the previous commit.
Remaining and left alone: whether certbot-renew.timer performs a real
renewal, which cannot be tested for about 89 days.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
14 lines
510 B
Plaintext
14 lines
510 B
Plaintext
=== 실행 후 상태 (dev 머신에서 관측) ===
|
|
수집 2026-09-04T12:29:05Z UTC
|
|
|
|
-- nginx 프로세스
|
|
585 1 95412 Thu Sep 3 19:00:39 2026 nginx: master process /usr/bin/nginx
|
|
37252 585 74 Fri Sep 4 21:29:36 2026 nginx: worker process
|
|
|
|
-- 서빙 인증서
|
|
serial=06F3E0EF4D1BB03DE58130EAAD1176101373
|
|
notBefore=Sep 4 11:29:18 2026 GMT
|
|
notAfter=Dec 3 11:29:17 2026 GMT
|
|
X509v3 Subject Alternative Name:
|
|
DNS:app1.hyeonworks.com, DNS:app2.hyeonworks.com, DNS:auth.hyeonworks.com
|