{"id":"IL-0265","org":"Open Build Service","date":"2023-01-05","docs":[],"title":{"en":"Open Build Service returned 503 errors for about two hours after an HAProxy package update changed its configuration","ko":"HAProxy 패키지 업데이트 뒤 Open Build Service 참조 서버가 약 2시간 동안 내려갔다"},"domain":["networking"],"impact":{"scope":"OBS reference server: API and web interface unavailable, answering with a maintenance message or HTTP 503","users":"everyone using the OBS reference server","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The OBS team wants to analyse the consequences of running \"zypper up\" more carefully, because some upgrades need attention. Secondary machines and their configuration need watching too: although everything is usually deployed with Salt, the certificates for the secondary machines were missed. When Passenger is started through Apache, it will not start if Apache has problems, so the whole Apache configuration should be checked even when the daemon starts without visible errors. The team also noted to expect the unexpected after a long vacation break.","ko":"\"zypper up\" 을 실행하면 무엇이 바뀌는지 더 잘 따져 봐야 한다. 업그레이드 중에는 주의가 필요한 것이 있기 때문이다. 보조 서버와 그 설정도 지켜봐야 한다. 평소에는 Salt 로 모든 것을 배포하지만 이번에는 보조 서버의 인증서를 놓쳤다. Apache 를 통해 Passenger 를 시작하면, Apache 에 문제가 있을 때 Passenger 프로세스가 뜨지 않는다. 그러므로 데몬이 문제없이 떠 있어도 Apache 설정 전체를 두 번 확인해야 한다. 긴 휴가 뒤에는 예상하지 못한 일이 생길 것이라고 생각해야 한다."},"related":[],"sources":[{"url":"https://openbuildservice.org/2023/01/05/post-mortem/","kind":"blog","archived":"https://web.archive.org/web/20241005102723/https://openbuildservice.org/2023/01/05/post-mortem/"}],"summary":{"en":"OBS runs updates during its maintenance windows on Thursdays from 8AM to 10AM CET/CEST. On 5 January 2023 an update started at 10:26 UTC, after the window, because its end was wrongly assumed to be 11AM. The updated haproxy package included configuration changes the team had not expected, and OBS went down at 10:27. The secondary HAProxy system could not take over, since the automated sync of renewed certificates to it had stopped without notice; OBS deploys with Salt, but the certificates of the secondary machines had been missed.\n\nThe team adapted all the HAProxy configuration files from 10:47, but the service stayed down because a \"MAINTENANCE\" flag left in the Apache configuration on another server kept that Apache serving the maintenance page instead of starting Passenger. At 12:18 the team removed the flag and restarted the server, and OBS was up again at 12:20. No permanent damage was done.","ko":"2023년 1월 5일, Open Build Service 팀은 참조 서버의 패키지를 업데이트했다. 이런 작업은 보통 CET/CEST 기준 목요일 오전 8시부터 10시까지의 점검 시간에 한다. 이번에는 점검 시간이 11시에 끝난다고 잘못 알고, 점검 시간이 지난 뒤에 시작했다. 10시 26분 UTC 에 zypper 업데이트를 시작했고 1분 뒤 OBS 가 내려갔다. 업데이트된 haproxy 패키지에 예상하지 못한 설정 변경이 들어 있었다.\n\n10시 35분에 보조 HAProxy 시스템으로 넘기려 했지만 소용이 없었다. 갱신된 인증서의 자동 동기화가 예고 없이 멈춰 있어서, 보조 시스템에는 옛 인증서가 남아 있었다. 팀은 10시 47분부터 HAProxy 설정 파일을 고쳤다. 그래도 서비스는 올라오지 않았다. 다른 서버의 Apache 설정에 \"MAINTENANCE\" 플래그가 남아 있었기 때문이다. 그 서버는 평소 이 플래그를 쓰지 않았다. 그 Apache 는 점검 페이지를 보여 주고 Passenger 를 시작하지 않았다. 12시 18분에 플래그를 지우고 서버를 재시작했고, 12시 20분에 OBS 가 다시 올라왔다. 참조 서버는 약 2시간 동안 내려가 있었고 영구적인 손상은 없었다."},"trigger":{"en":"The haproxy package on the reference server was updated with zypper; the update started after the Thursday maintenance window had ended, because the window was wrongly assumed to end at 11AM.","ko":"참조 서버에서 zypper 업데이트로 haproxy 패키지를 업데이트했다."},"severity":"unknown","symptoms":["service-unavailable"],"timeline":{"detected_after":"0m","resolved_after":"1h 53m"},"date_kind":"incident","detection":{"en":"Both the team and customers saw that the application was down right after the update; customers reported it through different communication channels.","ko":"팀과 사용자 모두 애플리케이션이 내려간 것을 알아챘다. 사용자들이 여러 소통 채널로 알려 왔다. 문제는 업데이트 직후에 드러났다."},"components":["haproxy"],"root_cause":"upgrade-breaking-change","remediation":[{"text":{"en":"Adjusted all the HAProxy configuration files","ko":"HAProxy 설정 파일을 모두 고쳤다."}},{"text":{"en":"Removed the maintenance mode flag from the Apache configuration","ko":"다른 서버의 Apache 설정에 남아 있던 점검 모드 플래그를 지웠다."}},{"text":{"en":"Restarted the server","ko":"서버를 재시작했고, 12시 20분 UTC 에 OBS 가 다시 올라왔다."}}],"action_items":[{"text":{"en":"Discuss whether a maintenance configuration block is a benefit or a problem","ko":"점검 모드 설정 블록이 도움이 되는지 문제가 되는지 논의한다."}},{"text":{"en":"Review the synchronization of SSL certificates for the secondary proxies","ko":"보조 프록시들의 SSL 인증서 동기화를 다시 살핀다."}}],"contributing":["overlapping-failures","monitoring-blind-spot","config-not-in-code"],"recurrence_of":null,"symptoms_text":{"en":"On 5 January 2023 the Open Build Service (OBS) reference server went offline for about two hours, one minute after a package update started at 10:26 UTC. The application answered with a maintenance message or an HTTP 503 error (Service Unavailable), and nobody could work with the API or the web interface.\n\nThe updated haproxy package had brought configuration changes that the team did not expect. Switching to the secondary HAProxy system at 10:35 did not help, because that system's certificates were out of date: the automated sync of renewed certificates had stopped without any notice. The team started adapting the configuration at 10:47.\n\nAfter the configuration files were adapted, the service still did not come back, and from 11:27 the team was debugging why. A \"MAINTENANCE\" flag had been left in the Apache configuration on another server, a machine that is usually not run with that flag. With the flag set, that Apache showed the maintenance page and did not start Passenger, even though the Apache daemon itself started without visible problems.","ko":"업데이트 직후 Open Build Service 참조 서버가 내려갔다. 애플리케이션은 점검 안내 메시지나 HTTP 503 Service Unavailable 오류로 응답했고, 아무도 API 와 웹 화면을 쓸 수 없었다. 팀도 사용자도 이를 알아챘고, 사용자들은 여러 채널로 알려 왔다.\n\n팀은 먼저 보조 HAProxy 시스템으로 넘기려 했지만 실패했다. 보조 시스템의 인증서가 갱신되지 않은 옛것이었기 때문이다. 갱신한 인증서를 자동으로 동기화하던 작업이 아무 알림 없이 멈춰 있었다.\n\n업데이트된 HAProxy 패키지가 예상하지 못한 설정 변경을 함께 들여왔다. 팀은 설정 파일을 고쳤지만 서비스는 한동안 계속 내려가 있었고, 팀은 서버가 왜 다시 올라오지 않는지 원인을 짐작해 가며 디버깅했다.\n\n원인은 다른 서버의 Apache 설정에 남아 있던 \"MAINTENANCE\" 플래그였다. 이 플래그 때문에 그 Apache 는 점검 페이지를 보여 주고 Passenger 를 시작하지 않았다. 이 플래그를 아무도 알아채지 못했다. Apache 데몬 자체는 눈에 띄는 문제 없이 떠 있었다."},"updated_at":"2026-11-14T12:33:51.666395Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0265","org_slug":"open-build-service"}