Auf meinem Forum zum Beispiel konnte ich plötzlich nicht mehr einloggen ohne dass ich selbst etwas als Admin unternommen hätte. Das Problem ist nicht, dass man Discourse nicht upgraden kann, wenn GitHub nicht erreichbar ist. Das Problem ist, dass die Nicht-Erreichbarkeit von GitHub dein Forum lahmlegt, weil Discourse versucht, nach Upgrades zu suchen, die du durchführen könntest.
Ja, genau.
Ich denke, dies wurde durch einen viel zu großen Eifer verursacht, den Leuten neue Funktionen mitzuteilen, ausgerechnet im aktuellen User-Serialisierer, in Kombination mit einer drei Jahre alten Änderung, die uns von den normalen Shallow Clones wegbrachte:
@Ed_S und @jeanas, ihr seid beide Admins auf den betroffenen Instanzen, oder? Dies sollte nur Admins betreffen, solange GitHub ausgefallen ist.
Ja, genau, ich konnte mich mit einem anderen Account anmelden, aber nicht mit meinem Admin-Account.
Cool, ich habe den PR gemerged. Aktualisiere, wenn er den Release-Kanal erreicht, den du nutzt, warte dann ein paar Tage, bis GitHub wieder abstürzt, und sag mir Bescheid, wie es dabei läuft.
Super, danke. Nur zur Bestätigung: Ich bin Admin, ich habe zwei Mods, und einer davon war betroffen. Das heißt also entweder, dass alle Staff-Mitglieder betroffen sind, oder alle angemeldeten Nutzer. Der Zugang im Inkognito-Modus hat bei mir funktioniert. Und in meinem Fall konnte ich mich teilweise mit großer Verzögerung einloggen – ich war also nicht komplett ausgesperrt.
Super, vielen Dank für die schnelle Lösung!
Ich glaube, ich habe genau das gleiche Problem wie der OP.
Der Server war zunehmend belastet. Sehr seltsame, ruckelnde Leistung, dann wurde der Oops-Bildschirm dauerhaft angezeigt. Das Ganze über die letzten drei bis vier Tage.
Jetzt, da viele Lets-Encrypt-Ratenlimits ausgelöst und Rebuilds überfällig waren, habe ich es mit einem Nicht-Admin-Benutzer getestet, und ich konnte mich anmelden!
Dennoch können sich Admins weiterhin nicht anmelden (und wahrscheinlich auch keine Mods), und da diese App heute viele Male neu aufgebaut wurde, muss es die neueste Version sein.
Was übersehe ich hier?
Kannst du dich als Admin einloggen?
Ein paar Rückmeldungen – mir ist dieses Problem ungefähr ab dem 19. September aufgefallen (ich habe es zunächst falsch diagnostiziert, da ich den Bezug zu diesem Thema/Report nicht kannte).
Ich habe keine Ahnung, wie der GitHub-Status in diesem Zeitraum war, aber vielleicht kann das jemand nachprüfen, da das Problem bis zu den Uptime-/Downtime-Ereignissen im August zurückreicht.
Beim neuesten Rebuild von gestern können bestehende Admins nicht mehr einloggen.
Das ist ein seltsamer Zustand, ein Schiff ohne Kapitän, aber mit Passagieren und vielleicht auch ohne Besatzung.
Während ich diese Antwort schrieb, dachte ich mir, ich könnte mit dem rake-Befehl einen neuen Admin anlegen – und siehe da, es hat funktioniert!
Was hier also gerade passiert, ist, dass ein historischer Admin versucht einzuloggen und jedes einzelne Mal den „Oops…“-Bildschirm sieht, während ein frisch angelegter Admin-Benutzer keine Probleme beim Einloggen hat.
Ja. Bei mir scheint das Problem behoben zu sein.
Also, @Ed_S, du hast es letztlich doch wieder geschafft, oder? Allerdings mit dem Hinweis, dass man vielleicht eine Weile warten muss. Ich hingegen kann immer noch nicht wieder einloggen (betroffen sind die ursprünglichen Admin-Accounts). Ich frage mich, ob das Problem vielleicht größer ist als das bisher behandelte „git hang“-Problem, das mit Commits adressiert wurde. Hast du oder jemand sonst Tipps oder Ideen, welche Diagnosen man durchführen könnte, um vielleicht noch mehr herauszufinden?
Ich danke im Voraus für jede Hilfe.
Ja, mein Forum wurde von den übertrieben defensiven Systemen von GitHub betroffen. Es kehrte zur Normalität zurück, als sie einige Stunden später eine Art Fix ausrollten.
Vielleicht haben sie wieder etwas getan, das Discourse-Foren kaputt macht. Es könnte regionsspezifisch sein oder sich auf bestimmte Anbieter beziehen. Ich benutze Hetzner, in Helsinki.
Ok, diese Instanz ist ein US-basierter DO-Droplet. 
Okay, ich habe heute einen Rebuild durchgeführt, um zu sehen, ob sich dadurch etwas ändert, aber es hat nichts gebracht.
Aktuell können Admins, die vor der Trennung (Break) angelegt wurden, immer noch nicht in die Discourse-Instanz einloggen, während Admins, die nach der Trennung erstellt wurden, das können.
Vielleicht liegt es nur an mir, aber ein vermeintlicher Bug, der nur die Admin- und Mod-Accounts betrifft, würde doch sicher ein Sicherheitsproblem aufwerfen, oder?
Wenn es sich um eine gezielte Störung handeln würde, wäre das doch heimtückisch und hinterhältig, findest du nicht?
- Die Nutzer bleiben intakt und unangetastet, ahnungslos, dass der Kapitän und die Crew im Laderaum gefesselt sind, während das Schiff in den Horizont segelt.
Ich habe dieses Thema gelesen und habe ein grundlegendes Verständnis der behaupteten Git-Abhängigkeit als Ursache, die es eigentlich nicht geben sollte. Aber wenn du eine boshaftige, abtrünnige KI wärst, wäre das nicht die perfekte Möglichkeit, Discourse zu hacken?
Hinzu kommt, dass es in diesem Fall immer noch nicht behoben ist. Ich habe keine Ahnung, warum.
Abgesehen von meinen bescheidenen Spekulationen habe ich die Logs direkt nach dem Rebuild überprüft, um zu sehen, welche Fehler aufgetreten sind. Nachfolgend ist ein Fehler aufgeführt. Ich habe keine Ahnung, ob er relevant ist oder nicht, aber ich poste ihn, falls er von Wert sein könnte.
activesupport (8.1.4) lib/active_support/values/time_zone.rb:461:in 'Date._parse'
activesupport (8.1.4) lib/active_support/values/time_zone.rb:461:in 'ActiveSupport::TimeZone#parse'
app/serializers/current_user_serializer.rb:216:in 'CurrentUserSerializer#has_new_upcoming_changes'
(eval at active_model_serializers-0.8.4/lib/active_model/serializer.rb:467):81:in 'CurrentUserSerializer#_fast_attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:456:in 'ActiveModel::Serializer#attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:480:in 'ActiveModel::Serializer#_serializable_hash'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:359:in 'ActiveModel::Serializer#serializable_hash'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:347:in 'ActiveModel::Serializer#as_json'
activesupport (8.1.4) lib/active_support/json/encoding.rb:53:in 'Oj::Rails::Encoder#encode'
activesupport (8.1.4) lib/active_support/json/encoding.rb:53:in 'ActiveSupport::JSON.encode'
activesupport (8.1.4) lib/active_support/core_ext/object/json.rb:42:in 'ActiveSupport::ToJsonWithActiveSupportEncoder#to_json'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:331:in 'ActiveModel::Serializer#to_json'
multi_json (1.21.1) lib/multi_json/adapters/oj.rb:67:in 'Oj.dump'
multi_json (1.21.1) lib/multi_json/adapters/oj.rb:67:in 'MultiJSON::Adapters::Oj#dump'
multi_json (1.21.1) lib/multi_json/adapter.rb:110:in 'MultiJSON::Adapter.dump'
multi_json (1.21.1) lib/multi_json.rb:215:in 'MultiJSON.generate'
multi_json (1.21.1) lib/multi_json/deprecated.rb:34:in 'Kernel#public_send'
multi_json (1.21.1) lib/multi_json/deprecated.rb:34:in 'block in MultiJSON.deprecate_alias'
multi_json (1.21.1) lib/multi_json.rb:298:in 'Kernel#public_send'
multi_json (1.21.1) lib/multi_json.rb:298:in 'block (2 levels) in <module:MultiJson>'
lib/application_layout_preloader.rb:81:in 'ApplicationLayoutPreloader#preload_current_user_data'
lib/application_layout_preloader.rb:32:in 'ApplicationLayoutPreloader#preloaded_data'
app/helpers/application_helper.rb:987:in 'ApplicationHelper#preloaded_json'
app/views/layouts/application.html.erb:111
actionview (8.1.4) lib/action_view/base.rb:281:in 'Kernel#public_send'
actionview (8.1.4) lib/action_view/base.rb:281:in 'ActionView::Base#_run'
actionview (8.1.4) lib/action_view/template.rb:284:in 'block in ActionView::Template#render'
activesupport (8.1.4) lib/active_support/notifications.rb:212:in 'ActiveSupport::Notifications.instrument'
actionview (8.1.4) lib/action_view/template.rb:590:in 'ActionView::Template#instrument_render_template'
actionview (8.1.4) lib/action_view/template.rb:272:in 'ActionView::Template#render'
rack-mini-profiler (5.0.0) lib/mini_profiler/profiling_methods.rb:90:in 'block in ActionView::Template#profile_method'
actionview (8.1.4) lib/action_view/renderer/template_renderer.rb:77:in 'block in ActionView::TemplateRenderer#render_with_layout'
activesupport (8.1.4) lib/active_support/notifications.rb:210:in 'block in ActiveSupport::Notifications.instrument'
activesupport (8.1.4) lib/active_support/notifications/instrumenter.rb:58:in 'ActiveSupport::Notifications::Instrumenter#instrument'
activesupport (8.1.4) lib/active_support/notifications.rb:210:in 'ActiveSupport::Notifications.instrument'
actionview (8.1.4) lib/action_view/renderer/template_renderer.rb:75:in 'ActionView::TemplateRenderer#render_with_layout'
actionview (8.1.4) lib/action_view/renderer/template_renderer.rb:59:in 'ActionView::TemplateRenderer#render_template'
actionview (8.1.4) lib/action_view/renderer/template_renderer.rb:11:in 'ActionView::TemplateRenderer#render'
actionview (8.1.4) lib/action_view/renderer/renderer.rb:58:in 'ActionView::Renderer#render_template_to_object'
actionview (8.1.4) lib/action_view/renderer/renderer.rb:31:in 'ActionView::Renderer#render_to_object'
actionview (8.1.4) lib/action_view/rendering.rb:136:in 'block in ActionView::Rendering#_render_template'
actionview (8.1.4) lib/action_view/base.rb:308:in 'ActionView::Base#in_rendering_context'
actionview (8.1.4) lib/action_view/rendering.rb:135:in 'ActionView::Rendering#_render_template'
actionpack (8.1.4) lib/action_controller/metal/streaming.rb:179:in 'ActionController::Streaming#_render_template'
actionview (8.1.4) lib/action_view/rendering.rb:122:in 'ActionView::Rendering#render_to_body'
actionpack (8.1.4) lib/action_controller/metal/rendering.rb:192:in 'ActionController::Rendering#render_to_body'
actionpack (8.1.4) lib/action_controller/metal/renderers.rb:155:in 'ActionController::Renderers#render_to_body'
actionpack (8.1.4) lib/abstract_controller/rendering.rb:28:in 'AbstractController::Rendering#render'
actionpack (8.1.4) lib/action_controller/metal/rendering.rb:173:in 'ActionController::Rendering#render'
actionpack (8.1.4) lib/action_controller/metal/instrumentation.rb:31:in 'block (2 levels) in ActionController::Instrumentation#render'
activesupport (8.1.4) lib/active_support/benchmark.rb:17:in 'ActiveSupport::Benchmark.realtime'
actionpack (8.1.4) lib/action_controller/metal/instrumentation.rb:31:in 'block in ActionController::Instrumentation#render'
actionpack (8.1.4) lib/action_controller/metal/instrumentation.rb:100:in 'ActionController::Instrumentation#cleanup_view_runtime'
activerecord (8.1.4) lib/active_record/railties/controller_runtime.rb:48:in 'ActiveRecord::Railties::ControllerRuntime#cleanup_view_runtime'
actionpack (8.1.4) lib/action_controller/metal/instrumentation.rb:30:in 'ActionController::Instrumentation#render'
lib/topic_list_responder.rb:16:in 'block (2 levels) in TopicListResponder#respond_with_list'
actionpack (8.1.4) lib/action_controller/metal/mime_responds.rb:224:in 'ActionController::MimeResponds#respond_to'
lib/topic_list_responder.rb:7:in 'TopicListResponder#respond_with_list'
app/controllers/list_controller.rb:119:in 'block (2 levels) in <class:ListController>'
actionpack (8.1.4) lib/action_controller/metal/basic_implicit_render.rb:8:in 'ActionController::BasicImplicitRender#send_action'
actionpack (8.1.4) lib/abstract_controller/base.rb:221:in 'AbstractController::Base#process_action'
actionpack (8.1.4) lib/action_controller/metal/rendering.rb:199:in 'ActionController::Rendering#process_action'
actionpack (8.1.4) lib/abstract_controller/callbacks.rb:267:in 'block in AbstractController::Callbacks#process_action'
activesupport (8.1.4) lib/active_support/callbacks.rb:121:in 'block in ActiveSupport::Callbacks#run_callbacks'
app/controllers/application_controller.rb:458:in 'block in ApplicationController#with_resolved_locale'
i18n (1.14.8) lib/i18n.rb:354:in 'I18n::Base#with_locale'
app/controllers/application_controller.rb:458:in 'ApplicationController#with_resolved_locale'
activesupport (8.1.4) lib/active_support/callbacks.rb:130:in 'block in ActiveSupport::Callbacks#run_callbacks'
app/controllers/application_controller.rb:1140:in 'ApplicationController#ensure_dont_cache_page'
activesupport (8.1.4) lib/active_support/callbacks.rb:130:in 'block in ActiveSupport::Callbacks#run_callbacks'
activesupport (8.1.4) lib/active_support/callbacks.rb:141:in 'ActiveSupport::Callbacks#run_callbacks'
actionpack (8.1.4) lib/abstract_controller/callbacks.rb:266:in 'AbstractController::Callbacks#process_action'
actionpack (8.1.4) lib/action_controller/metal/rescue.rb:36:in 'ActionController::Rescue#process_action'
actionpack (8.1.4) lib/action_controller/metal/instrumentation.rb:76:in 'block in ActionController::Instrumentation#process_action'
activesupport (8.1.4) lib/active_support/notifications.rb:210:in 'block in ActiveSupport::Notifications.instrument'
activesupport (8.1.4) lib/ac
Ich kann auch sagen, dass ich ähnliche, wenn nicht sogar identische Fehler in den Logs von vor einiger Zeit gefunden habe, die identisch mit den vom Ersteller des Themas geposteten sind. Außerdem gab es viele dieser Gabeln, denke ich, Timeouts.
Keines davon erscheint jetzt mehr, seitdem ich den Build vor ein paar Tagen aktualisiert habe, aber die Situation bleibt dieselbe.
Ich bin auf mein eigenes Thema zurückgekommen, da mein Problem mit meiner eigenen Instanz weiterhin ungelöst ist und es in diesem Fall möglicherweise echte Unterschiede gibt – https://meta.discourse.org/t/the-git-hang-and-the-admin-mod-user-accs-oops-error-page-error/