ubuntuusers.de

Wie lautet denn der Workaround, wenn "snap update" mit dem Fehler "Fehler: Mit dem snap-Store konnte keine Verbindung hergestellt werden" abbricht und der Host nicht anpingbar ist? Muss ich mit den Abbrüchen von "snap update" leben (und diese entsprechend abfangen, also wieder Mehraufwand)? Oder gibt es eine Configurationsoption, die in diesem Fall keinen Returncode != 0 zurück liefert und nicht einfach so fortfährt, als wäre der Server, über den ich ohnehin keinerlei Hoheit habe, verfügbar wäre? Ist es wirklich ne gute Idee, einen zentralen Bestandteil wie Systemupdates an einen Host wie api.snapcraft.io zu binden, der ggf. mal nicht erreichbar ist, bzw. eher nicht zuverlässig ist :/ ?

Die Canonical Server waren nicht erreichbar.

https://x.com/ubuntu/status/2120564228541088085

Mittlerweile ist es wieder ok.

https://status.canonical.com/#/

hdz schrieb:

[…] Workaround, wenn "snap update" mit dem Fehler "Fehler: Mit dem snap-Store konnte keine Verbindung hergestellt werden" abbricht […]

Einen solchen Befehl gibt es nicht und ein nicht existierender Befehl kann auch keinen Fehler melden und auch keinen Return-Code liefern.

Der Befehl

snap refresh 

liefert aber ordnungsgemß den Fehlercode 1, wenn der Server nicht erreicht werden kann.

hdz schrieb:

Muss ich mit den Abbrüchen von "snap update" leben (und diese entsprechend abfangen, also wieder Mehraufwand)?

Im Skript kann man den Aufruf eigentlich ganz weglassen: snapd aktualisiert die Snaps ohnehin selbst, standardmäßig viermal am Tag (den Zeitplan zeigt snap refresh --time). Fällt der Store mal aus, wird das beim nächsten Lauf nachgeholt. Wer den Aufruf trotzdem drin haben will, fängt den Fehler eben bewusst ab, z. B. mit snap refresh || true. Ping ist übrigens kein guter Test, solche Hosts antworten oft gar nicht auf ICMP.

Kätzchen schrieb:

Die Canonical Server waren nicht erreichbar.

Das hab ich ebenfalls herausgefunden, trotzdem danke für den Hinweis und den Link zum Post!

kB schrieb:

Einen solchen Befehl gibt es nicht und ein nicht existierender Befehl kann auch keinen Fehler melden und auch keinen Return-Code liefern.

Das war natürlich ein Fehler im Post. Was aber eigentlich offensichtlich ist, da ein Aufruf von "snap update" definitiv einen Fehler mit einen RC = 64 liefert. Damit wäre mein Skript ja nicht ein einziges Mal erfolgreich gelaufen. Ein nicht existierender Befehl liefert übrigens einen RC = 127. Trotzdem danke für den Hinweis.

kB schrieb:

Der Befehl

snap refresh 

liefert aber ordnungsgemß den Fehlercode 1, wenn der Server nicht erreicht werden kann.

Hast du bitte nen Link zur Doku der Returncodes? Das wäre möglicherweise DIE Lösung für mein Problem. Die man-Page für snap schweigt sich dazu leider aus.

kuchenrold schrieb:

Im Skript kann man den Aufruf eigentlich ganz weglassen: snapd aktualisiert die Snaps ohnehin selbst, standardmäßig viermal am Tag (den Zeitplan zeigt snap refresh --time).

Dann sollte ich das mal bei nem aktuellen System prüfen... Der Aufruf ist nicht grundlos im Skript drin (dafür bin ich viel zu faul) und war in der Vergangenheit offenbar notwendig.

kuchenrold schrieb:

Wer den Aufruf trotzdem drin haben will, fängt den Fehler eben bewusst ab, z. B. mit snap refresh || true.

Das liefert dann aber auch keinen Fehler, falls beim lokalen Verarbeiten ein Problem auftritt. Also völliger Blindflug. Ich meinte eine Option in dem Sinne: kein Fehler, wenn der API-Server nicht erreichbar ist. Die man-Page von snap listet leider auch keine Returncodes und deren Bedeutung, so dass auch darüber nicht sinnvoll gefiltert werden kann.

Ping ist übrigens kein guter Test, solche Hosts antworten oft gar nicht auf ICMP.

api.snapcraft.io antwortet auf ICMP-Anfragen. Der curl-Befehl war ebenso erfolglos, nur brauch ich den HTTPS-Request gar nicht erst stellen, wenn der Server nicht auf ICMP reagiert. Deshalb hab ich nur den ping im Post erwähnt, um deutlich zu machen, dass der Server nicht erreichbar ist.

Also vielen Dank an alle, die hier bei meinem Problem mithelfen! Ich sehe jetzt 2 Ansatzpunkte: 1. prüfen, ob der Automatismus mittlerweile funktioniert und der Befehl erst gar nicht notwendig ist und 2. anhand einer Doku zu den Returncodes die Abbrüche von snap zu filtern.

Moin hdz,

suchst Du so was wie das hier oder das?

Grüße

schollsky

schollsky schrieb:

Moin hdz,

suchst Du so was wie das hier oder das?

Genau sowas habe ich gesucht! Vielen Dank!

Nur leider hilft mir das in meinem Fall nur begrenzt, da RC = 1, der bei Nicht-Erreichbarkeit des API-Servers geliefert wird, für "The command failed for a reason not covered by a more specific exit code.". Aha, Danke, Canonical, für diese detaillierte Auskunft.

Ich glaube, ich wechsel jetzt zu Mint, nachdem ich mehrere Probleme mit Chromium und Thunderbird als Snap hatte. Und das, obwohl ich seit Kubuntu 5.04 dabei bin und entsprechend eng gebunden bin, aber ich sehe einfach zu viele Probleme mit snap... Upstart damals hat wenigstens funktioniert.

Es zwingt dich doch keiner Snaps zu nutzen. Nicht mal Canonical tut das. Nur weil etwas vorinstalliert ist muss man es doch nicht behalten.

schwarzheit schrieb:

Es zwingt dich doch keiner Snaps zu nutzen. Nicht mal Canonical tut das. Nur weil etwas vorinstalliert ist muss man es doch nicht behalten.

Der Aufwand, Firefox, Chromium oder Thunderbird ohne snap per PPA zu installieren, ist schon höher als ein einfaches "apt install ...". Oder gibt es eine einfache Möglichkeit, bei Ubuntu komplett auf snap zu verzichten, da ich bisher nur viele Nachteile, aber keine für mich praktischen Vorteile sehe?

>> snap/snapd deinstallieren <<

schwarzheit schrieb:

>> snap/snapd deinstallieren <<

Danke für den Link, das sieht schon interessant aus. Hatte vermutet, dass snapd elementar für's System ist.

Kannst du mir evtl. auch sagen, was danach bei einem "apt install firefox" passiert, wenn dieses Package auf Snap verweist?

Das steht doch alles im verlinkte Artikel.

Du hast recht, sorry, dass ich nicht bis zum Ende geschaut habe.

Ist aber schon ein ganz schöner Zusatzaufwand, der eine Neuinstallation von Ubuntu gegenüber Mint unnötig erschwert. Und bei Neuinstallationen von ursprünglichen snap-Paketen wirds ebenso unnötig aufwendig. Da bietet Canonical vermutlich keine elegantere Lösung, oder?