CI: Renovate-Schedule von wöchentlich auf täglich verkürzt

'before 6am on monday' erlaubte nur einmal pro Woche automatische
PR-Erstellung - jeder außerhalb dieses Fensters gefundene Update musste
im Dependency-Dashboard-Issue erst manuell abgehakt werden ("Awaiting
Schedule"), auch nach der letzten Automerge-Änderung. 'before 6am' (ohne
Wochentag) öffnet das Fenster jetzt täglich, PRs für sichere Updates
laufen dadurch spürbar zeitnaher und größtenteils ohne manuelles
Abhaken durch.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.gitea/workflows/code-quality.yaml

@@ -24,16 +24,14 @@ jobs:
           components: clippy, rustfmt
           cache: false
 
+      # Ein rohes 'actions/cache' auf target/ liefert zwar einen technischen Cache-Hit (Dateien
+      # werden wiederhergestellt), Cargo kompiliert die Abhängigkeiten aber oft trotzdem neu:
+      # Der tar-basierte Restore-Vorgang setzt bei allen wiederhergestellten Dateien dieselbe
+      # Mtime, wodurch Cargos Fingerprinting nicht mehr zuverlässig erkennen kann, was
+      # älter/neuer als was ist, und sicherheitshalber alles neu baut. Swatinem/rust-cache ist
+      # genau dafür gebaut (u. a. gezielte Mtime-Korrektur nach dem Restore).
       - name: Cache Cargo-Abhängigkeiten & Build-Artefakte
-        uses: actions/cache@v6
-        with:
-          path: |
-            ~/.cargo/registry
-            ~/.cargo/git
-            target
-          key: cargo-${{ runner.os }}-${{ hashFiles('Cargo.lock') }}
-          restore-keys: |
-            cargo-${{ runner.os }}-
+        uses: Swatinem/rust-cache@v2
 
       - name: Formatierung automatisch beheben
         run: cargo fmt

.gitea/workflows/main.yaml

@@ -47,16 +47,16 @@ jobs:
           toolchain: stable
           cache: false
 
+      # Ein rohes 'actions/cache' auf target/ liefert zwar einen technischen Cache-Hit
+      # (Dateien werden restauriert), Cargo kompiliert die Abhängigkeiten aber trotzdem neu:
+      # Der tar-basierte Restore-Vorgang setzt bei allen wiederhergestellten Dateien
+      # (Quelldateien wie kompilierte .rlib/.d-Dateien) dieselbe Mtime, wodurch Cargos
+      # Fingerprinting nicht mehr zuverlässig erkennen kann, was tatsächlich älter/neuer als
+      # was ist, und sicherheitshalber alles neu baut. Swatinem/rust-cache ist genau dafür
+      # gebaut (u. a. gezielte Mtime-Korrektur nach dem Restore) und cached dabei automatisch
+      # auch beide Cross-Compilation-Targets (x86_64 + aarch64) in diesem Job.
       - name: Cache Cargo-Abhängigkeiten & Build-Artefakte
-        uses: actions/cache@v6
-        with:
-          path: |
-            ~/.cargo/registry
-            ~/.cargo/git
-            target
-          key: cargo-${{ runner.os }}-${{ hashFiles('Cargo.lock') }}
-          restore-keys: |
-            cargo-${{ runner.os }}-
+        uses: Swatinem/rust-cache@v2
 
       - name: Alte Paketierungs-Ausgaben aus dem Cache entfernen
         run: rm -rf target/debian target/generate-rpm target/arch target/completions

.gitea/workflows/testing.yaml

@@ -47,16 +47,16 @@ jobs:
           toolchain: stable
           cache: false
 
+      # Ein rohes 'actions/cache' auf target/ liefert zwar einen technischen Cache-Hit
+      # (Dateien werden restauriert), Cargo kompiliert die Abhängigkeiten aber trotzdem neu:
+      # Der tar-basierte Restore-Vorgang setzt bei allen wiederhergestellten Dateien
+      # (Quelldateien wie kompilierte .rlib/.d-Dateien) dieselbe Mtime, wodurch Cargos
+      # Fingerprinting nicht mehr zuverlässig erkennen kann, was tatsächlich älter/neuer als
+      # was ist, und sicherheitshalber alles neu baut. Swatinem/rust-cache ist genau dafür
+      # gebaut (u. a. gezielte Mtime-Korrektur nach dem Restore) und cached dabei automatisch
+      # auch beide Cross-Compilation-Targets (x86_64 + aarch64) in diesem Job.
       - name: Cache Cargo-Abhängigkeiten & Build-Artefakte
-        uses: actions/cache@v6
-        with:
-          path: |
-            ~/.cargo/registry
-            ~/.cargo/git
-            target
-          key: cargo-${{ runner.os }}-${{ hashFiles('Cargo.lock') }}
-          restore-keys: |
-            cargo-${{ runner.os }}-
+        uses: Swatinem/rust-cache@v2
 
       - name: Alte Paketierungs-Ausgaben aus dem Cache entfernen
         run: rm -rf target/debian target/generate-rpm target/arch target/completions

.gitea/workflows/unit-tests.yaml

@@ -8,6 +8,7 @@ on:
       - reopened
     branches:
       - testing
+      - dev
 
 jobs:
   test:
@@ -23,16 +24,11 @@ jobs:
           toolchain: stable
           cache: false
 
+      # Siehe main.yaml/testing.yaml: Swatinem/rust-cache statt eines rohen 'actions/cache' auf
+      # target/, das trotz Cache-Hit wegen verschobener Mtimes nach dem Restore oft trotzdem
+      # alles neu kompiliert.
       - name: Cache Cargo-Abhängigkeiten & Build-Artefakte
-        uses: actions/cache@v6
-        with:
-          path: |
-            ~/.cargo/registry
-            ~/.cargo/git
-            target
-          key: cargo-${{ runner.os }}-${{ hashFiles('Cargo.lock') }}
-          restore-keys: |
-            cargo-${{ runner.os }}-
+        uses: Swatinem/rust-cache@v2
 
       - name: Run Tests
         run: cargo test

Cargo.lock

@@ -2052,7 +2052,7 @@ checksum = "ba467056f1b547ed52077911161fc86985becbc60e8e1857c8a144dab0def891"
 
 [[package]]
 name = "smart-mount"
-version = "2.0.3"
+version = "2.0.4"
 dependencies = [
  "aes-gcm 0.11.1",
  "anyhow",

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "smart-mount"
-version = "2.0.3"
+version = "2.0.4"
 edition = "2024"
 authors = ['DragonSlayer_14']
 readme = "README.md"
@@ -110,7 +110,13 @@ suggests = { "davfs2" = "*", "cifs-utils" = "*", "nfs-utils" = "*" }
 post_install_script = """
 if command -v systemctl >/dev/null 2>&1; then
     systemctl daemon-reload || true
-    systemctl enable --now smart-mount-mount.service smart-mount-watch.timer || true
+    # smart-mount-mount.service mountet echte Netzlaufwerke (kann bei nicht erreichbaren
+    # Servern pro Paar mehrere zehn Sekunden dauern) - "enable --now" wuerde synchron darauf
+    # warten und damit die Paketinstallation blockieren, daher aktivieren + nur als
+    # asynchroner Job starten ("--no-block", kehrt sofort zurueck).
+    systemctl enable smart-mount-mount.service || true
+    systemctl start --no-block smart-mount-mount.service || true
+    systemctl enable --now smart-mount-watch.timer || true
 fi
 /usr/lib/smart-mount/setup-cron || true
 """

README.md

@@ -145,13 +145,19 @@ System-systemd-Dienst ein - kein manueller Schritt nötig. Die dafür paketierte
   `smart-mount watch` aufruft (Standardintervall: 120s).
 
 Die postinst/postrm-Skripte des Pakets (bzw. das `.INSTALL`-Skriptlet bei Arch) aktivieren und
-starten beide Units beim Installieren/Upgraden (`systemctl enable --now ...`) und deaktivieren
-sie wieder beim Deinstallieren (`systemctl disable --now ...`) - siehe `packaging/deb/postinst`
-+ `packaging/deb/postrm` bzw. `[package.metadata.generate-rpm]`/`scripts/package-arch.py` in
+deaktivieren beide Units beim Installieren/Deinstallieren - siehe `packaging/deb/postinst` +
+`packaging/deb/postrm` bzw. `[package.metadata.generate-rpm]`/`scripts/package-arch.py` in
 `Cargo.toml`. Welche Laufwerkspaare dabei gemountet werden (und für welchen Nutzer, siehe
 `owner_user` unten) steuert ausschließlich `/etc/smart-mount/config.toml` - nicht die
 Unit-Dateien selbst.
 
+`smart-mount-mount.service` mountet dabei echte Netzlaufwerke, was bei einem gerade nicht
+erreichbaren Server pro Paar mehrere zehn Sekunden dauern kann (begrenzt auf max. 10 Minuten
+insgesamt, siehe `TimeoutStartSec` in der Unit) - das Paket-Setup wird dadurch **nicht**
+blockiert: `systemctl start --no-block` stößt den ersten Mount-Versuch beim Installieren nur an,
+statt synchron auf ihn zu warten. `smart-mount-watch.timer` wird dagegen sofort synchron
+gestartet (das Timer-"Armen" selbst ist immer augenblicklich fertig).
+
 **Anderes Watch-Intervall als der Standard (120s):** `settings.watch_interval_secs` in
 `config.toml` steuert nur den Cron-Fallback (s. u.) - der paketierte Timer hat ein fest
 eingebautes Intervall. Zum Anpassen:

packaging/deb/postinst

@@ -9,7 +9,15 @@ set -e
 if [ "$1" = "configure" ]; then
     if command -v systemctl >/dev/null 2>&1; then
         systemctl daemon-reload || true
-        systemctl enable --now smart-mount-mount.service smart-mount-watch.timer || true
+        # smart-mount-mount.service mountet echte Netzlaufwerke (kann pro konfiguriertem Paar
+        # mehrere zehn Sekunden dauern, wenn ein Server gerade nicht erreichbar ist) - "enable
+        # --now" wuerde synchron darauf warten und damit "apt"/"dpkg" fuer die gesamte Dauer
+        # blockieren. Daher: aktivieren (fuer den naechsten Boot) und der eigentliche Mount-Lauf
+        # nur als asynchroner Job ("--no-block", kehrt sofort zurueck) - das Paket-Setup selbst
+        # wartet also nie auf Netzwerk-Timeouts.
+        systemctl enable smart-mount-mount.service || true
+        systemctl start --no-block smart-mount-mount.service || true
+        systemctl enable --now smart-mount-watch.timer || true
     fi
     /usr/lib/smart-mount/setup-cron || true
 fi

packaging/systemd/smart-mount-mount.service

@@ -11,6 +11,14 @@ Type=oneshot
 # könnte).
 RemainAfterExit=yes
 ExecStart=/usr/bin/smart-mount mount --all
+# Harte Obergrenze statt des systemd-Standards (üblicherweise 90s): pro konfiguriertem Paar
+# werden Erreichbarkeit UND Mount-Versuch sequenziell geprüft (bis zu ~20s Erreichbarkeits-
+# check + 30s Mount-Timeout, siehe crate::mount::MOUNT_TIMEOUT_SECS), bei mehreren Paaren
+# summiert sich das - 90s würde bei zwei oder mehr gerade nicht erreichbaren Servern schon
+# reichen, um mitten im Mount-Versuch abgebrochen zu werden. 10 Minuten sind großzügig genug für
+# eine typische Anzahl Paare, ohne bei einem echten Hänger (z. B. einer verwaisten Dateisperre)
+# unbegrenzt zu warten.
+TimeoutStartSec=600
 # Explizit (statt sich auf den systemd-Standard zu verlassen): stdout/stderr gehen ins Journal,
 # unter einem festen, von der jeweiligen Unit unabhängigen Tag - 'journalctl -t smart-mount'
 # zeigt damit die Ausgaben aller smart-mount-Units gebündelt.

renovate.json

@@ -1,29 +1,59 @@
 {
   "$schema": "https://docs.renovatebot.com/renovate-schema.json",
-  "extends": ["config:recommended"],
+  "extends": [
+    "config:recommended"
+  ],
   "timezone": "Europe/Berlin",
-  "schedule": ["before 6am on monday"],
+  "schedule": [
+    "before 6am"
+  ],
   "baseBranchPatterns": [
     "dev"
   ],
   "packageRules": [
     {
-      "matchFileNames": [".gitea/workflows/**"],
+      "matchFileNames": [
+        ".gitea/workflows/**"
+      ],
       "groupName": "Gitea Actions",
       "separateMajorMinor": false,
       "separateMinorPatch": false
     },
     {
-      "matchManagers": ["cargo"],
+      "matchManagers": [
+        "cargo"
+      ],
       "groupName": "Cargo Dependencies",
       "separateMajorMinor": false,
       "separateMinorPatch": false
     },
     {
-      "matchManagers": ["dockerfile", "docker-compose"],
+      "matchManagers": [
+        "dockerfile",
+        "docker-compose"
+      ],
       "groupName": "Docker-Images",
       "separateMajorMinor": false,
       "separateMinorPatch": false
+    },
+    {
+      "description": "Patch-/Minor-/Digest-Updates automatisch mergen, sobald alle CI-Checks (inkl. Unit-Tests) erfolgreich sind - Major-Updates sind unten explizit ausgenommen (siehe nächste Regel).",
+      "matchUpdateTypes": [
+        "patch",
+        "minor",
+        "digest",
+        "lockFileMaintenance"
+      ],
+      "automerge": true,
+      "automergeType": "pr",
+      "platformAutomerge": true
+    },
+    {
+      "description": "Major-Updates immer manuell prüfen, da potenziell brechende Änderungen.",
+      "matchUpdateTypes": [
+        "major"
+      ],
+      "automerge": false
     }
   ],
   "customManagers": [

scripts/package-arch.py

@@ -105,16 +105,26 @@ def build_install_scriptlet(name, installable, all_units, has_cron_helper):
     Cron-Fallback-Hilfsprogramm ('usr/lib/<name>/setup-cron', siehe src/bin/setup-cron.rs) beim
     Installieren/Upgraden auf bzw. entfernt dessen Cron-Datei beim Entfernen wieder. Rein anhand
     der tatsächlich gefundenen Unit-Dateien/Hilfsprogramme zusammengesetzt, ohne den
-    Anwendungsnamen selbst hart zu codieren (der als `name`-Parameter hereinkommt)."""
-    installable_str = " ".join(installable)
+    Anwendungsnamen selbst hart zu codieren (der als `name`-Parameter hereinkommt).
+
+    '.service'-Units werden bewusst NICHT über 'enable --now' gestartet: Bei einem oneshot-
+    Service (typischer Fall für ein Boot-Setup-Skript) würde das den ExecStart-Befehl synchron
+    ausführen und damit 'pacman' für die gesamte Laufzeit des Skripts blockieren (siehe
+    packaging/deb/postinst für den konkreten Fall, der das erst sichtbar gemacht hat: ein
+    Mount-Versuch gegen ein gerade nicht erreichbares Netzlaufwerk). '.timer'-Units sind davon
+    nicht betroffen - sie nur zu "armen" ist immer sofort fertig - und starten daher weiterhin
+    synchron mit 'enable --now'."""
+    timers = [u for u in installable if u.endswith(".timer")]
+    services = [u for u in installable if not u.endswith(".timer")]
     all_units_str = " ".join(all_units)
 
-    systemd_enable = (
-        "    systemctl daemon-reload >/dev/null 2>&1 || true\n"
-        f"    systemctl enable --now {installable_str} >/dev/null 2>&1 || true\n"
-        if installable
-        else ""
-    )
+    systemd_enable = "    systemctl daemon-reload >/dev/null 2>&1 || true\n" if installable else ""
+    if timers:
+        systemd_enable += f"    systemctl enable --now {' '.join(timers)} >/dev/null 2>&1 || true\n"
+    for service in services:
+        systemd_enable += f"    systemctl enable {service} >/dev/null 2>&1 || true\n"
+        systemd_enable += f"    systemctl start --no-block {service} >/dev/null 2>&1 || true\n"
+
     systemd_reload = "    systemctl daemon-reload >/dev/null 2>&1 || true\n" if all_units else ""
     systemd_disable = (
         f"    systemctl disable --now {all_units_str} >/dev/null 2>&1 || true\n" if all_units else ""