7 Commits
Author SHA1 Message Date
DragonSlayer_14andClaude Sonnet 5 a5b48e560e CI: Renovate-Schedule von wöchentlich auf täglich verkürzt
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 27s
Security Scans / Trivy & OSV-Scanner (push) Successful in 56s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 1m20s
'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>
2026-09-20 23:36:48 +02:00
DragonSlayer_14andClaude Sonnet 5 ce266787b6 CI: Renovate merged sichere Updates automatisch, unit-tests laufen jetzt auch für PRs gegen dev
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 31s
Security Scans / Trivy & OSV-Scanner (push) Successful in 53s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 1m20s
Patch-/Minor-/Digest-Updates (Cargo, Gitea Actions, Docker-Images)
werden künftig automatisch gemergt, sobald alle CI-Checks erfolgreich
sind - Major-Updates bleiben weiterhin manuell zu prüfen, da sie eher
brechende Änderungen enthalten.

Voraussetzung dafür: unit-tests.yaml (der eigentliche 'cargo test'-Lauf)
löste bisher nur bei Pull Requests gegen 'testing' aus, nicht gegen
'dev' - Renovate-PRs zielen aber auf 'dev' und wurden damit nie durch
einen echten Build/Test abgesichert, nur durch die Security-/Secret-
Scans. Jetzt läuft er auch dort.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-20 23:27:16 +02:00
DragonSlayer_14andClaude Sonnet 5 121bffc289 CI: Ersetzt rohes actions/cache für Cargo-Build-Artefakte durch Swatinem/rust-cache
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 29s
Security Scans / Trivy & OSV-Scanner (push) Successful in 55s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 6m57s
Ein rohes 'actions/cache' auf target/ lieferte zwar einen technischen
Cache-Hit, Cargo kompilierte die Abhängigkeiten aber 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. Swatinem/rust-cache
behebt das gezielt (u. a. gezielte Mtime-Korrektur nach dem Restore).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-20 23:18:19 +02:00
Gitea-Bot fc68daddac Chore: Erhöht Patch-Version auf 2.0.4 für Promotion nach testing
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 29s
Security Scans / Trivy & OSV-Scanner (push) Successful in 57s
Security Scans / Trivy & OSV-Scanner (pull_request) Successful in 56s
TruffleHog Secret Scan / TruffleHog (pull_request) Successful in 25s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 1m40s
Unit-Tests / Unit-Tests (pull_request) Successful in 3m23s
2026-09-20 20:33:00 +00:00
DragonSlayer_14andClaude Sonnet 5 3bf2ce0718 Fix: Paketinstallation blockiert nicht mehr synchron auf smart-mount-mount.service
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 19s
Security Scans / Trivy & OSV-Scanner (push) Successful in 29s
Auto Patch-Version-Bump (Dev → Testing PR) / Erkenne relevante Änderungen im PR (pull_request) Successful in 13s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 47s
TruffleHog Secret Scan / TruffleHog (pull_request) Successful in 25s
Auto Patch-Version-Bump (Dev → Testing PR) / Patch-Version erhöhen & auf Dev pushen (pull_request) Successful in 14s
Security Scans / Trivy & OSV-Scanner (pull_request) Successful in 42s
Unit-Tests / Unit-Tests (pull_request) Successful in 4m18s
'systemctl enable --now smart-mount-mount.service' im postinst/RPM-
Scriptlet wartete synchron auf den kompletten 'mount --all'-Lauf -
bei nicht erreichbaren Laufwerken (Netzwerk-Timeouts pro Paar) blieb
'apt'/'dpkg'/'pacman' dadurch minutenlang ohne sichtbare Rückmeldung
hängen (Logs gehen ins Journal, nicht ins Paketmanager-Terminal).

Jetzt: 'systemctl enable' + 'systemctl start --no-block' für den
Mount-Service (stößt den ersten Mount-Versuch nur an, wartet nicht
darauf), 'enable --now' bleibt für den Watch-Timer (Timer "armen" ist
immer sofort fertig). scripts/package-arch.py unterscheidet das generisch
anhand der Dateiendung (.timer vs. .service), ohne den Anwendungsnamen
hart zu codieren. Zusätzlich TimeoutStartSec=600 im Unit-File als
Obergrenze gegen echte Hänger.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-20 22:31:53 +02:00
Gitea-Bot c4a415e3e4 Chore: Erhöht Patch-Version auf 2.0.3 für Promotion nach testing
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 26s
Security Scans / Trivy & OSV-Scanner (push) Successful in 54s
Security Scans / Trivy & OSV-Scanner (pull_request) Successful in 54s
TruffleHog Secret Scan / TruffleHog (pull_request) Successful in 28s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 1m29s
Unit-Tests / Unit-Tests (pull_request) Successful in 3m10s
2026-09-20 17:17:13 +00:00
DragonSlayer_14andClaude Sonnet 5 18d84c94f6 Fix: mount/unmount melden Fehlschläge jetzt korrekt, Logs im Journal sichtbar und persistent
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 15s
Security Scans / Trivy & OSV-Scanner (push) Successful in 31s
TruffleHog Secret Scan / TruffleHog (pull_request) Successful in 24s
Auto Patch-Version-Bump (Dev → Testing PR) / Erkenne relevante Änderungen im PR (pull_request) Successful in 15s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 59s
Auto Patch-Version-Bump (Dev → Testing PR) / Patch-Version erhöhen & auf Dev pushen (pull_request) Successful in 13s
Security Scans / Trivy & OSV-Scanner (pull_request) Successful in 44s
Unit-Tests / Unit-Tests (pull_request) Successful in 4m12s
'mount --all'/'unmount --all' gaben bisher immer Ok(()) zurück, selbst
wenn einzelne Laufwerkspaare nicht (aus)gehängt werden konnten (nur als
Text ausgegeben, nie propagiert) - anders als 'watch'. Dadurch zeigte
'systemctl status smart-mount-mount' nie "failed", egal was beim
Booten schiefging. run_mount/run_unmount propagieren Fehlschläge jetzt
wie 'watch' als Prozess-Fehler.

Zusätzlich: logger_ctdra::set_log_dir() zeigt jetzt auf
/var/log/smart-mount statt auf einen zufälligen Temp-Ordner, beide
systemd-Units haben ein festes SyslogIdentifier=smart-mount mit
explizitem StandardOutput/StandardError=journal (journalctl -t
smart-mount zeigt damit alles gebündelt), und
smart-mount-mount.service bleibt dank RemainAfterExit=yes nach einem
erfolgreichen Lauf als "active (exited)" sichtbar statt sofort wieder
auf "inactive" zu springen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-20 19:16:08 +02:00
14 changed files with 169 additions and 59 deletions
+7 -9
View File
@@ -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
+9 -9
View File
@@ -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
+9 -9
View File
@@ -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
+5 -9
View File
@@ -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
Generated
+1 -1
View File
@@ -2052,7 +2052,7 @@ checksum = "ba467056f1b547ed52077911161fc86985becbc60e8e1857c8a144dab0def891"
[[package]]
name = "smart-mount"
version = "2.0.2"
version = "2.0.4"
dependencies = [
"aes-gcm 0.11.1",
"anyhow",
+8 -2
View File
@@ -1,6 +1,6 @@
[package]
name = "smart-mount"
version = "2.0.2"
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
"""
+18 -3
View File
@@ -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:
@@ -162,6 +168,15 @@ sudo systemctl edit smart-mount-watch.timer
# OnUnitActiveSec=60s
```
**Logs:** beide Units schreiben mit festem `SyslogIdentifier=smart-mount` ins systemd-Journal -
`journalctl -u smart-mount-mount` / `-u smart-mount-watch` (oder gebündelt `journalctl -t
smart-mount`) zeigt sie an. Zusätzlich schreibt smart-mount dieselben Meldungen dauerhaft nach
`/var/log/smart-mount/log-<Datum>.log` (siehe `settings.log_level` für die Ausführlichkeit,
Standard `info`) - unabhängig von der Journal-Rotation. `smart-mount-mount.service` bleibt nach
einem erfolgreichen Lauf als "active (exited)" sichtbar (`RemainAfterExit=yes`), und ein
Fehlschlag beim Mounten mindestens eines konfigurierten Laufwerkspaars lässt den Dienst jetzt
auch tatsächlich als "failed" erscheinen, statt es stillschweigend zu ignorieren.
### Cron-Fallback (Systeme ohne systemd)
Ist beim Installieren/Upgraden des Pakets kein `systemctl` gefunden, aber `/etc/cron.d`
+9 -1
View File
@@ -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
@@ -5,7 +5,26 @@ Wants=network-online.target
[Service]
Type=oneshot
# Bleibt nach einem erfolgreichen Lauf als "active (exited)" sichtbar (statt sofort wieder
# "inactive") - macht in 'systemctl status' auf einen Blick erkennbar, dass der letzte Boot-Lauf
# tatsächlich durchlief, statt nur "inactive" zu zeigen (das genauso gut "nie gelaufen" heißen
# 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.
StandardOutput=journal
StandardError=journal
SyslogIdentifier=smart-mount
[Install]
WantedBy=multi-user.target
@@ -4,3 +4,6 @@ Description=smart-mount: check reachability and switch local/cloud if needed
[Service]
Type=oneshot
ExecStart=/usr/bin/smart-mount watch
StandardOutput=journal
StandardError=journal
SyslogIdentifier=smart-mount
+35 -5
View File
@@ -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": [
+18 -8
View File
@@ -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 ""
+22 -3
View File
@@ -2,7 +2,7 @@
use crate::config::{self, DrivePair};
use crate::db::credentials::CredentialStore;
use crate::reconcile;
use crate::reconcile::{self, Action};
fn select_pairs(
cfg: &crate::config::AppConfig,
@@ -32,9 +32,21 @@ pub async fn run_mount(name: Option<String>, all: bool) -> anyhow::Result<()> {
);
let creds = CredentialStore::open().await?;
let mut had_failure = false;
for pair in &pairs {
let outcome = reconcile::reconcile_pair(pair, &cfg.settings, &creds).await;
print_outcome(&outcome);
if matches!(outcome.action, Action::Failed(_)) {
had_failure = true;
}
}
// Ohne dies wäre `smart-mount-mount.service` (siehe packaging/systemd/) beim Booten selbst
// dann "erfolgreich" (Exit-Code 0), wenn tatsächlich kein einziges Laufwerkspaar gemountet
// werden konnte - `systemctl status` würde den Fehlschlag also nie sichtbar machen. Analog
// zu `watch::run` unten.
if had_failure {
anyhow::bail!("at least one drive pair could not be mounted");
}
Ok(())
}
@@ -52,17 +64,24 @@ pub async fn run_unmount(name: Option<String>, all: bool) -> anyhow::Result<()>
&format!("unmount: processing {} drive pair(s)", pairs.len()),
);
let mut had_failure = false;
for pair in &pairs {
match reconcile::unmount_pair(pair, &cfg.settings).await {
Ok(_) => println!("{} ({}): unmounted", pair.name, pair.id),
Err(e) => println!("{} ({}): ERROR: {e}", pair.name, pair.id),
Err(e) => {
println!("{} ({}): ERROR: {e}", pair.name, pair.id);
had_failure = true;
}
}
}
if had_failure {
anyhow::bail!("at least one drive pair could not be unmounted");
}
Ok(())
}
pub(crate) fn print_outcome(outcome: &reconcile::ReconcileOutcome) {
use reconcile::Action;
let action_str = match &outcome.action {
Action::NoOp => "no change".to_string(),
Action::MountedLocal => "mounted local".to_string(),
+6
View File
@@ -7,6 +7,12 @@ use smart_mount::cli;
async fn main() -> ExitCode {
smart_mount::config::init();
// Persistentes, gut auffindbares Log-Verzeichnis statt logger-ctdras Standard-Fallback
// (ein Ordner im System-Temp-Verzeichnis, siehe logger-ctdra-Doku) - smart-mount läuft
// ausschließlich als root/System-Dienst (siehe crate::systemd), daher immer derselbe,
// feste Pfad. Muss vor dem ersten Log-Aufruf stehen (siehe logger_ctdra::set_log_dir).
logger_ctdra::set_log_dir("/var/log/smart-mount");
let log_level = match smart_mount::config::pairs::load() {
Ok(cfg) => cfg.settings.log_level,
Err(_) => "info".to_string(),