• Café
  • Automatisiertes Paketupgrade

Dirk ob systemd in units Bash-Syntax mag

nein, das mag systemd nicht, das müsste in einer eigenen shell laufen, zb:
ExecStart =/usr/bin/<shell> [ $(pacman -Qu | wc -l) -gt 0 ] && notify-send -a "Update verfügbar" "Es stehen $(pacman -Qu | wc -l) updates zur Installation bereit!"

Dirk Und den Timer dann entsprechend im root-Kontext aktivieren, damit wird täglich die Pacman-Datenbank aktualisiert und Fehler auch entsprechend geloggt.

Vor der Aktualisierung der Paketdatenbank ohne nachfolgendes Systemupdate kann ich nur warnen. Wenn nämlich der Benutzer danach ein Paket (und möglicherweise noch weitere Abhängigkeiten darauf) installiert und dieses Paket seit dem letzten Systemupdate anbieterseitig aktualisiert wurde, passen die Dateien nicht mehr zum restlichen System und man bekommt den typischen Zustand eines teilaktualisierten Systems, mit den bekannten Risiken.

ExecStart = [ $(pacman -Qu | wc -l) -gt 0 ] && notify-send -a "Update verfügbar" "Es stehen $(pacman -Qu | wc -l) updates zur Installation bereit!"

Dafür gibt es extra den Skript checkupdates aus dem pacman-contrib-Paket, das aus gutem Grund eben nicht die Paketdatenbank aktualisiert, sondern statt dessen unter /tmp Kopien der Master- und lokalen Datenbank abstellt und mit diesen den Vergleich auf aktualisierte Pakete durchführt. Das kann insbesondere auch von jedem Benutzer und nicht nur von root durchgeführt werden.
Da das Skript mit einem abfragbaren Status verlassen wird (2 No updates are available) erübrigt sich auch die Umleitung nach wc um die ausgegebenen Zeilen zu zählen.

  • Dirk hat auf diesen Beitrag geantwortet.
  • Dirk gefällt das.

    Martin-MS Ich gehe natürlich vom Idealfall aus, dass der Anwender sofort nach der ersten Benachrichtigung ein Systemupdate fährt, und natürlich auch davon, dass der Anwender immer erst ein Systemupdate macht, bevor ein Paket explizit installiert wird. 🙂

    Das checkupdate-Script ist tatsächlich besser als mein müde zusammengekloppter Einzeiler 👍 Einen wie beschrieben laufenden Updatebenachrichtiger sollte man daher natürlich besser um dieses Script herum bauen, da schenkt man sich dann auch gleich die Zweiteilung.

    tuxnix Leider geht seit qt6 die Darstellung als Link nicht mehr, sonst hätte ich in der Notiz gleich zum Wiki Artikel verlinkt.

    Versuche folgendes:
    notify-send "Pacman database locked" "<a href='https://wiki.archlinux.org/title/Pacman#%22Failed_to_init_transaction_(unable_to_lock_database)%22_error'>How to solve the problem</a>"

    • tuxnix hat auf diesen Beitrag geantwortet.

      Martin-MS
      Danke für den Tipp, aber genau das hatte ich schon probiert.
      Leider wird das <a href="xyz">Link</a> von notify-send nur als html code dargestellt und nicht als anklickbarer Link
      Und das war letztes Jahr noch anders.
      Klappt das denn bei dir?

      Habe einen Fehler in meinem reminder skript entdeckt.
      Es muss [ $((86460%3600)) -lt "60" ] heißen und nicht [ $((86460%3600)) -eq "0" ], weil der timer nur jede Minute einmal in Aktion tritt, also ein mal in einem 60 sec intervall.
      Ich verbesser das oben im Post wo das script steht, die Bedingung für die db.lck Sache ist dann auch gleich mit enthalten.

      • Martin-MS hat auf diesen Beitrag geantwortet.

        GerBra Das wäre ja noch ein einfaches Ding. Wenn das Ziel wirklich ein "automatisches pacman für Alle" sein sollte, dann müßten IMHO wesentlich robustere Prüfungen erfolgen.
        Hat man das upgrade durchgeführt, wird man einen Tag in Ruhe gelassen.

        Nein, ach du jeh , ein - automatisches pacman für alle - soll es gerade nicht werden.
        Es soll lediglich informieren und dazu animieren ein pacman -Syu selbst durchzuführen und nur dann, wenn dies trotz zunehmend aufdringlich werdender Aufforderungen immer noch nicht erfolgt, erst dann soll das upgrade auch mal automatisch erfolgen.

        Mir geht es um die Fälle menschlicher Natur, denen ich Arch Linux aufgespielt habe, die aber ohne eine Erinnerung keine upgrades durchführen. Die möchte ich da sanft heranführen es von ganz allein zu tun.
        Neulich hab ich einen Freund besucht, Arch Linux lief immer noch munter auf dem Rechner, aber 2 Jahre lang war kein einziges update gemacht. Das ist der Störfall den ich vermeiden möchte. Wenn so etwas passiert, dann möchte ich gar niemanden mehr Linux aufspielen.

        Zu deinen Unterpunkten:

        • Stromausfall, kann ich nicht beeinflussen. Dazu aber weiter unten mehr. Gegen "Rechner während des upgrades runter fahren" gibt es jetzt die Warnung wenn das upgrade im Hintergrund läuft.
        • Kernelupdates müssen beim manuellen pacman -Syu auch klappen.
        • Kram aus dem AUR müssen die Leute selbst installieren und selbst warten können.
          Je nachdem was dort installiert wird, kann es auch keinen automatischen Schutz davor geben.
        • Bei Nachfragen von pacman während einer interaktiven Sitzung (z.B. nach Programmalternativen)
          Die default Auswahl genügt. Der User der nicht selbst seine Updates fährt, muss von der Stange nehmen.
        • Manuelles Eingreifen erforderlich Dazu muss ich mir erst noch Gedanken machen, wie ich die neueste Archnews mit notiy-send auf den Bildschirm zaubere.
          Eigentlich müsste pacman so gestaltet werden, dass es selbstständig die Liste der installierten Pakete durchsucht und falls ein manueller Eingriff notwendig wird, die News anzeigt und falls notwenig dann sogar das upgrade mit entsprechender Fehlermedung abbricht. Nur mal so eine Idee dazu.
          Insgesamt ist bei pacman ja schon viel passiert in der Richtung. Die j/n Kasskaden von früher gibt es nicht mehr. Mit Bestätigung der Vorauswahl läuft es eigentlich jetzt immer durch. Wahrscheinlich weil es jetzt auch so Sachen wie discover und software gibt, die das upgrade automatisch fahren.
          Ja, ein Systemupgrade erfolgreich beendet fehlt im pacman.log
        • Snapshots - Ich finde snapshots unnötig. Bisher bin ich immer mit einem paket-downgrade ausgekommen falls mal was hängt. Ohnehin benötige ich eine Sicherung auf einem getrennten Medium.
          Um beides zu gewährleisten wäre eigentlich ein A/B boot system auf zwei getrennten Datenträgern ideal. Auf dem jeweils inaktiven findet das upgrade und die Datensicherung statt.
          Dann bliebe das laufende System intakt, falls mal etwas beim upgrade schief läuft und der User in seiner Sitzung ungestört.
        • War das jetzt nicht Windows, das gerade die halbe Welt mit einem automatischen System lahm gelegt hat? Nein, so etwas brauchen wir nicht. 😉

        Jeden Ansatz eines Automaten für Updates würde ich an den Zeitpunkt des Herunterfahrens koppeln. Kein eingeloggter/arbeitender User = ein kleines Problem weniger.

        Ist aber auch nervig. Und wenn dann mal etwas schief läuft, merkt der User es erst, wenn er den Rechner dringend braucht. Eine Freundin von mir schaltet auch immer den Strom an der Steckerleiste aus. Es gibt wirklich nichts was nicht auch vom user sabotiert werden könnte.

        Danke dir für das Bainstorming und die vielen Punkte, die es dabei zu bedenken gilt.
        Es ist gut das alles mal gründlich durchzugehen.
        Aber wie schon oben bemerkt, das skript dient in erster Linie der Pädagogik und soll dazu animieren, ein manuelles upgrade durchzuführen. Zum automatischen upgrade kommt es erst wenn das alles nicht hilft und dann natürlich auf Verantwortung des users.
        "Wer nicht hören will, muss...."

        Lohegrin ist ein sagenhafter Superheld aus dem schwülstigen Wagneruniversum.
        Natürlich klappt es mit dem NIE bei ihm auch nicht so ganz wie vorgesehen.
        Vielleicht hätte ich auch "Sag niemals NIE" von 007 rezitieren sollen. 😉

        Ich bekomme jetzt (1 Tag nachdem ich das skript aktiviert habe) sündlich eine Meldung:
        "29 upgrades available. Run: # pacman -Syu"

        Morgen wechselt die Farbe der Nachricht von grün auf gelb und der Takt auf halbstündiges Nerven.

        Zusätzlich werden die mirrors aktuell gehalten und das paket cache geleehrt. Was ja auch schon recht beliebte Störfälle vermeiden hilft. Und zusätzlich wird auch das manuelle upgrade beschleunigt weil die meisten pakete schon vorab herunter geladen wurden.

        • GerBra hat auf diesen Beitrag geantwortet.

          tuxnix Es ist gut das alles mal gründlich durchzugehen.
          Aber wie schon oben bemerkt, das skript dient in erster Linie der Pädagogik und soll dazu animieren, ein manuelles upgrade durchzuführen. Zum automatischen upgrade kommt es erst wenn das alles nicht hilft und dann natürlich auf Verantwortung des users.

          Gut, das sehe ich ein. Ich handhabe das bei den wenigen "Fällen" die ich habe so, daß dann eben kein Update erfolgt, außer ich weiß definitiv von sicherheitsrelevanten Vorgängen. Irgendwann erledige ich dann halt mal ein "großes" Update. Ein selbständiges Update halte ich da für aussichtslos, ein Automatismus scheidet da aus, v.a. da ich dann nicht mehr den Zeitpunkt bestimmen kann wann ggf. um "Hilfe" gerufen wird.

          Evtl. noch mal ein paar praktische Hinweise rund um pacman für dein Vorhaben, die ich mit der Zeit teils nutze:

          • Die pacman-Hooks sind sehr mächtig, v.a. interessant die PreTransaction-Hooks.
            V.a. deshalb, da zu dem Zeitpunkt noch nichts am System verändert wurde (außer DB-Sync)
            Ich war mal dran etwas zu implementieren was die zu updatenden Pakete nach einer Auswahl hin durchsucht und je nach Kriterium den Update-Prozeß unterbrechen kann //Edit: bzw. genauer: erst gar nicht startet). Das konnten z.B. Kernel-Updates sein, oder - meine Intention damals - für bestimmte Pakete Major/Epoch-Upgrades oder Minor=0 Upgrades("= ggf. "Beta" einer neuen Major-Version). In diesen Fällen sollte ein pacman -Syu sich eben mit entsprechendem Hinweis beenden, um ggf. noch bestimmte Maßnahmen vorher durchführen zu können. Z.B. Obacht: es wird eine neue Gnome/KDE-Version installiert. Also dasselbe, was man per Lesen/Überfliegen der Paketupdate-Liste nach einiger Zeit intuitiv draufhat.
            Ich habe das außer im Ansatz leider nicht mehr verfolgt.

          • Zur pacman-Log und dem Feststellen des Status eines Updates
            Evtl. wäre das mal ein Feature-Request wert, zum Vorgang eines Updates eine Transaktions-Nummer/Status zu implementieren, v.a. da libalpm das AFAIK von Haus aus kann/tut.
            Meine Idee war/ist einen "Wrapper" rund um "pacman -Syu" zu legen, der per /usr/bin/logger eine generierte Transaktions-Nummer/Text hinterlegt (z.B. PID+Zufallszahl) und bei erfolgreichem Update eine dazugehörige "Beendet" Meldung, ebenfalls mit obiger Nummer und Status-Text. So wäre im pacman.log oder per paclog ermittelbar: Wann wurde das letzte erfolgreiche Update durchgeführt - Transaktions-Nummern von Start/Stop müssen aufeinanderfolgen und der "Status" muß OK sein.

          Snapshots: Ich finde das die beste Methode, um unproblematisch einen bestimmten Zustand zu sichern und wiederherzustellen. Deswegen schaue ich immer, entweder Dateisysteme oder Volume-Manager zu verwenden, die sowas anbieten. V.a. aus dem Grund, daß ich dadurch Zeitpunkt(oder Ort/Art) bestimmen kann, wann ich bei einem etwaigen Problem mich mit "Frickelei am Lebenden" rumschlagen will/muß.

          tuxnix Um beides zu gewährleisten wäre eigentlich ein A/B boot system auf zwei getrennten Datenträgern ideal

          Oder man führt das Upgrade(oder die Aktion) im "Snapshot" durch, läßt also den aktuellen Zustand unverändert. Erst auf "Zuruf" würde dann der neue Zustand aktiv werden.

          Martin-MS
          Betr. Hyperlink mit notfy-send
          Danke für den sreenshot. (Nein am Syntax hat es nicht gelegen der war nur in meinem post falsch)
          Woran der Fehler liegt habe ich noch nicht ganz herausfinden können.
          Ich nutze sway. Motiviert durch deinen screenshot habe ich es mal mit plasma versucht.
          Dort funktioniert es einwandfrei und auf Anhieb.
          Auf sway habe ich den notification daemon von mako auf swaync und jetzt auf dunst geändert.
          Dunst zeigt den Hyperlink in der Meldung schon mal richtig an, leitet aber die url auch nicht weiter.
          Soweit bin ich dann schon mal.
          Ich hätte da noch die Idee, dass sway auf den notification daemon von plasma zugreift.
          Wie konfiguriere ich das?

          6 Tage später

          Nachdem ich heraus gefunden habe wie man unter root Mitteilungen an den user rauschicken kann, war statt der zwei Skripte zuvor, nur noch eines von Nöten. Ich habe die Funktionen der beiden bisherigen Skripte nun zusammengefasst und lasse das resultierende Skript jetzt stündlich mittels Systmd-Timer ausführen.
          Es erinnert, falls neue Paketversionen zum Upgrade verfügbar sind den User ein # pacman -Syu durchzuführen, macht dies aber auch automatisch, falls x Tagen nach dem letzten Paketupgrade verstrichen sind. Gibt es beim Upgrade Fehler, wird dies dem User angezeigt. Auch eine Blockierung durch db.lck wird detektiert und gemeldet. 1. Minute vor einem automatischen Update wird aufgefordert aktuelle Daten abzuspeichern, dann eine Aufforderung den Rechner weiter laufen zu lassen und schließlich eine Erfolgsmeldung. Je nachdem ob auch der kernel dabei erneuert wurde wird ein reboot oder ein Neustarten der Anwendungen empfohlen.
          Nebenbei wird der Paket-Cache gewartet, die package-mirrors aktuell gehalten und eine Datei mit der Auflistung aller installierten Pakete geführt.

          //Edit 3.8.2024 : Ich habe den vorläufigen Code an dieser Stelle gelöscht, weil das irritieren kann und zu Fehlern führt s.unten. Die Diskussion bleibt auch ohne den Code klar verständlich, weil die jeweiligen Argumente explizit den jeweiligen Syntax aufführen. Ganz unten steht jetzt das aktuelle Skript incl. Installationsanleitung.

          • brikler hat auf diesen Beitrag geantwortet.
          • Dirk gefällt das.

            tuxnix stündlich mittels Systmd-Timer ausführen.

            stündlich? das ist aber schon ganz schön oft…

            • tuxnix hat auf diesen Beitrag geantwortet.

              brikler stündlich? das ist aber schon ganz schön oft…

              Ja, da hast du recht. Alle vier Stunden bzw. 1x täglich würden durchaus genügen um an ein Upgrade zu erinnern. Momentan teste ich noch und fahre kurze Intervalle.

              Hallo
              Mein Versuch Dein Auto Upgrade Script auf einen aktuellen Endeavour System einzurichten geht leider nicht.
              Wo liegt mein Fehler. Als Timer und Service habe ich diese benutzt.
              Der upgrade Timer

              [Unit]
              Description=upgrade.timer
              
              [Timer]
              OnStartupSec=5min
              OnCalendar=hourly
              Persistent=true
              
              [Install]
              WantedBy=basic.target
              
              Der upgrade Service
              [Unit]
              Description=upgrade.service
              After=network-online.target
              
              [Service]
              ExecStart=/usr/local/bin/upgrade
              
              [Install]
              WantedBy=basic.target

              Meine weiteren Schritte, den Ordner ~/.config/systemd/ gibt es nicht.

              cd .config/
              mkdir -p systemd/user
              mv upgrade.service .config/systemd/user/upgrade.service
              mv upgrade.timer .config/systemd/user/upgrade.timer
              sudo mv upgrade /usr/local/bin/upgrade
              sudo chmod u+x /usr/local/bin/upgrade
              systemctl --user enable --now upgrade.timer

              Hier die aktuellen Abfragen und Logs. Der user ist [ralf@rk-7072 ~]$

              ls -la /usr/local/bin/
              -rwxr--r--  1 ralf ralf 3295 31. Jul 21:40 upgrade
              #
              ls -la .config/systemd/user/
              drwxr-xr-x 2 ralf ralf 4096  2. Aug 19:55 basic.target.wants
              -rw-r--r-- 1 ralf ralf  140  2. Aug 17:28 upgrade.service
              -rw-r--r-- 1 ralf ralf  127  2. Aug 17:29 upgrade.timer
              #
              systemctl list-timers --user
              NEXT                          LEFT LAST                            PASSED UNIT          ACTIVATES
              Fri 2024-08-02 21:00:00 CEST 14min Fri 2024-08-02 20:00:19 CEST 39min ago upgrade.timer upgrade.service
              1 timers listed.
              Pass --all to see loaded but inactive timers, too.
              #
              systemctl --user status upgrade.service
              ○ upgrade.service
                   Loaded: loaded (/home/ralf/.config/systemd/user/upgrade.service; disabled; preset: enabled)
                   Active: inactive (dead) since Fri 2024-08-02 20:01:25 CEST; 46min ago
                 Duration: 1min 5.433s
               Invocation: 11eeec17ec4c4292ae7d752a633be159
              TriggeredBy: ● upgrade.timer
                  Process: 1990 ExecStart=/usr/local/bin/upgrade (code=exited, status=0/SUCCESS)
                 Main PID: 1990 (code=exited, status=0/SUCCESS)
                 Mem peak: 38.1M
                      CPU: 800ms
              
              Aug 02 20:01:22 rk-7072 upgrade[2129]: ==> Escalating privileges using sudo
              Aug 02 20:01:22 rk-7072 sudo[2130]: pam_systemd_home(sudo:auth): New sd-bus connection (system-bus-pam-systemd-home>
              Aug 02 20:01:22 rk-7072 sudo[2130]: pam_unix(sudo:auth): conversation failed
              Aug 02 20:01:22 rk-7072 sudo[2130]: pam_unix(sudo:auth): auth could not identify password for [ralf]
              Aug 02 20:01:25 rk-7072 upgrade[2129]: ==> ERROR: Failed to escalate
              Aug 02 20:01:25 rk-7072 upgrade[2133]: /usr/local/bin/upgrade: Zeile 70: /var/pkglist.txt: Keine Berechtigung
              Aug 02 20:01:25 rk-7072 sudo[2144]: pam_systemd_home(sudo:account): New sd-bus connection (system-bus-pam-systemd-h>
              Aug 02 20:01:25 rk-7072 sudo[2144]:     ralf : PWD=/home/ralf ; USER=ralf ; ENV=DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS>
              Aug 02 20:01:25 rk-7072 sudo[2144]: pam_unix(sudo:session): session opened for user ralf(uid=1000) by ralf(uid=1000)
              Aug 02 20:01:25 rk-7072 sudo[2144]: pam_unix(sudo:session): session closed for user ralf
              #
              type upgrade
              upgrade ist /usr/local/bin/upgrade
              #
              upgrade
              Fehler: Sie benötigen Root-Rechte, um diese Operation auszuführen.
              error: Permission denied
              #
              journalctl -f
              Aug 02 20:45:17 rk-7072 systemd[633]: Started Kate - Erweiterter Texteditor.
              Aug 02 20:48:18 rk-7072 plasmashell[747]: kf.plasma.quick: Exposed with no visual parent. Window positioning broken.
              Aug 02 20:54:00 rk-7072 sudo[2781]: pam_systemd_home(sudo:account): New sd-bus connection (system-bus-pam-systemd-home-2781) opened.
              Aug 02 20:54:00 rk-7072 sudo[2781]:     ralf : TTY=pts/0 ; PWD=/home/ralf ; USER=ralf ; ENV=DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus ; COMMAND=/usr/bin/notify-send 'Upgrade starts in 1 min:' '<span color=\'#ffff00\' font=\'16px\'><i><b>Save your documents!</b></i></span>' -t 60000 -u normal -p
              Aug 02 20:54:00 rk-7072 sudo[2781]: pam_unix(sudo:session): session opened for user ralf(uid=1000) by ralf(uid=1000)
              Aug 02 20:54:00 rk-7072 sudo[2781]: pam_unix(sudo:session): session closed for user ralf
              Aug 02 21:00:19 rk-7072 systemd[633]: Started upgrade.service.
              Aug 02 21:00:20 rk-7072 upgrade[2935]: Fehler: Sie benötigen Root-Rechte, um diese Operation auszuführen.
              Aug 02 21:00:20 rk-7072 upgrade[2936]: error: Permission denied
              Aug 02 21:00:20 rk-7072 sudo[2937]: pam_systemd_home(sudo:account): New sd-bus connection (system-bus-pam-systemd-home-2937) opened.
              Aug 02 21:00:20 rk-7072 sudo[2937]:     ralf : PWD=/home/ralf ; USER=ralf ; ENV=DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus ; COMMAND=/usr/bin/notify-send 'Upgrade starts in 1 min:' '<span color=\'#ffff00\' font=\'16px\'><i><b>Save your documents!</b></i></span>' -t 60000 -u normal -p
              Aug 02 21:00:20 rk-7072 sudo[2937]: pam_unix(sudo:session): session opened for user ralf(uid=1000) by ralf(uid=1000)
              Aug 02 21:00:20 rk-7072 sudo[2937]: pam_unix(sudo:session): session closed for user ralf
              Aug 02 21:01:20 rk-7072 sudo[2969]: pam_systemd_home(sudo:account): New sd-bus connection (system-bus-pam-systemd-home-2969) opened.
              Aug 02 21:01:20 rk-7072 sudo[2969]:     ralf : PWD=/home/ralf ; USER=ralf ; ENV=DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus ; COMMAND=/usr/bin/notify-send 'Linux is upgrading:' 'Keep system running!' -t 0 -u critical -r 6 -p
              Aug 02 21:01:20 rk-7072 sudo[2969]: pam_unix(sudo:session): session opened for user ralf(uid=1000) by ralf(uid=1000)
              Aug 02 21:01:20 rk-7072 plasmashell[747]: org.kde.plasma.notificationmanager: Trying to replace notification with id 6 which doesn't exist, creating a new one. This is an application bug!
              Aug 02 21:01:20 rk-7072 sudo[2969]: pam_unix(sudo:session): session closed for user ralf
              Aug 02 21:01:20 rk-7072 upgrade[2990]: Fehler: Sie benötigen Root-Rechte, um diese Operation auszuführen.
              Aug 02 21:01:20 rk-7072 sudo[3005]: pam_systemd_home(sudo:account): New sd-bus connection (system-bus-pam-systemd-home-3005) opened.
              Aug 02 21:01:20 rk-7072 sudo[3005]:     ralf : PWD=/home/ralf ; USER=ralf ; ENV=DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus ; COMMAND=/usr/bin/notify-send 'Upgrade done:' '<span color=\'#89ff89\' font=\'18px\'><i><b>Restart applikation</b></i></span>' -t 0 -u low -r 6
              Aug 02 21:01:20 rk-7072 sudo[3005]: pam_unix(sudo:session): session opened for user ralf(uid=1000) by ralf(uid=1000)
              Aug 02 21:01:20 rk-7072 sudo[3005]: pam_unix(sudo:session): session closed for user ralf
              Aug 02 21:01:20 rk-7072 upgrade[3026]: ==> Escalating privileges using sudo
              Aug 02 21:01:20 rk-7072 sudo[3027]: pam_systemd_home(sudo:auth): New sd-bus connection (system-bus-pam-systemd-home-3027) opened.
              Aug 02 21:01:20 rk-7072 sudo[3027]: pam_unix(sudo:auth): conversation failed
              Aug 02 21:01:20 rk-7072 sudo[3027]: pam_unix(sudo:auth): auth could not identify password for [ralf]
              Aug 02 21:01:22 rk-7072 upgrade[3026]: ==> ERROR: Failed to escalate
              Aug 02 21:01:22 rk-7072 upgrade[3048]: ==> Escalating privileges using sudo
              Aug 02 21:01:22 rk-7072 sudo[3049]: pam_systemd_home(sudo:auth): New sd-bus connection (system-bus-pam-systemd-home-3049) opened.
              Aug 02 21:01:22 rk-7072 sudo[3049]: pam_unix(sudo:auth): conversation failed
              Aug 02 21:01:22 rk-7072 sudo[3049]: pam_unix(sudo:auth): auth could not identify password for [ralf]
              Aug 02 21:01:24 rk-7072 upgrade[3048]: ==> ERROR: Failed to escalate
              Aug 02 21:01:24 rk-7072 upgrade[3052]: /usr/local/bin/upgrade: Zeile 70: /var/pkglist.txt: Keine Berechtigung
              Aug 02 21:01:24 rk-7072 sudo[3063]: pam_systemd_home(sudo:account): New sd-bus connection (system-bus-pam-systemd-home-3063) opened.
              Aug 02 21:01:24 rk-7072 sudo[3063]:     ralf : PWD=/home/ralf ; USER=ralf ; ENV=DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus ; COMMAND=/usr/bin/notify-send 'Error: pacman -Qqe' 'To analyse run command\\non terminal' -t 0 -u critical
              Aug 02 21:01:24 rk-7072 sudo[3063]: pam_unix(sudo:session): session opened for user ralf(uid=1000) by ralf(uid=1000)
              Aug 02 21:01:24 rk-7072 sudo[3063]: pam_unix(sudo:session): session closed for user ralf
              • tuxnix hat auf diesen Beitrag geantwortet.

                @md_39118 Bitte achte auf die richtige Formatierung, ich war mal so frei und habs korrigiert. Das mit dem Code ist leider nicht ganz intuitiv, aber hier steht es noch mal ausführlich beschrieben:

                https://wiki.archlinux.de/title/Foren-FAQs#Wie_bekommt_man_Code_richtig_formatiert_ins_Forum?

                Beachte bitte, dass Endeavour OS nicht Arch Linux ist, und für Arch entwickelte Dinge nicht automatisch auch unter Endeavour OS laufen.

                  Dirk
                  Danke für die Änderung der Formatierung.
                  Im Moment habe ich nur das Endeavour System zum Testen, wobei das doch recht nahe am Original ist.

                  md_39118
                  Du hast den Timer/Service als user laufen. Du benötigst ihn aber als root! Weil ich noch Änderungen bei der Namensgebung und den Dateipfaden gemacht habe, schreibe ich dir hier am Besten noch mal alles komplett auf:

                  ( Es müsste auf den meisten GUIs auf Anhieb eine Nachricht auf den Bildschirm anzeigen. Ich hab es aber noch nicht überall getestet. Ist kein Paketupgrade vorhanden dann gibt es aber auch keine Meldung. )

                  Der Timer ist jetzt auf vierstündige Erinnerungen eingestellt.

                  Viel Spaß damit und melde mal zurück auf welcher GUI du es laufen hast.

                  //Edit 18.8.2024 : Ich habe den vorläufigen Code an dieser Stelle gelöscht, weil das irritieren kann und zu Fehlern führt s.unten. Die Diskussion bleibt auch ohne den Code klar verständlich, weil die jeweiligen Argumente explizit den jeweiligen Syntax aufführen. Ganz unten steht jetzt das aktuelle Skript incl. Installationsanleitung.

                  • md_39118 hat auf diesen Beitrag geantwortet.

                    tuxnix
                    Hallo
                    Danke für Deine Mühe.
                    Auf dem Pc läuft KDE Plasma 6
                    Deine neue Version kann ich erst ab 10.8 Testen, bin ab morgen mit den Enkeln wandern.
                    Danach werde ich berichten.

                    10 Tage später

                    Hallo
                    Ein kurzer Status Bericht, für mich sieht es jetzt gut aus.
                    Das Auto Update wird dann wohl am 15.8.24 starten.
                    Hier noch eine Zusammenfassung der journalctl Daten.

                    Start am 13.08.2024 um 14:13
                    
                    Die 1. Meldung, wenn diese nicht gelöscht wird, wird die Anzeige der Zeit(min) weiter aktualisiert zb. von "Vor 1 min" bis die Startzeit hier 14:13 angezeigt wird.
                    notify-send
                    6 upgrades, run: pacman -Syu
                    
                    systemctl list-timers
                    NEXT                             LEFT LAST                           PASSED UNIT                             ACTIVA>
                    Tue 2024-08-13 14:21:25 CEST       6s Tue 2024-08-13 14:11:36 CEST 9min ago ureminder.timer                  uremin>
                    
                    Die 2. Meldung, wenn diese nicht gelöscht wird, wird die Anzeige der Zeit(min) weiter aktualisiert zb. von "Vor 1 min" bis die Startzeit hier 14:21 angezeigt wird.
                    notify-send
                    6 upgrades, run: pacman -Syu
                    
                    Bis jetzt erfolgte noch kein Auto Update
                    date
                    Di 13. Aug 20:05:51 CEST 2024
                    uname -a
                    Linux rk-7072 6.10.3-arch1-2 #1 SMP PREEMPT_DYNAMIC Tue, 06 Aug 2024 07:21:19 +0000 x86_64 GNU/Linux
                    
                    
                    journalctl | grep ureminder
                    Aug 11 17:58:25 rk-7072 dolphin[1868]: kf.kio.workers.file: copy() QUrl("file:///run/media/ralf/D7DC-D7BD/neu/ureminder") to QUrl("file:///home/ralf/neu/ureminder") mode= 420
                    Aug 11 17:58:25 rk-7072 dolphin[1868]: kf.kio.workers.file: copy() QUrl("file:///run/media/ralf/D7DC-D7BD/neu/ureminder.service") to QUrl("file:///home/ralf/neu/ureminder.service") mode= 420
                    Aug 11 17:58:25 rk-7072 dolphin[1868]: kf.kio.workers.file: copy() QUrl("file:///run/media/ralf/D7DC-D7BD/neu/ureminder.timer") to QUrl("file:///home/ralf/neu/ureminder.timer") mode= 420
                    Aug 11 17:58:25 rk-7072 dolphin[1868]: kf.kio.workers.file: copy() QUrl("file:///run/media/ralf/D7DC-D7BD/neu/ureminder.txt") to QUrl("file:///home/ralf/neu/ureminder.txt") mode= 420
                    Aug 11 18:32:18 rk-7072 systemd[1]: Started ureminder.timer.
                    Aug 11 18:32:18 rk-7072 systemd[1]: Started ureminder.service.
                    Aug 11 18:32:19 rk-7072 ureminder[13020]: :: Paketdatenbanken werden synchronisiert …
                    Aug 11 18:32:19 rk-7072 ureminder[13020]:  endeavouros wird heruntergeladen …
                    Aug 11 18:32:19 rk-7072 ureminder[13020]:  core wird heruntergeladen …
                    Aug 11 18:32:19 rk-7072 ureminder[13020]:  extra wird heruntergeladen …
                    Aug 11 18:32:19 rk-7072 ureminder[13020]:  multilib wird heruntergeladen …
                    Aug 11 18:32:19 rk-7072 ureminder[13020]: :: Vollständige Systemaktualisierung wird gestartet …
                    Aug 11 18:32:19 rk-7072 ureminder[13020]:  Es gibt nichts zu tun
                    Aug 11 18:32:20 rk-7072 ureminder[13028]: ==> no candidate packages found for pruning
                    Aug 11 18:32:20 rk-7072 ureminder[13037]: ==> no candidate packages found for pruning
                    Aug 11 18:32:20 rk-7072 systemd[1]: ureminder.service: Deactivated successfully.
                    Aug 11 18:32:20 rk-7072 systemd[1]: ureminder.service: Consumed 1.305s CPU time, 40.5M memory peak.
                    Aug 11 19:34:23 rk-7072 systemd[1]: ureminder.timer: Deactivated successfully.
                    Aug 11 19:34:23 rk-7072 systemd[1]: Stopped ureminder.timer.
                    Aug 11 19:34:54 rk-7072 systemd[1]: Started ureminder.timer.
                    Aug 11 19:45:05 rk-7072 systemd[1]: Started ureminder.service.
                    Aug 11 19:45:06 rk-7072 ureminder[1562]: :: Paketdatenbanken werden synchronisiert …
                    Aug 11 19:46:06 rk-7072 ureminder[1562]:  endeavouros wird heruntergeladen …
                    Aug 11 19:46:06 rk-7072 ureminder[1562]:  core wird heruntergeladen …
                    Aug 11 19:46:06 rk-7072 ureminder[1562]:  extra wird heruntergeladen …
                    Aug 11 19:46:06 rk-7072 ureminder[1562]:  multilib wird heruntergeladen …
                    Aug 11 19:46:06 rk-7072 ureminder[1562]: :: Vollständige Systemaktualisierung wird gestartet …
                    Aug 11 19:46:07 rk-7072 ureminder[1562]: Abhängigkeiten werden aufgelöst …
                    Aug 11 19:46:23 rk-7072 ureminder[1562]: Paket (1)            Alte Version  Neue Version  Netto-Veränderung  Größe des Downloads
                    Aug 11 19:46:23 rk-7072 ureminder[1562]: extra/python-orjson  3.10.6-1      3.10.7-1               0,00 MiB             0,26 MiB
                    Aug 11 19:46:23 rk-7072 ureminder[1562]: Gesamtgröße des Downloads:  0,26 MiB
                    Aug 11 19:46:23 rk-7072 ureminder[1562]: :: Download fortsetzen? [J/n]
                    Aug 11 19:46:23 rk-7072 ureminder[1562]: :: Pakete werden empfangen …
                    Aug 11 19:46:24 rk-7072 ureminder[1562]:  python-orjson-3.10.7-1-x86_64 wird heruntergeladen …
                    Aug 11 19:46:24 rk-7072 ureminder[1562]: Schlüsselbund wird geprüft …
                    Aug 11 19:46:25 rk-7072 ureminder[1562]: Paketintegrität wird geprüft …
                    Aug 11 19:46:25 rk-7072 ureminder[1624]: ==> no candidate packages found for pruning
                    Aug 11 19:46:25 rk-7072 ureminder[1634]: ==> no candidate packages found for pruning
                    Aug 11 19:46:26 rk-7072 systemd[1]: ureminder.service: Deactivated successfully.
                    Aug 11 19:46:26 rk-7072 systemd[1]: ureminder.service: Consumed 2.044s CPU time, 66.3M memory peak.
                    Aug 11 20:53:24 rk-7072 systemd[1]: ureminder.timer: Deactivated successfully.
                    Aug 11 20:53:24 rk-7072 systemd[1]: Stopped ureminder.timer.
                    Aug 13 14:11:36 rk-7072 systemd[1]: Started ureminder.timer.
                    Aug 13 14:11:47 rk-7072 systemd[1]: Started ureminder.service.
                    Aug 13 14:11:49 rk-7072 ureminder[618]: :: Paketdatenbanken werden synchronisiert …
                    Aug 13 14:11:51 rk-7072 ureminder[618]:  endeavouros wird heruntergeladen …
                    Aug 13 14:11:51 rk-7072 ureminder[618]:  core wird heruntergeladen …
                    Aug 13 14:11:51 rk-7072 ureminder[618]:  extra wird heruntergeladen …
                    Aug 13 14:11:51 rk-7072 ureminder[618]:  multilib wird heruntergeladen …
                    Aug 13 14:11:51 rk-7072 ureminder[618]: :: Vollständige Systemaktualisierung wird gestartet …
                    Aug 13 14:11:52 rk-7072 ureminder[618]: Abhängigkeiten werden aufgelöst …
                    Aug 13 14:12:20 rk-7072 ureminder[618]: Paket (6)            Alte Version    Neue Version    Netto-Veränderung  Größe des Downloads
                    Aug 13 14:12:20 rk-7072 ureminder[618]: extra/libei          1.2.1-1         1.3.0-1                 -0,01 MiB             0,09 MiB
                    Aug 13 14:12:20 rk-7072 ureminder[618]: core/linux           6.10.3.arch1-2  6.10.4.arch2-1           0,04 MiB           135,48 MiB
                    Aug 13 14:12:20 rk-7072 ureminder[618]: core/linux-headers   6.10.3.arch1-2  6.10.4.arch2-1           0,00 MiB            25,92 MiB
                    Aug 13 14:12:20 rk-7072 ureminder[618]: extra/mesa           1:24.1.5-1      1:24.1.5-2               0,00 MiB            17,70 MiB
                    Aug 13 14:12:20 rk-7072 ureminder[618]: extra/polkit         124-2           125-1                   -0,01 MiB             0,39 MiB
                    Aug 13 14:12:20 rk-7072 ureminder[618]: extra/python-orjson  3.10.6-1        3.10.7-1                 0,00 MiB
                    Aug 13 14:12:20 rk-7072 ureminder[618]: Gesamtgröße des Downloads:  179,59 MiB
                    Aug 13 14:12:20 rk-7072 ureminder[618]: :: Download fortsetzen? [J/n]
                    Aug 13 14:12:20 rk-7072 ureminder[618]: :: Pakete werden empfangen …
                    Aug 13 14:12:41 rk-7072 ureminder[618]:  linux-6.10.4.arch2-1-x86_64 wird heruntergeladen …
                    Aug 13 14:12:41 rk-7072 ureminder[618]:  linux-headers-6.10.4.arch2-1-x86_64 wird heruntergeladen …
                    Aug 13 14:12:41 rk-7072 ureminder[618]:  mesa-1:24.1.5-2-x86_64 wird heruntergeladen …
                    Aug 13 14:12:41 rk-7072 ureminder[618]:  polkit-125-1-x86_64 wird heruntergeladen …
                    Aug 13 14:12:41 rk-7072 ureminder[618]:  libei-1.3.0-1-x86_64 wird heruntergeladen …
                    Aug 13 14:12:41 rk-7072 ureminder[618]: Schlüsselbund wird geprüft …
                    Aug 13 14:12:43 rk-7072 ureminder[618]: Paketintegrität wird geprüft …
                    Aug 13 14:13:00 rk-7072 ureminder[1278]: ==> no candidate packages found for pruning
                    Aug 13 14:13:00 rk-7072 ureminder[1289]: ==> finished: 3 packages removed (disk space saved: 178.85 MiB)
                    Aug 13 14:13:00 rk-7072 systemd[1]: ureminder.service: Deactivated successfully.
                    Aug 13 14:13:00 rk-7072 systemd[1]: ureminder.service: Consumed 6.509s CPU time, 264.6M memory peak.
                    Aug 13 14:21:39 rk-7072 systemd[1]: Started ureminder.service.
                    Aug 13 14:21:39 rk-7072 ureminder[1468]: :: Paketdatenbanken werden synchronisiert …
                    Aug 13 14:21:40 rk-7072 ureminder[1468]:  endeavouros wird heruntergeladen …
                    Aug 13 14:21:40 rk-7072 ureminder[1468]:  core wird heruntergeladen …
                    Aug 13 14:21:40 rk-7072 ureminder[1468]:  extra wird heruntergeladen …
                    Aug 13 14:21:40 rk-7072 ureminder[1468]:  multilib wird heruntergeladen …
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: :: Vollständige Systemaktualisierung wird gestartet …
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: Abhängigkeiten werden aufgelöst …
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: Paket (6)            Alte Version    Neue Version    Netto-Veränderung
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: extra/libei          1.2.1-1         1.3.0-1                 -0,01 MiB
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: core/linux           6.10.3.arch1-2  6.10.4.arch2-1           0,04 MiB
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: core/linux-headers   6.10.3.arch1-2  6.10.4.arch2-1           0,00 MiB
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: extra/mesa           1:24.1.5-1      1:24.1.5-2               0,00 MiB
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: extra/polkit         124-2           125-1                   -0,01 MiB
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: extra/python-orjson  3.10.6-1        3.10.7-1                 0,00 MiB
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: Gesamtgröße des Downloads:  0,00 MiB
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: :: Download fortsetzen? [J/n]
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: Schlüsselbund wird geprüft …
                    Aug 13 14:21:40 rk-7072 ureminder[1468]: Paketintegrität wird geprüft …
                    Aug 13 14:21:41 rk-7072 ureminder[1555]: ==> no candidate packages found for pruning
                    Aug 13 14:21:41 rk-7072 ureminder[1565]: ==> no candidate packages found for pruning
                    Aug 13 14:21:41 rk-7072 systemd[1]: ureminder.service: Deactivated successfully.
                    Aug 13 14:21:41 rk-7072 systemd[1]: ureminder.service: Consumed 2.598s CPU time, 48.8M memory peak.
                    • tuxnix hat auf diesen Beitrag geantwortet.

                      md_39118

                      Ja, timer/service läuft und löst das skript aus!
                      Ja, wenn Days=4 im Skript gesetzt ist und das letzte Paket von dir am 11.8 erneuert wurde und du zwischendurch kein pacman -Syu tätigst, dann sollte am 15.08. ein auto-ugrade erfolgen. 😉

                      Erscheint denn auch alle 4 h eine Nachricht auf dem Desktop bzw. wenn du ein sudo ureminder ausführst? Dort werden auch die Namen der zum Upgrade stehenden Pakete angezeigt.
                      Ich habe mal ein Screenshot gemacht wie das auf sway aussieht.
                      Und welches Plasma läuft bei dir Plasma (X11) oder Plasma (Wayland) ?

                      • md_39118 hat auf diesen Beitrag geantwortet.

                        tuxnix
                        Hallo
                        Das Endeavour läuft mit Plasma (X11)
                        Mit Wayland gibt es nach der User Anmeldung nur einen schwarzen Monitor keine Konsole nichts.
                        Die 1 Nachricht kommt gleich nach dem Anmelden, die 2 Nachricht nach 7 Minuten.
                        Beide Nachrichten zeigen die anstehenden Pakete. Nach 4 Stunden ist keine Nachricht erfolgt.
                        Das werde ich nochmal Kontrollieren.
                        Eigentlich wollte ich noch ein Bildschirm Foto anhängen, aber wie, ist ja sehr umständlich hier im Forum.

                        • tuxnix hat auf diesen Beitrag geantwortet.