jf/syncova-backup
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 9 Wiki Activity

[Fehler] #1

New Issue
Closed
opened 2026-08-17 14:08:42 +00:00 by jf · 1 comment
jf commented 2026-08-17 14:08:42 +00:00
Owner
Copy Link

Was ist passiert?

Beim Installieren ist das Script abgebrochen:

==> Repository
Das Repository gehoert nicht auf denselben Datentraeger wie die
zu sichernden Daten. Ein Datentraegerausfall naehme sonst Original
und Sicherung gemeinsam mit.

Ort des Repositorys [/srv/syncova-repository]: /tmp/syncova-repository
✓ Repository unter /tmp/syncova-repository (gehaertet)

==> Dienst
Der Dienst wird geprueft.

! Der Dienst meldet sich nicht als betriebsbereit.
  systemctl status syncova-api
  journalctl -u syncova-api -n 50 --no-pager

Abbruch: Die Einrichtung wird zurueckgebaut.

Der Lauf wird zurueckgebaut.
Dienst entfernt
Verzeichnis entfernt: /tmp/syncova-repository
Datei entfernt: /etc/syncova/syncova.env
Verzeichnis entfernt: /etc/syncova
Verzeichnis entfernt: /opt/syncova
Dienstkonto entfernt: syncova
Datenbank entfernt: syncova
Datenbankkonto entfernt: syncova

Es wurde nichts angetastet, was vorher schon da war.

Was haben Sie erwartet?

Das die Installation reibungslos durchläuft

Wie lässt es sich auslösen?

  1. Setup gestartet
  2. Postgres installiert
  3. Admin Benutzer erstellt
  4. Und beim Dienst prüfen bricht er ab.

Fehlercode und request_id

No response

Welcher Bereich?

Weiß ich nicht

Sind Daten in Gefahr?

Nein — es ist unschön, aber nichts geht verloren

Wie oft tritt es auf?

Jedes Mal

Diagnosebericht

# Syncova — Diagnosebericht

Erstellt: 2026-08-17 14:04:46 UTC

## Fassungen

```text
Unter /opt/syncova/bin liegt kein Programm.
```

## System

```text
Betriebssystem: Ubuntu 25.04
Kern:           Linux 6.17.4-2-pve
Architektur:    x86_64
Umgebung:       Container
systemd:        vorhanden
```

## Dienst

```text
Zustand:   inactive
Autostart: not-found

Unit syncova-api.service could not be found.
```

## Gesundheit

```text
curl ist nicht vorhanden.
```

## Datenbank und Schema

```text
Der Schemastand ist ohne lesbare Konfiguration nicht zu ermitteln.
```

## Repositories

```text
(keines gefunden oder nicht ermittelbar)
```

## Konfiguration

```text
/etc/syncova/syncova.env ist nicht lesbar (root-Rechte noetig?).
```

## Letzte Fehler- und Warnzeilen

```text
(keine Fehler- oder Warnzeilen in den letzten 400 Eintraegen)
```

## Die letzten Protokollzeilen

```text
Aug 17 13:48:42 syncova-backup systemd[1]: syncova-api.service: Scheduled restart job, restart counter is at 2.
Aug 17 13:48:42 syncova-backup systemd[1]: Started syncova-api.service - Syncova Control Plane.
Aug 17 13:48:42 syncova-backup (cova-api)[7584]: syncova-api.service: Failed to set up mount namespacing: /tmp/syncova-repository: No such file or directory
Aug 17 13:48:42 syncova-backup (cova-api)[7584]: syncova-api.service: Failed at step NAMESPACE spawning /opt/syncova/bin/syncova-api: No such file or directory
Aug 17 13:48:42 syncova-backup systemd[1]: syncova-api.service: Main process exited, code=exited, status=226/NAMESPACE
Aug 17 13:48:42 syncova-backup systemd[1]: syncova-api.service: Failed with result 'exit-code'.
Aug 17 13:48:46 syncova-backup systemd[1]: Stopped syncova-api.service - Syncova Control Plane.
Aug 17 14:04:21 syncova-backup systemd[1]: Started syncova-api.service - Syncova Control Plane.
Aug 17 14:04:21 syncova-backup (cova-api)[7975]: syncova-api.service: Failed to set up mount namespacing: /tmp/syncova-repository: No such file or directory
Aug 17 14:04:21 syncova-backup (cova-api)[7975]: syncova-api.service: Failed at step NAMESPACE spawning /opt/syncova/bin/syncova-api: No such file or directory
Aug 17 14:04:21 syncova-backup systemd[1]: syncova-api.service: Main process exited, code=exited, status=226/NAMESPACE
Aug 17 14:04:21 syncova-backup systemd[1]: syncova-api.service: Failed with result 'exit-code'.
Aug 17 14:04:26 syncova-backup systemd[1]: syncova-api.service: Scheduled restart job, restart counter is at 1.
Aug 17 14:04:26 syncova-backup systemd[1]: Started syncova-api.service - Syncova Control Plane.
Aug 17 14:04:26 syncova-backup (cova-api)[7992]: syncova-api.service: Failed to set up mount namespacing: /tmp/syncova-repository: No such file or directory
Aug 17 14:04:26 syncova-backup (cova-api)[7992]: syncova-api.service: Failed at step NAMESPACE spawning /opt/syncova/bin/syncova-api: No such file or directory
Aug 17 14:04:26 syncova-backup systemd[1]: syncova-api.service: Main process exited, code=exited, status=226/NAMESPACE
Aug 17 14:04:26 syncova-backup systemd[1]: syncova-api.service: Failed with result 'exit-code'.
Aug 17 14:04:31 syncova-backup systemd[1]: syncova-api.service: Scheduled restart job, restart counter is at 2.
Aug 17 14:04:31 syncova-backup systemd[1]: Started syncova-api.service - Syncova Control Plane.
Aug 17 14:04:31 syncova-backup (cova-api)[8010]: syncova-api.service: Failed to set up mount namespacing: /tmp/syncova-repository: No such file or directory
Aug 17 14:04:31 syncova-backup (cova-api)[8010]: syncova-api.service: Failed at step NAMESPACE spawning /opt/syncova/bin/syncova-api: No such file or directory
Aug 17 14:04:31 syncova-backup systemd[1]: syncova-api.service: Main process exited, code=exited, status=226/NAMESPACE
Aug 17 14:04:31 syncova-backup systemd[1]: syncova-api.service: Failed with result 'exit-code'.
Aug 17 14:04:36 syncova-backup systemd[1]: Stopped syncova-api.service - Syncova Control Plane.
```

## Sicherungen frueherer Aktualisierungen

```text
total 0
```

---

Protokollzeilen zum Vorfall

No response

Sonstiges

No response

Vor dem Absenden

  • Ich habe die Tabelle oben durchgesehen; es ist keiner dieser Fälle
  • Der Bericht enthält keine Passwörter, Schlüssel oder Tokens
  • Ich verwende die Fassung, die im Diagnosebericht steht
### Was ist passiert? Beim Installieren ist das Script abgebrochen: ==> Repository Das Repository gehoert nicht auf denselben Datentraeger wie die zu sichernden Daten. Ein Datentraegerausfall naehme sonst Original und Sicherung gemeinsam mit. Ort des Repositorys [/srv/syncova-repository]: /tmp/syncova-repository ✓ Repository unter /tmp/syncova-repository (gehaertet) ==> Dienst Der Dienst wird geprueft. ! Der Dienst meldet sich nicht als betriebsbereit. systemctl status syncova-api journalctl -u syncova-api -n 50 --no-pager Abbruch: Die Einrichtung wird zurueckgebaut. Der Lauf wird zurueckgebaut. Dienst entfernt Verzeichnis entfernt: /tmp/syncova-repository Datei entfernt: /etc/syncova/syncova.env Verzeichnis entfernt: /etc/syncova Verzeichnis entfernt: /opt/syncova Dienstkonto entfernt: syncova Datenbank entfernt: syncova Datenbankkonto entfernt: syncova Es wurde nichts angetastet, was vorher schon da war. ### Was haben Sie erwartet? Das die Installation reibungslos durchläuft ### Wie lässt es sich auslösen? 1. Setup gestartet 2. Postgres installiert 3. Admin Benutzer erstellt 4. Und beim Dienst prüfen bricht er ab. ### Fehlercode und request_id _No response_ ### Welcher Bereich? Weiß ich nicht ### Sind Daten in Gefahr? Nein — es ist unschön, aber nichts geht verloren ### Wie oft tritt es auf? Jedes Mal ### Diagnosebericht ````text # Syncova — Diagnosebericht Erstellt: 2026-08-17 14:04:46 UTC ## Fassungen ```text Unter /opt/syncova/bin liegt kein Programm. ``` ## System ```text Betriebssystem: Ubuntu 25.04 Kern: Linux 6.17.4-2-pve Architektur: x86_64 Umgebung: Container systemd: vorhanden ``` ## Dienst ```text Zustand: inactive Autostart: not-found Unit syncova-api.service could not be found. ``` ## Gesundheit ```text curl ist nicht vorhanden. ``` ## Datenbank und Schema ```text Der Schemastand ist ohne lesbare Konfiguration nicht zu ermitteln. ``` ## Repositories ```text (keines gefunden oder nicht ermittelbar) ``` ## Konfiguration ```text /etc/syncova/syncova.env ist nicht lesbar (root-Rechte noetig?). ``` ## Letzte Fehler- und Warnzeilen ```text (keine Fehler- oder Warnzeilen in den letzten 400 Eintraegen) ``` ## Die letzten Protokollzeilen ```text Aug 17 13:48:42 syncova-backup systemd[1]: syncova-api.service: Scheduled restart job, restart counter is at 2. Aug 17 13:48:42 syncova-backup systemd[1]: Started syncova-api.service - Syncova Control Plane. Aug 17 13:48:42 syncova-backup (cova-api)[7584]: syncova-api.service: Failed to set up mount namespacing: /tmp/syncova-repository: No such file or directory Aug 17 13:48:42 syncova-backup (cova-api)[7584]: syncova-api.service: Failed at step NAMESPACE spawning /opt/syncova/bin/syncova-api: No such file or directory Aug 17 13:48:42 syncova-backup systemd[1]: syncova-api.service: Main process exited, code=exited, status=226/NAMESPACE Aug 17 13:48:42 syncova-backup systemd[1]: syncova-api.service: Failed with result 'exit-code'. Aug 17 13:48:46 syncova-backup systemd[1]: Stopped syncova-api.service - Syncova Control Plane. Aug 17 14:04:21 syncova-backup systemd[1]: Started syncova-api.service - Syncova Control Plane. Aug 17 14:04:21 syncova-backup (cova-api)[7975]: syncova-api.service: Failed to set up mount namespacing: /tmp/syncova-repository: No such file or directory Aug 17 14:04:21 syncova-backup (cova-api)[7975]: syncova-api.service: Failed at step NAMESPACE spawning /opt/syncova/bin/syncova-api: No such file or directory Aug 17 14:04:21 syncova-backup systemd[1]: syncova-api.service: Main process exited, code=exited, status=226/NAMESPACE Aug 17 14:04:21 syncova-backup systemd[1]: syncova-api.service: Failed with result 'exit-code'. Aug 17 14:04:26 syncova-backup systemd[1]: syncova-api.service: Scheduled restart job, restart counter is at 1. Aug 17 14:04:26 syncova-backup systemd[1]: Started syncova-api.service - Syncova Control Plane. Aug 17 14:04:26 syncova-backup (cova-api)[7992]: syncova-api.service: Failed to set up mount namespacing: /tmp/syncova-repository: No such file or directory Aug 17 14:04:26 syncova-backup (cova-api)[7992]: syncova-api.service: Failed at step NAMESPACE spawning /opt/syncova/bin/syncova-api: No such file or directory Aug 17 14:04:26 syncova-backup systemd[1]: syncova-api.service: Main process exited, code=exited, status=226/NAMESPACE Aug 17 14:04:26 syncova-backup systemd[1]: syncova-api.service: Failed with result 'exit-code'. Aug 17 14:04:31 syncova-backup systemd[1]: syncova-api.service: Scheduled restart job, restart counter is at 2. Aug 17 14:04:31 syncova-backup systemd[1]: Started syncova-api.service - Syncova Control Plane. Aug 17 14:04:31 syncova-backup (cova-api)[8010]: syncova-api.service: Failed to set up mount namespacing: /tmp/syncova-repository: No such file or directory Aug 17 14:04:31 syncova-backup (cova-api)[8010]: syncova-api.service: Failed at step NAMESPACE spawning /opt/syncova/bin/syncova-api: No such file or directory Aug 17 14:04:31 syncova-backup systemd[1]: syncova-api.service: Main process exited, code=exited, status=226/NAMESPACE Aug 17 14:04:31 syncova-backup systemd[1]: syncova-api.service: Failed with result 'exit-code'. Aug 17 14:04:36 syncova-backup systemd[1]: Stopped syncova-api.service - Syncova Control Plane. ``` ## Sicherungen frueherer Aktualisierungen ```text total 0 ``` --- ```` ### Protokollzeilen zum Vorfall _No response_ ### Sonstiges _No response_ ### Vor dem Absenden - [x] Ich habe die Tabelle oben durchgesehen; es ist keiner dieser Fälle - [x] Der Bericht enthält keine Passwörter, Schlüssel oder Tokens - [x] Ich verwende die Fassung, die im Diagnosebericht steht
jf closed this issue 2026-08-18 06:12:08 +00:00
jf commented 2026-08-18 06:24:52 +00:00
Author
Owner
Copy Link

Behoben in v1.0.0-rc3 (a37631c).

Die Ursache

Sie stand wörtlich im Diagnosebericht:

syncova-api.service: Failed to set up mount namespacing:
    /tmp/syncova-repository: No such file or directory
status=226/NAMESPACE

Die Diensteinheit setzt PrivateTmp=yes. Der Dienst bekommt damit ein eigenes /tmp — der in ReadWritePaths genannte Ablageort existiert in seiner Sicht nicht, und systemd bricht ab, bevor das Programm überhaupt läuft. Deshalb kam nie eine Meldung aus Syncova selbst; es lief nie an.

Was daran der größere Fehler war

Nicht der Startfehler, sondern dass setup.sh /tmp überhaupt angenommen hat.

systemd-tmpfiles räumt /tmp regelmäßig auf, und auf vielen Systemen ist es ein tmpfs — nach einem Neustart leer. Wäre der Dienst gestartet, hätte die Anlage Sicherungen an einen Ort geschrieben, an dem sie von selbst verschwinden. Ohne Meldung, bis jemand sie braucht.

Insofern hat der Startfehler hier den schlimmeren Fall verhindert.

Behoben

  • /tmp, /var/tmp, /dev/shm, /run und jedes tmpfs werden abgelehnt — und zwar vor der Datenbankeinrichtung. Ihr Lauf hatte PostgreSQL installiert, das Schema angelegt und einen Administrator eingerichtet, bevor es scheiterte; das dauert jetzt Sekunden statt Minuten.
  • Der Abbruch zeigt den Grund. setup.sh liefert die letzten Journalzeilen gleich mit und erklärt 226/NAMESPACE. Ihr Hinweis auf journalctl war beim Rückbau bereits wertlos — da war der Dienst schon entfernt. Dass Sie den Bericht separat erstellen mussten, war der eigentliche Umweg.
  • Für Wegwerf-Umgebungen: SYNCOVA_SETUP_ALLOW_VOLATILE_REPOSITORY=ja. Dann wird PrivateTmp abgeschaltet, sonst startete der Dienst nie.

Regressionstest vorhanden und gegen die alte Fassung als fangend geprüft.

Für Ihren Server

tar -xzf syncova-v1.0.0-rc3-linux-amd64.tar.gz
cd syncova-v1.0.0-rc3-linux-amd64
shasum -a 256 -c SHA256SUMS
sudo ./setup.sh

Nehmen Sie einen dauerhaften Ort — /srv/syncova-repository ist die Vorgabe — und möglichst einen anderen Datenträger als den der Quelldaten.

Der Rückbau hat übrigens vollständig gegriffen: Nichts blieb liegen, und die Datenbank war vorher nicht vorhanden. Danke für den Bericht — er enthielt alles, was zur Analyse nötig war.

Behoben in **[v1.0.0-rc3](https://git.jfritzsche.de/jf/syncova-backup/releases/tag/v1.0.0-rc3)** (`a37631c`). ## Die Ursache Sie stand wörtlich im Diagnosebericht: ```text syncova-api.service: Failed to set up mount namespacing: /tmp/syncova-repository: No such file or directory status=226/NAMESPACE ``` Die Diensteinheit setzt `PrivateTmp=yes`. Der Dienst bekommt damit ein **eigenes** `/tmp` — der in `ReadWritePaths` genannte Ablageort existiert in seiner Sicht nicht, und systemd bricht ab, bevor das Programm überhaupt läuft. Deshalb kam nie eine Meldung aus Syncova selbst; es lief nie an. ## Was daran der größere Fehler war Nicht der Startfehler, sondern dass `setup.sh` `/tmp` **überhaupt angenommen** hat. `systemd-tmpfiles` räumt `/tmp` regelmäßig auf, und auf vielen Systemen ist es ein tmpfs — nach einem Neustart leer. Wäre der Dienst gestartet, hätte die Anlage Sicherungen an einen Ort geschrieben, an dem sie von selbst verschwinden. Ohne Meldung, bis jemand sie braucht. Insofern hat der Startfehler hier den schlimmeren Fall verhindert. ## Behoben - **`/tmp`, `/var/tmp`, `/dev/shm`, `/run` und jedes tmpfs werden abgelehnt** — und zwar **vor** der Datenbankeinrichtung. Ihr Lauf hatte PostgreSQL installiert, das Schema angelegt und einen Administrator eingerichtet, bevor es scheiterte; das dauert jetzt Sekunden statt Minuten. - **Der Abbruch zeigt den Grund.** `setup.sh` liefert die letzten Journalzeilen gleich mit und erklärt `226/NAMESPACE`. Ihr Hinweis auf `journalctl` war beim Rückbau bereits wertlos — da war der Dienst schon entfernt. Dass Sie den Bericht separat erstellen mussten, war der eigentliche Umweg. - Für Wegwerf-Umgebungen: `SYNCOVA_SETUP_ALLOW_VOLATILE_REPOSITORY=ja`. Dann wird `PrivateTmp` abgeschaltet, sonst startete der Dienst nie. Regressionstest vorhanden und gegen die alte Fassung als fangend geprüft. ## Für Ihren Server ```bash tar -xzf syncova-v1.0.0-rc3-linux-amd64.tar.gz cd syncova-v1.0.0-rc3-linux-amd64 shasum -a 256 -c SHA256SUMS sudo ./setup.sh ``` Nehmen Sie einen dauerhaften Ort — `/srv/syncova-repository` ist die Vorgabe — und möglichst einen anderen Datenträger als den der Quelldaten. Der Rückbau hat übrigens vollständig gegriffen: Nichts blieb liegen, und die Datenbank war vorher nicht vorhanden. Danke für den Bericht — er enthielt alles, was zur Analyse nötig war.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: jf/syncova-backup#1
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?