Pop!_OS Hintergrund-Dienst nervt, da er mein Update-Script behindert

[Tanzmusikus]

Hallo Linuxer/innen,

mich nervt, dass beim Start von Pop!_OS immer erstmal ein sudo apt update o.s.ä. im Hintergrund läuft.
Wenn ich dann mein Update-Script zeitnah laufen lasse, bekomme ich oft diese Fehlermeldung:

Paketlisten werden gelesen… Fertig
E: Sperre /var/lib/apt/lists/lock konnte nicht erlangt werden. Sie wird von Prozess 1234 (packagekitd) gehalten.
N: Beachten Sie, dass das Entfernen der Sperrdatei keine Lösung ist und Ihr System beschädigen kann.
E: Das Verzeichnis /var/lib/apt/lists/ kann nicht gesperrt werden.

Ich habe bereits in der grafischen Oberfläche "Startprogrammeinstellungen" den "Pop!_OS Release Check" deaktiviert.

Das reicht offensichtlich nicht aus um das Problem zu lösen.
Im Nachbar-Thema habe ich diesen Befehl gesehen & ausprobiert:

Spoiler: systemd-analyze blame

systemd-analyze blame
3.527s NetworkManager-wait-online.service
2.289s fwupd.service
 336ms dev-nvme0n1p4.device
 283ms tor@default.service
 263ms accounts-daemon.service
 202ms gpu-manager.service
 192ms systemd-udev-trigger.service
 183ms qemu-kvm.service
 170ms cups.service
 169ms user@1000.service
 164ms udisks2.service
 151ms com.system76.Scheduler.service
 148ms firewalld.service
 111ms systemd-resolved.service
 111ms networkd-dispatcher.service
 110ms recovery.mount
 104ms com.system76.PowerDaemon.service
  90ms systemd-journal-flush.service
  88ms fwupd-refresh.service
  87ms systemd-cryptsetup@cryptswap.service
  80ms apparmor.service
  80ms systemd-journald.service
  74ms pop-default-settings-zram.service
  74ms lvm2-monitor.service
  74ms lm-sensors.service
  72ms systemd-logind.service
  68ms smbd.service
  66ms apport.service
  66ms upower.service
  65ms systemd-sysusers.service
  64ms avahi-daemon.service
  63ms virtualbox.service
  61ms systemd-modules-load.service
  60ms ModemManager.service
  59ms systemd-pstore.service
  58ms systemd-sysctl.service
  54ms cosmic-greeter-daemon.service
  54ms gdm.service
  50ms nmbd.service
  47ms networking.service
  46ms grub-common.service
  44ms systemd-udevd.service
  39ms dev-hugepages.mount
  39ms keyboard-setup.service
  38ms dev-mqueue.mount
  38ms polkit.service
  38ms sys-kernel-debug.mount
  38ms sys-kernel-tracing.mount
  34ms systemd-random-seed.service
  33ms e2scrub_reap.service
  33ms chrony.service
  31ms switcheroo-control.service
  31ms modprobe@fuse.service
  31ms modprobe@efi_pstore.service
  30ms kmod-static-nodes.service
  30ms systemd-fsck@dev-disk-by\x2duuid-xxxx\xyzabcd.service
  29ms rsyslog.service
  28ms modprobe@configfs.service
  28ms modprobe@drm.service
  27ms binfmt-support.service
  27ms dbus-broker.service
  27ms packagekit.service
  26ms wpa_supplicant.service
  25ms systemd-tmpfiles-setup.service
  25ms alsa-restore.service
  25ms systemd-remount-fs.service
  24ms sys-kernel-config.mount
  24ms resolvconf-pull-resolved.service
  23ms NetworkManager.service
  22ms sys-fs-fuse-connections.mount
  21ms colord.service
  20ms grub-initrd-fallback.service
  18ms systemd-binfmt.service
  17ms thermald.service
  16ms com.system76.SystemUpdater.service
  16ms systemd-tmpfiles-clean.service
  13ms tor.service
  13ms plymouth-read-write.service
  10ms console-setup.service
  10ms finalrd.service
   8ms systemd-tmpfiles-setup-dev.service
   8ms proc-sys-fs-binfmt_misc.mount
   6ms openvpn.service
   5ms systemd-update-utmp.service
   5ms systemd-user-sessions.service
   4ms user-runtime-dir@1000.service
   4ms plymouth-quit-wait.service
   4ms systemd-update-utmp-runlevel.service
   3ms dev-mapper-cryptswap.swap
   3ms ifupdown-pre.service
   2ms ufw.service
   2ms boot-efi.mount
   2ms rtkit-daemon.service
   2ms run-qemu.mount
   1ms setvtrgb.service
  29us blk-availability.service

Da stehen ja nun diverse Dienste mit ihren Ausführungszeiten beim Boot.
Für dieses sudo apt update kämen m.M.n. von den obigen Diensten folgende in Frage:

com.system76.SystemUpdater.service

Der Dienst ist für das Aktualisieren der Firmware von System76-Hardware gedacht.
Da ich ein normales AM4-System besitze, sollte eine Deaktivierung unproblematisch sein.

Der obige Dienst ist es wohl doch nicht, da er nur 1x pro Monat ausgeführt wird.
Es scheint der pop-upgrade.service zu sein, welcher ähnlich wie bei EndeavourOS agiert (dort ist er aber nicht automatisiert, sondern befindet sich in meinem Update-Script für EnOS).

Der Dienst wird lt. s76-Programmierer bei jedem Bootvorgang ausgeführt, um sich selbst immer aktuell zu halten.
Ein Deaktivieren kann Probleme bei Updates verursachen ... ... muss ich wohl mit leben.
Quelle: https://github.com/pop-os/system-updater/issues/38

Wenn ich wüsste, wie man diesen Dienst als Befehl ausführt, dann könnte ich ihn in mein Update-Script für Pop!_OS aufnehmen.

 

[0x8100]

Wenn ich dann mein Update-Script zeitnah laufen lasse,

wozu eigentlich? kann das system auch alleine machen:

 

[Tanzmusikus]

wozu eigentlich? kann das system auch alleine machen:

Möchte ich aber nicht.
Ich schaue mir lieber in der Konsole an, was aktualisiert wird und ggf. welche Fehler dabei auftreten.

Da ich mehrere PPAs und zusätzlich noch Flatpaks installiert habe sowie einige Aufräumbefehle nicht durch die Automatik abgedeckt werden, sehe ich darin keine ausreichende Alternative.

 

[0x8100]

du kannst jetzt natürlich versuchen gegen das system zu arbeiten oder du erweiterst dein script einfach so dass es checkt, ob die lock-datei da ist und erst loslegt, wenn sie nicht (mehr) existiert.

 

[Tanzmusikus]

oder du erweiterst dein script einfach so dass es checkt, ob die lock-datei da ist und erst loslegt, wenn sie nicht (mehr) existiert.

Cool, wie geht das?

"if then else"-Schleife im Bash-Script wird wohl nicht ganz ausreichen. Oder doch?

https://linuxhandbook.com/if-else-bash/
https://linuxize.com/post/bash-if-else-statement/
https://www.howtogeek.com/884039/how-to-use-bash-if-statements-with-examples/

 

[andy_m4]

"if -> else"-Schleife

Du musst eine while-Schleife und eine if-else-Verzweigung kombinieren:

#!/bin/bash

lockfilename = "/var/lib/apt/lists/lock"

while true; do # Endlosschleife
    # Überprüfen, ob die Lock-Datei vorhanden ist
    if [ -e "$lockfilename" ]; then
        # Lock-Datei ist noch vorhanden
        sleep 5  # 5 Sekunden warten und dann gucken wir noch mal nach
                 # der Lock-Datei
    else
        # Lock-Datei ist endlich weg
        # ################################
        # hier kommt dein Kram rein, den Du machen willst
        # ################################
        break  # while-Schleife verlassen
    fi
done

 

[Malaclypse17]

Würde es eher mit while versuchen: https://www.cyberciti.biz/faq/bash-while-loop/
Edit: Vorposter war schneller

 

[Tanzmusikus]

@andy_m4
Wow ... Danke!! Das sieht ja schon fast fertig aus. 😊 👍

 

[0x8100]

prüfen auf vorhandensein reicht nicht, man muss schauen, ob ein lock auf der datei ist:

#!/bin/bash

while $(lslocks | grep -q '/var/lib/apt/lists/lock'); do
  echo "wait..."
  sleep 1
done

apt update && apt upgrade

 

[andy_m4]

Vorposter war schneller

Und das trotz des sleep-Commands. ;-)

 

[Tanzmusikus]

5 Sekunden warten und dann gucken wir noch mal nach der Lock-Datei

Haha ... das mache ich sonst immer (natürlich ohne nach der Lock-Datei zu schauen). Wird wohl bald "adé" sein ...

 

[andy_m4]

prüfen auf vorhandensein reicht nicht, man muss schauen, ob ein lock auf der datei ist

Gut zu wissen. Aber wäre es dann nicht eleganter flock zu nehmen, statt auf einer Liste "herumzugreppen" ?

 

[Tanzmusikus]

flock

Scheint interessant zu sein. Könnte Code sparen.
Aber heute bekomme ich das nicht mehr zusammen.


Vielleicht das hier könnte evtl. passen(?)

shell> flock -x local-lock-file echo 'a b c'
Grab the exclusive lock "local-lock-file" before running echo 
with 'a b c'.

 

[0x8100]

Gut zu wissen. Aber wäre es dann nicht eleganter flock zu nehmen, statt auf einer Liste "herumzugreppen" ?

guter einwand. dann sollte sich das ganze auf das reduzieren:

flock /var/lib/apt/lists/lock -c "apt update && apt upgrade"

 

[Tanzmusikus]

Super!
Es funktioniert mit:

sudo flock /var/lib/apt/lists/lock -c "apt update"
etc. pp. ...

Also nochmals vielen Dank ab Euch alle !!!

 

[andy_m4]

guter einwand

Eher Hinweis als Einwand. Der entscheidende Einwand kam von Dir mit dem Lock.

 

[netzgestaltung]

Wenn ich wüsste, wie man diesen Dienst als Befehl ausführt, dann könnte ich ihn in mein Update-Script für Pop!_OS aufnehmen.

sollte das nicht mit systemctl start com.system76.SystemUpdater.service gehen?
ich würd auch eher nachstarten als mit while aufs ende warten.

 

[Tanzmusikus]

Wahrscheinlich ja.

---

Sicherer für das System wäre es allerdings, den s76-SystemUpdater-Dienst immer laufen zu lassen (siehe #1 unten).
Da warte ich lieber ein paar Sekunden bis der Prozess wirklich fertig ist nach dem Booten.

Was mich nervt ist die Ungewissheit, wann der Dienst fertig ist & ich mehrmals umsonst probiere.
Da kommt dann flock ins Spiel.

 

[Tanzmusikus]

Leider funktioniert der Befehl sudo flock /var/lib/apt/lists/lock -c "apt update" nicht wie gewünscht.

Paketlisten werden gelesen… Fertig
E: Sperre /var/lib/apt/lists/lock konnte nicht erlangt werden. Sie wird von Prozess 1234 (apt-get) gehalten.
N: Beachten Sie, dass das Entfernen der Sperrdatei keine Lösung ist und Ihr System beschädigen kann.
E: Das Verzeichnis /var/lib/apt/lists/ kann nicht gesperrt werden.
Paketlisten werden gelesen… Fertig

Es ist genauso wie vorher bzw. ohne diesem "flock"-Befehl. 😕