ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
hakel2020 schrieb: … Ich würde apport entfernen, um das Ganze zu stabilisieren.
sudo apt-get purge whoopsie apport apport-gtk
…
ChickenLipsRfun2eat schrieb: … hakel2020 schrieb: Ich würde apport entfernen, um das Ganze zu stabilisieren.
Den Melder zu entfernen löst das Problem nicht.
…
hakel2020 schrieb: … Das ist kein "Melder" im Sinne von hilfreich ... gerade in letzter Zeit gab es wieder ein paar Threads dazu. 🙄 https://wiki.ubuntuusers.de/Apport/
Hilfreich ist der insofern, als dass irgendein Programm abgestürzt ist. Und das sollte man nachverfolgen. Ob das nun etwas essentielles ist, oder nur eine falsche Startreihenfolge kommt dabei natürlich nicht raus. Ich sehe das als „Hey, guck mal, da is was abgestürzt.“. Mehr sollte man da nicht reininterpretieren. Da Anwendungen aber im Normalfall nicht abstürzen sollten, ist es hilfreich das zu verfolgen (mit gdb/valgrind & Co, nicht mit apport 😉 ). Wer fleißig sein journalctl liest, der braucht das natürlich nicht.
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
apport ist ein Dienst, der normierte Berichte aus den Logs generiert und an Canonical schickt. Ursprünglich wurde das nur vom Entwicklerkreis von Ubuntu verwendet, was natürlich Sinn macht. Niemand weiß, warum das im Standard aktiviert verteilt wird. Kein Supporter fragt hier im Forum nach crash Dateien. Canonical hat dafür bestimmt entsprechende Tool, oder das landet komplett in der Statistik. Mag sein, daß apport in "bestimmten Situationen" von einem Pro gezielt eingesetzt werden kann. Nachteile für den Normalo meldet Müll, zu empfindlich eingestellt Spammt var/Log voll kann durchaus selber zum Ärgernis werden nicht hilfreiche Berichte
Kurz, man könnte den dienst aktivieren, wenn man einen "Verdacht" hat, daß etwas nicht rund läuft. Sonst halt besser bei Bedarf in die Logs schauen.
|
ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
hakel2020 schrieb: Mag sein, daß apport in "bestimmten Situationen" von einem Pro gezielt eingesetzt werden kann.
Ich finde eine grafische Information gerade für „Nicht-Pros„ (wie auch immer du das definierst) eine gute Hilfe, um zu merken das da was im argen liegt. Dadurch, dass bspw. systemd die erforderlichen Dienste immer wieder neu zu starten versucht, bis sie irgendwann laufen, merkt das der Anwender ja nicht „von alleine“.
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
Ich stimme dir zu, nur macht der apport das nicht in der Praxis. -schön wär's- 🙄 apport zu entfernen ist nur eine Empfehlung aus der Praxis von mir, mehr nicht. P.S. Ich schätze, du stehst mit deiner Haltung zu apport relativ einsam da. Nicht böse gemeint ...!
|
ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
hakel2020 schrieb: P.S. Ich schätze, du stehst mit deiner Haltung zu apport relativ einsam da. Nicht böse gemeint ...!
Dann frage ich mich, wieso das so ist. Ich dachte bisher wir leben hier vom Mitmachen. Anstatt immer nur zu meckern oder abzuraten, wie wäre es mal mit verbessern oder unterstützenswerte Alternativen aufzeigen?
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
Das wird etwas OT. Die Diskussion könnte man an einer anderen Stelle führen. Das Thema apport ist aber nach meinem subjektiven Ermessen hier im Forum "durch".
|
ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
hakel2020 schrieb: Die Diskussion könnte man an einer anderen Stelle führen. Das Thema apport ist aber nach meinem subjektiven Ermessen hier im Forum "durch".
Ich hab mich mal daran versucht den Verlauf herauszuzitieren. Was siehst du denn als Alternative für „Normalbenutzer“? Ich bin mit journalctl happy und muss das eh manuell verfolgen, da ich in den meisten Systemen keinen Notifier nutze, der mich mit „wichtigen Informationen“ aus der Konzentration reisst. Da ich meine Updates auch noch immer manuell mache, ist das ein Abwasch, den ich meist am frühen Morgen und/oder am spätend Abend mache.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53598
Wohnort: Berlin
|
hakel2020 schrieb: apport ist ein Dienst, der normierte Berichte aus den Logs generiert und an Canonical schickt.
Die in der Regel vollkommen unbrauchbar sind. Schau dir mal an, wie viele automatisch generierte, "normierte" Bugreports bearbeitet wurden. Die Zahl dürfte so zwischen Null und Null liegen. Vielleicht sind es aber inzwischen auch schon Null.
Ursprünglich wurde das nur vom Entwicklerkreis von Ubuntu verwendet, was natürlich Sinn macht.
Naja, auch vom Tester-Kreis. Es war ja nur in den Entwicklungsversionen standardmäßig installiert und aktiviert, eben für die Tester.
Niemand weiß, warum das im Standard aktiviert verteilt wird.
Ich hab jetzt nicht die öffentlichen (kann natürlich auch in einer nicht öffentlichen diskutiert worden sein) Entwickler-Mailinglisten durchgesehen, aber irgendjemand wird das schon da eingefügt haben, also weiß der vermutlich auch, was er sich dabei gedacht hat. Würden sicherlich viele andere auch gerne wissen.
Kein Supporter fragt hier im Forum nach crash Dateien.
Das hat auch einen Grund: Apport ist in der Regel komplett unbrauchbar. Entweder es meldet Fehler, wo keine sind, oder drei Wochen lang dauerhaft, dass vor drei Wochen ein Status-Applet abgestürzt ist oder solche Kindereien. Ich kann mich an keinen einzigen Fall hier erinnern, in dem Apport etwas hilfreiches, das zur Behebung eines echten Fehlers beigetragen hätte, geliefert hätte. Bin allerdings auch noch nicht so lange hier. 😛
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53598
Wohnort: Berlin
|
ChickenLipsRfun2eat schrieb: Ich dachte bisher wir leben hier vom Mitmachen. Anstatt immer nur zu meckern oder abzuraten, wie wäre es mal mit verbessern oder unterstützenswerte Alternativen aufzeigen?
Apport ist ein Tool, dass das, was es können will, nicht beherrscht. Es nicht zu benutzen ist durchaus eine Alternative, davon abzuraten also auch. Kann mich auch nicht erinnern, dass hier mal gefordert worden wäre, man solle nicht nur von bleachbit abraten, sondern eine funktionierende Alternative nennen. Die Gründe dafür sollten klar sein und sind auch analog auf Apport anwendbar.
|
ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
tomtomtom schrieb: Apport ist ein Tool, dass das, was es können will, nicht beherrscht. Es nicht zu benutzen ist durchaus eine Alternative, davon abzuraten also auch…
Im Gegensatz zu bleachbit zerstört es aber nicht die Installation. Es sammelt nur meist nutzlose Informationen, was daran liegen könnte, wie die Programme in den Repos kompiliert werden. Da müsste ich erst mal nachgucken, wie das funktioniert. War da nicht was, dass man unter Ubuntu die debug-Symbole separat installieren konnte? Eine Alternative wäre da sinnvoll, die den Nutzer auf einen Crash aufmerksam macht. Journalctl guckt sich wohl kaum jemand an. Eventuell könnte man das hier ein wenig ausarbeiten: Die popup-Meldung ist super, damit weiß man, das Programm xy in irgend einer Form einen crash verursacht hat. Das ist aus meiner Sicht auch der einzige Nutzen, da die backtrace nur sinnvoll ist, wenn man Programme mit debug-symbolen nutzt (gcc -g ), was vermutlich auch niemand tut — und die, die das tun, die können bestimmt das journal filtern… Und warum meldet Apport was 3 Wochen lang? Weil sich keiner drum gekümmert hat. Dafür kann das Programm ja auch nichts^^ Soweit ich mich erinnere musste man dazu die Dateien unter /var/crash/(?) entweder senden, löschen oder sonst wie als „bearbeitet markieren“. Weiß einer von euch, wie Apport funktioniert? Theoretisch könnte man das ja durch ein „Nur-Popup-Script“ ersetzen, das über org.freebus.Notifications funktioniert. Das haben ja alle *buntus.
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
Im Gegensatz zu bleachbit zerstört es aber nicht die Installation.
Da hatten wir hier aber auch andere Fälle! "Verzweifelte Nutzer (dramatisiert)" die ihrer vermeintlichen Pflicht nachkommen wollten und dann gegen die "Canonical Wand" gerannt sind, oder Leute die schlicht in "Dumps" abgesoffen sind. Was ja bekanntlich nicht ganz ungefährlich ist. Man kann das alles natürlich auf die "Blödheit" der Nutzer schieben, aber apport ist so im Moment kontraproduktiv. Nochmal, ich will dich nicht angreifen! Ich sage nur meine völlig subjektive Meinung aus der Praxis. Ein Automatismus (Dienst), der sinnvolle und lesbare Protokolle generiert und per Notification dem User meldet, wäre schön, ist mir aber nicht bekannt. P.S. apropos bekannt - gab es da mal nicht so ein Script für Supporter hier im Forum, das Infos von Normalos gesammelt hat?
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29043
Wohnort: WW
|
Hallo, im Wikiartikel zu Apport steht doch alles, wie wann was übertragen wird und wie man das konfiguriert. Gruß, noisefloor
|
ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
noisefloor schrieb: im Wikiartikel zu Apport steht doch alles, wie wann was übertragen wird und wie man das konfiguriert.
Da steht zwar, wie ich es zum hochladen bewegen kann (Dateiendung .upload), aber nicht wie ich dem sagen kann, dass das Thema „abgeschlossen“ ist und nicht bei jedem Neustart wieder gemeldet wird. Oder ich bin zu blind, dann bitte kurz mit der Nase draufstumpen 😉 hakel2020 schrieb: Nochmal, ich will dich nicht angreifen! Ich sage nur meine völlig subjektive Meinung aus der Praxis.
Ich fühle mich nicht angegriffen. Ich sehe uns nur in der Pflicht bei solchen Empfehlungen eine Alternative zu bringen, da es ja nicht irrelevant ist, wenn Anwendungen crashen.
Ein Automatismus (Dienst), der sinnvolle und lesbare Protokolle generiert und per Notification dem User meldet, wäre schön, ist mir aber nicht bekannt.
Naja, die Backtrace kannst du wie gesagt durch die Installation der debug-Pakete brauchbar machen, bzw. durch selbst kompilieren mit -g, wenns keins gibt.
P.S. apropos bekannt - gab es da mal nicht so ein Script für Supporter hier im Forum, das Infos von Normalos gesammelt hat?
Imho gab es Ansätze, wurde aber ob der Komplexität verworfen. Für Plasma gibt es sowas ab Werk (qdbus org.kde.KWin /KWin supportInformation), welches die relevanten Paketversionen, Effekte, und was so ein Desktop mitbringt zusammenfasst. Für das Grundsystem gibt es journalctl , bspw. journalctl -b -xep 4 für alle Fehler und Warnungen seit Reboot oder journalctl -p 4..4 für nur Warnungen. Da findet man auch Abstürze. Was gnome angeht, kann ich nicht helfen. Ich nutze aktuell nur noch sway (oder dwm auf X) und springe gelegentlich mal auf ein anderes tty um in Plasma was nachzugucken.
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
im Wikiartikel zu Apport steht doch alles, wie wann was übertragen wird und wie man das konfiguriert.
Es geht doch um die Leute, die das Wiki nicht kennen und/oder nicht lesen und/oder nicht verstehen. Davon gibt es eine Menge!
auf die "Blödheit" der Nutzer schieben,
Wer ein Problem hat, möchte erst mal eine Lösung und da hilft apport eher nicht. Normale "Hilfesuchende" sind auch nicht die Zielgruppe von apport. Es wird sicher wie bei Windows klar definierte "Kreise" geben. Eine Alternative zu apport, wäre also im Grunde ein völlig anderer Ansatz, der so nicht existiert.
Für Plasma gibt es sowas ab Werk (qdbus org.kde.KWin /KWin supportInformation)
Etwas "Desktopübergreifendes" wäre an dieser Stelle/Kontext sinnvoller. Es gilt das Prinzip "jeder denkt nur an sich". ☹ Alles Stückwerk ...
|
ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
hakel2020 schrieb: auf die "Blödheit" der Nutzer schieben,
Wer ein Problem hat, möchte erst mal eine Lösung und da hilft apport eher nicht. Normale "Hilfesuchende" sind auch nicht die Zielgruppe von apport. Es wird sicher wie bei Windows klar definierte "Kreise" geben.
Wieso zitierst du dich da selbst? 😀 Aber egal: Wie gut apport wirklich funktioniert kann ich nicht sagen, es ist aber relativ sinnfrei das ohne debug-Symbole laufen zu lassen. Unter Plasma gibt es da aber eine Schaltfläche, um diese nachzuinstallieren, damit werden die Reports auch besser / brauchbar. (Nachtrag: Ich weiß gar nicht, ob das in Kubuntu geht, da das nicht apport ist, sondern der KCrashHandler die Grundaufgaben bearbeitet)
Eine Alternative zu apport, wäre also im Grunde ein völlig anderer Ansatz, der so nicht existiert.
Welcher denn? Um den Nutzer nur zu informieren, dass etwas gecrasht ist, könnte man sicher was kleineres als Apport nehmen. Da gibt es sicher ein dbus-Event für.
Für Plasma gibt es sowas ab Werk (qdbus org.kde.KWin /KWin supportInformation)
Etwas "Desktopübergreifendes" wäre an dieser Stelle/Kontext sinnvoller. Es gilt das Prinzip "jeder denkt nur an sich". ☹
Das funktioniert aber nicht desktopübergreifend, weil die GTK-Desktops kein Qt haben, und schon gar kein KWin. Umgekehrt kannst du unter Plasma nicht mutter ansprechen, etc. Grafische Umgebungen müssen da also ihr eigenes Werkzeug liefern. Benennen könnte man das gleich, evtl sogar eine „offizielle Maske“ dafür entwickeln. Das wäre was für freedesktop.org, falls die nicht sowas schon haben.
|