At the moment it seems that Copr web UI is not reachable. The latest reachable host in a traceroute is TI Sparkle Seabone Ashburn (VA) / Palo Alto (CA) POPs:
TI Sparkle Seabone Ashburn (VA) / Palo Alto (CA) POPs
$ traceroute copr.fedorainfracloud.org traceroute to copr.fedorainfracloud.org (3.225.109.36), 30 hops max, 60 byte packets 1 _gateway (192.168.1.1) 0.667 ms 0.976 ms 1.716 ms 2 * * * 3 172.17.200.88 (172.17.200.88) 7.332 ms 172.17.200.92 (172.17.200.92) 7.440 ms 8.592 ms 4 172.17.200.36 (172.17.200.36) 11.148 ms 172.17.200.32 (172.17.200.32) 11.243 ms 172.17.200.38 (172.17.200.38) 11.852 ms 5 172.19.184.114 (172.19.184.114) 10.656 ms 172.19.184.116 (172.19.184.116) 10.544 ms 172.19.184.114 (172.19.184.114) 11.211 ms 6 172.19.177.14 (172.19.177.14) 12.466 ms 172.19.177.24 (172.19.177.24) 6.442 ms 7.231 ms 7 195.22.205.116 (195.22.205.116) 8.425 ms 12.505 ms 195.22.205.98 (195.22.205.98) 26.302 ms 8 195.22.195.67 (195.22.195.67) 103.284 ms 105.749 ms 195.22.195.35 (195.22.195.35) 102.749 ms 9 195.22.206.61 (195.22.206.61) 101.999 ms 102.570 ms 103.337 ms 10 * * * 11 * * *
I see no outages on Fedora Infrastructure status page or AWS status page.
I've also tried to test fetching the webpage from a client located in Dulles, VA (by using webpagetest.org) and it also results in a "server not reachable" reply, so I don't think it's something on Seabone side.
Thank you for the report - I started httpd that was killed by OOM. It should work for now.
We applied a temporary larger timeout for the /backend/* URLs, so I bet it could increase memory consumption? @frostyx
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)