Automatisiertes Paketupgrade
- Bearbeitet
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.
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.
- Bearbeitet
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>"
- Bearbeitet
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.
tuxnix <a href="xyz">Link</a>
Da wird bei mir gar nichts dargestellt, weil der Ausdruck formal falsch ist (doppelte statt einfache Anführungszeichen, und fehlendes Protokoll).
tuxnix Klappt das denn bei dir?
Ja sicher, und ich habe auch Qt6 -> https://c.gmx.net/@327748706747023899/4ffRD5SyTKK-IIVCm4nnBQ/ROOT/ROOT
- Bearbeitet
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.
- Bearbeitet
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.
- Bearbeitet
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?
- Bearbeitet
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.
- Bearbeitet
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.targetMeine 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.timerHier 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- Bearbeitet
@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.
- Bearbeitet
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.
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.- Bearbeitet
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) ?
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.