social.anoxinon.de is one of the many independent Mastodon servers you can use to participate in the fediverse.
Die offizielle Mastodon Instanz des Vereins Anoxinon e.V.

Administered by:

Server stats:

948
active users
Continued thread

In the most recent case, it was unfortunately a deadlock issue causing Forgejo to not respond within that timeout. It takes more than 15 seconds to be returned as a deadlock error. Hence, you get to see the timeout error instead of a 500 error (codeberg.org/Codeberg/Communit).

The timeout was not the issue here, although we have bumped it for POST method requests to give Forgejo extra margin to work with.

Codeberg.org500 server error creating issues/PR, commenting etc.### Comment It had been happening several hours a day for previous 3 days. E.g. when posting a comment a "loading" (sending?) spinner is visible and it spins for several seconds, then a red `! server error: 500` error bar appears and upon page refresh its clear the comment hasn't been added. ...
Continued thread

You might've encountered a 504 error, which means Forgejo did not respond within a specified timeout (15s in most cases).

When we used Caddy, we did not configure timeouts, and it would indefinitely wait for a request to finish. This is not ideal when Forgejo is under high load and gets increasingly more traffic. For HAProxy we have set a max amount of requests and timeouts to prevent (and possibly recover from) Forgejo from a state where it's overloaded and stops responding.

It has been in the works for months, but the recent increase of downtime has accelerated work. We've moved from Caddy to HAProxy for codeberg.org traffic.

Starting over with a new reverse proxy has enabled us to make choices that enable us to set up HAProxy to scale with our increasing traffic. For example, traffic is split (when possible, decided via heuristics) over several instances to load balance expensive traffic.

We hope to share more details at a later time about this change.

Continued thread

The maintenance is completed and services are expected to recover soonish (still fighting with the Codeberg e. V. forum).

We're postponing the reboot of the third machine.

Continued thread

We're uncertain about the timeframe of when we can shutdown this machine. Therefore, we're going to bring up services again for the time being, we only require them to be down just before bringing the machine down.

Continued thread

Hi,

It's taking longer than expected. Ceph made a surprise move on us at the last moment by telling us our network configuration is maybe no longer up to date after we replaced servers (not today, but a while ago). This is preventing us from deploying new monitors to keep quorum. We're working on fixing this.

It's _simply_ preventing us from gracefully shutting down, no data is at risk.

We'll be performing a reboot of all our servers this evening.

This means that our services (CI, pages, translate) will be temporarily offline. We invested a lot of effort in the last few months to be able to move Forgejo between servers easily and this should see minimal downtime.

Codeberg Status<p>Hi all, sorry for the lack of updates. We did try to fix the problem shortly afterwards (and seemingly, we did so successfully), but we were alerted a few hours later that this hiccup seemingly occurred again. Thank you to the affected users that helped us notice by reporting this to us.</p><p>We fixed the problem for now through the classic &quot;turning it off and on again method&quot;, but establishing the root cause is still a pending task. ~n</p>
Codeberg Status<p>Hi, we are aware of reports that some users are not able to submit issues/pull requests. We apologize for the hiccup and are working on fixing this problem.</p>
Codeberg Status<p>We understand that this was a long wait, but we didn&#39;t want to leave it up to chance. So, as an immediate security measure we temporarily disabled our CI. Thank you all for your patience.</p><p>CI operations (Woodpecker CI, Forgejo Actions) have been restored.</p>
Codeberg Status<p>Hi all, sorry for the long wait.</p><p>We wanted to preemptively ensure that our servers (especially the ones hosting CI/CD services) were sufficiently shielded against <a href="https://copy.fail" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://</span><span class="">copy.fail</span><span class="invisible"></span></a>; we found no evidence of a compromise.</p><p>We waited for the greater community to react and provide some additional clarity on what is affected and what isn&#39;t (e.g. container engines), we carefully studied the LKML, and waited for upstreams to release official updates and guidance.</p>
Codeberg Status<p>We estimate that the recovery process of our CI services may potentially take multiple hours. We ask for your understanding as we are trying to reinforce our services&#39; reliability.</p>
Codeberg Status<p>We are expanding our maintenance efforts to include our Forgejo Actions CI as well. Again, we apologize for the inconvenience. We&#39;ll try to bring both services back up as soon as possible.</p>
Codeberg Status<p>Our hosted Woodpecker CI/CD is going down for maintenance.</p><p>* Builds will be delayed.<br />* Web UI will be inaccessible for some minutes.<br />* Commits pushed during the downtime will not trigger builds.</p><p>We apologize for the inconvenience.</p>
Codeberg Status<p>We&#39;re investigating a downtime of our primary instance.</p>
Codeberg Status<p>Codeberg.org will be upgraded to Forgejo v15 in a few minutes. We expect downtime to be at most a few minutes, according to migration tests in the staging environment.</p>
Codeberg Status<p>We have recovered Codeberg pages v2 from an outage rendering websites inaccessible. The newer &quot;git-pages&quot; deployment was not affected.</p><p>We apologize for the disruption.</p><p>Yesterday, we deployed a change to our main Forgejo instance that was supposed to not affect the read-only shadow instance used to serve Codeberg Pages&#39; API requests. However, more than 24 hours later, the read-only instance was restarted automatically and the configuration change inadvertently prevented it from coming back up.</p>
Codeberg Status<p>We believe we have established the cause and are observing that our services are recovering. We are monitoring the situation. Should we have any further updates to make, we will let you know. Thank you for your patience.</p>
Codeberg Status<p>Hi all, we&#39;re aware that Codeberg is down right now and are investigating.</p>
Codeberg Status<p>We&#39;re up again.</p>
Codeberg Status<p>We are aware of reports of Codeberg being down and are investigating. Thank you for your patience.</p>
Codeberg Status<p>Re-indexing just started.</p>
Codeberg Status<p>This evening we will switch Codeberg.org&#39;s issue search backend from Bleve to our new OpenSearch cluster. During this transition, search results might be unavailable or inaccurate as every issue is getting re-indexed. We&#39;ve done a test on a snapshot of the data and then it took roughly 1 hour for re-indexing.</p>
Codeberg Status<p>We believe that access has been restored for the time being, we&#39;ll continue monitoring the situation for now.</p>
Codeberg Status<p>Good morning. Since a bit more than an hour ago, multiple people from our side begun working on restoring the availability of our services and will share further updates as they come.</p><p>Nothing that&#39;s impossible, it&#39;s all just a bit of a bother.</p>
Codeberg Status<p>We were able to restore IPv4 and IPv6 connectivity. Performance is still not optimal, and connections are occasionally dropping. We&#39;ve taken measures to try and maintain uptime overnight (with a certain probability).</p><p>Routes protected by iocaine (crawler protection) may return 503 errors. Currently, it appears that these packets are also occasionally being lost.</p><p>It&#39;s 2:30am, and we require a good night&#39;s sleep before we can look into this further.</p>
Codeberg Status<p>Hi everyone! We are still fighting with an ongoing DDoS attack against our service on the network level. We do not yet have any ETA on recovery time, as we&#39;re still investigating different mitigation strategies.</p><p>As always, we are very grateful for your support and patience.</p>
Codeberg Status<p>We&#39;re currently suffering from performance degradation due to heavy traffic. We are still investigating.</p>
Codeberg Status<p>Maintenance is over. Ceph is still recovering and moving data around for the next hours.</p><p>We have finally restored our 3rd host that was down for about 2 weeks. Now, we have full redundancy on the Ceph filesystem again.</p><p>Replacement of the affected server was delayed due to FOSDEM and poor performance of initial host system SSDs (which was unsuitable for operating our database cluster on it).</p>
Codeberg Status<p>We&#39;re entering Ceph filesystem maintenance. Please expect performance degradation or (in worst case) some downtime.</p>
Codeberg Status<p>We are currently struggling with database performance and investigating.</p><p>Tonight, we shipped a new server to the datacenter and started restoring Galera cluster on the node (since the hardware breakage last week, we were running on 2/3 nodes only).</p><p>We are not yet sure what is causing the sudden performance drop.</p>
Codeberg Status<p>Greetings from the emergency response team in trains and buses to <a href="https://social.anoxinon.de/tags/FOSDEM2026" class="mention hashtag" rel="tag">#<span>FOSDEM2026</span></a>! Looking forward to seeing you soon.</p>
Codeberg Status<p>About 30 minutes ago, we have recreated a runner which is currently processing the backlog of Hosted Woodpecker CI/CD builds.</p><p>Take a look at details about which jobs have been queued or missed and changes in the environment at <a href="https://codeberg.org/Codeberg/changelog/issues/4#issuecomment-10265260" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/Codeberg/changelo</span><span class="invisible">g/issues/4#issuecomment-10265260</span></a></p>
Codeberg Status<p>We have restored the Weblate (&quot;Codeberg Translate&quot;) instance from backups a few hours ago.<br />There might have been up to an hour of lost work, and we apologize for this. </p><p>In the next days, we are evaluating how to improve recovery point and time objectives for this service.</p>
Codeberg Status<p>We have finally restored access to your Codeberg Pages.</p><p>Weblate and Hosted Woodpecker CI/CD will unfortunately have to remain offline.</p><p>We are currently unable to access any of the two boot devices on that host and we are currently evaluating whether we can rescue the latest data or restore from one of the hourly system snapshots (which would involve data loss since the last snapshots).</p><p>We&#39;ll proceed with further investigation and a decision after some sleep.</p>
Codeberg Status<p>Hardware maintenance on the 3rd server (the one that had a broken SSD and was the reason for the maintenance) did not succeed.</p><p>We have to keep it down and continue debugging remotely.</p><p>This affects Weblate, Hosted Woodpecker CI/CD and some other services.</p><p>We apologize for the issue and will work on restoring access to them as soon as possible.</p>
Codeberg Status<p>During the following steps, we did an elevated amount of human errors (likely attributed to increased stress) and had more downtime of Codeberg.org than initially expected.</p><p>This was due to a configuration error that made the &quot;failover&quot; instance still depend on a service hosted on the primary server, and so the failover also became unavailable when the primary went down for maintenance.</p><p>It took us a few minutes to realize and correct the mistake.</p>