• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst]backintime: Fehler beim Schreiben einer Konfiguration

Boreas

Member
bit (GUI-Variante) startet beim 1. Aufruf mit einem Dialog zur Festlegung der Konfiguration. Diesen kann ich nicht abschließen, da
genau beim Versuch des Abspeicherns dieser mit folgender Fehlermeldung abgebrochen wird:
Code:
Schreiben eines neuen crontab ist fehlgeschlagen.
Starte ich bit (auch in der GUI-Variante) aus einer Konsole heraus bit kommt folgende Fehlermeldung:
Code:
ERROR:dbus.proxies:Introspect error on :1.53:/UdevRules: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied:
Rejected send message, 1 matched rules; type="method_call", sender=":1.103" (uid=1000 pid=6709 comm="python3 -Es /usr/share/backintime
/qt4/app.py ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" 
destination=":1.53" (uid=0 pid=2951 comm="/usr/bin/python3 -Es /usr/share/backintime/qt4/ser")
anschließend erscheint das Dialogfenster zur Festlegung der Konfiguartion, die dann wie beswchrieben nicht erfolgreich beendet werden kann. In der Konsol erscheint dann folgende Fehlermeldung:
Code:
Fehlermeldung: ERROR: Failed to write lines to crontab: 1, /var/spool/cron/tabs: Datei oder Verzeichnis nicht gefunden
/var/spool/cron/tabs: mkdir: Datei oder Verzeichnis nicht gefunden
Bei einer Standardinstallation von openSUSE Leap 15.0 als virtuelle Maschine treten diese Probleme nicht auf.
Ich habe bereits in div. Foren und anderen Quellen recherchiert - ohne Erfolg. Da ich schon nicht wirklich etwas mit der Teilmeldung
Code:
/UdevRules: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied
und der genannten Zugriffverweigerung des DBus durch eine Udev-Regel anfangen kann, frage ich hier mal nach, ob jemand hier Rat weiß.
Angaben zum System:
Code:
>uname -a
Linux linux-hypnos 4.12.14-lp150.12.22-default #1 SMP Sat Oct 13 05:05:16 UTC 2018 (09415e8) x86_64 x86_64 x86_64 GNU/Linux
Code:
>cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.0"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.0"
PRETTY_NAME="openSUSE Leap 15.0"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.0"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
und noch zwei Ausgaben:
Code:
Loading repository data...
Reading installed packages...

S  | Name            | Type    | Version          | Arch   | Repository            
---+-----------------+---------+------------------+--------+-----------------------
i  | backintime      | package | 1.1.24-lp150.1.5 | noarch | openSUSE-Leap-15.0-Oss
i+ | backintime-lang | package | 1.1.24-lp150.1.5 | noarch | openSUSE-Leap-15.0-Oss
i+ | backintime-qt4  | package | 1.1.24-lp150.1.5 | noarch | openSUSE-Leap-15.0-Oss
und
Code:
>zypper se -si python3
Building repository 'openSUSE-Leap-15.0-1' cache .............................................................................[done]
Loading repository data...
Reading installed packages...

S | Name                 | Type    | Version                              | Arch   | Repository               
--+----------------------+---------+--------------------------------------+--------+--------------------------
i | libpython3_6m1_0     | package | 3.6.5-lp150.2.3.1                    | x86_64 | openSUSE-Leap-15.0-Update
i | python3              | package | 3.6.5-lp150.2.3.1                    | x86_64 | openSUSE-Leap-15.0-Update
i | python3-apparmor     | package | 2.12-lp150.5.1                       | x86_64 | openSUSE-Leap-15.0-Oss   
i | python3-apparmor     | package | 2.12-lp150.5.1                       | x86_64 | openSUSE-Leap-15.0-1     
i | python3-appdirs      | package | 1.4.3-lp150.1.6                      | noarch | openSUSE-Leap-15.0-Oss   
i | python3-appdirs      | package | 1.4.3-lp150.1.6                      | noarch | openSUSE-Leap-15.0-1     
i | python3-base         | package | 3.6.5-lp150.2.3.1                    | x86_64 | openSUSE-Leap-15.0-Update
i | python3-bind         | package | 9.11.2-lp150.8.6.1                   | noarch | openSUSE-Leap-15.0-Update
i | python3-cmdln        | package | 2.0.0-lp150.1.3                      | noarch | openSUSE-Leap-15.0-Oss   
i | python3-cmdln        | package | 2.0.0-lp150.1.3                      | noarch | openSUSE-Leap-15.0-1     
i | python3-createrepo_c | package | 0.10.0.git20170131.04828e6-lp150.3.1 | x86_64 | openSUSE-Leap-15.0-Oss   
i | python3-createrepo_c | package | 0.10.0.git20170131.04828e6-lp150.3.1 | x86_64 | openSUSE-Leap-15.0-1     
i | python3-cupshelpers  | package | 1.5.7-lp150.5.1                      | noarch | openSUSE-Leap-15.0-Oss   
i | python3-cupshelpers  | package | 1.5.7-lp150.5.1                      | noarch | openSUSE-Leap-15.0-1     
i | python3-curses       | package | 3.6.5-lp150.2.3.1                    | x86_64 | openSUSE-Leap-15.0-Update
i | python3-dbm          | package | 3.6.5-lp150.2.3.1                    | x86_64 | openSUSE-Leap-15.0-Update
i | python3-dbus-python  | package | 1.2.4-lp150.4.4                      | x86_64 | openSUSE-Leap-15.0-Oss   
i | python3-dbus-python  | package | 1.2.4-lp150.4.4                      | x86_64 | openSUSE-Leap-15.0-1     
i | python3-decorator    | package | 4.2.1-lp150.1.3                      | noarch | openSUSE-Leap-15.0-Oss   
i | python3-decorator    | package | 4.2.1-lp150.1.3                      | noarch | openSUSE-Leap-15.0-1     
i | python3-firewall     | package | 0.5.5-lp150.2.9.1                    | noarch | openSUSE-Leap-15.0-Update
i | python3-gobject      | package | 3.26.1-lp150.1.4                     | x86_64 | openSUSE-Leap-15.0-Oss   
i | python3-gobject      | package | 3.26.1-lp150.1.4                     | x86_64 | openSUSE-Leap-15.0-1     
i | python3-packaging    | package | 16.8-lp150.1.6                       | noarch | openSUSE-Leap-15.0-Oss   
i | python3-packaging    | package | 16.8-lp150.1.6                       | noarch | openSUSE-Leap-15.0-1     
i | python3-pip          | package | 10.0.1-lp150.1.2                     | noarch | openSUSE-Leap-15.0-Oss   
i | python3-pip          | package | 10.0.1-lp150.1.2                     | noarch | openSUSE-Leap-15.0-1     
i | python3-ply          | package | 3.10-lp150.1.6                       | noarch | openSUSE-Leap-15.0-Oss   
i | python3-ply          | package | 3.10-lp150.1.6                       | noarch | openSUSE-Leap-15.0-1     
i | python3-pycups       | package | 1.9.73-lp150.1.7                     | x86_64 | openSUSE-Leap-15.0-Oss   
i | python3-pycups       | package | 1.9.73-lp150.1.7                     | x86_64 | openSUSE-Leap-15.0-1     
i | python3-pycurl       | package | 7.43.0.1-lp150.2.5                   | x86_64 | openSUSE-Leap-15.0-Oss   
i | python3-pycurl       | package | 7.43.0.1-lp150.2.5                   | x86_64 | openSUSE-Leap-15.0-1     
i | python3-pyparsing    | package | 2.2.0-lp150.1.12                     | noarch | openSUSE-Leap-15.0-Oss   
i | python3-pyparsing    | package | 2.2.0-lp150.1.12                     | noarch | openSUSE-Leap-15.0-1     
i | python3-qt4          | package | 4.12.1-lp150.2.7                     | x86_64 | openSUSE-Leap-15.0-Oss   
i | python3-setuptools   | package | 38.4.1-lp150.1.3                     | noarch | openSUSE-Leap-15.0-Oss   
i | python3-setuptools   | package | 38.4.1-lp150.1.3                     | noarch | openSUSE-Leap-15.0-1     
i | python3-sip          | package | 4.19.7-lp150.1.3                     | x86_64 | openSUSE-Leap-15.0-Oss   
i | python3-six          | package | 1.11.0-lp150.2.3                     | noarch | openSUSE-Leap-15.0-Oss   
i | python3-six          | package | 1.11.0-lp150.2.3                     | noarch | openSUSE-Leap-15.0-1     
i | python3-slip         | package | 0.6.5-lp150.4.3                      | noarch | openSUSE-Leap-15.0-Oss   
i | python3-slip         | package | 0.6.5-lp150.4.3                      | noarch | openSUSE-Leap-15.0-1     
i | python3-slip-dbus    | package | 0.6.5-lp150.4.3                      | noarch | openSUSE-Leap-15.0-Oss   
i | python3-slip-dbus    | package | 0.6.5-lp150.4.3                      | noarch | openSUSE-Leap-15.0-1     
i | python3-speechd      | package | 0.8.8-lp150.1.2                      | x86_64 | openSUSE-Leap-15.0-Oss   
i | python3-speechd      | package | 0.8.8-lp150.1.2                      | x86_64 | openSUSE-Leap-15.0-1     
i | python3-zypp-plugin  | package | 0.6.3-lp150.1.2                      | noarch | openSUSE-Leap-15.0-Oss   
i | python3-zypp-plugin  | package | 0.6.3-lp150.1.2                      | noarch | openSUSE-Leap-15.0-1
 
OP
B

Boreas

Member
Hallo Sauerland,

zunächst vielen Dank für die Reaktion. Hier die Aufgaben:
Code:
>ls -al /var/spool/cron/tabs/
ls: cannot access '/var/spool/cron/tabs/': No such file or directory
Anm.: Das Verzeichnis '/var/spool/cron/tabs/' wird erst durch bit erstellt, beim Schreiben der Konfiguration.
und hier noch
Code:
>zypper se -si cron
Loading repository data...
Reading installed packages...

S | Name                | Type    | Version          | Arch   | Repository            
--+---------------------+---------+------------------+--------+-----------------------
i | cron                | package | 4.2-lp150.2.32   | x86_64 | openSUSE-Leap-15.0-Oss
i | cronie              | package | 1.5.1-lp150.2.32 | x86_64 | openSUSE-Leap-15.0-Oss
i | perl-Config-Crontab | package | 1.45-lp150.1.7   | noarch | openSUSE-Leap-15.0-Oss
 
OP
B

Boreas

Member
Hallo Sauerland,
herzlichen Dank, dass Du Dir noch einmal Gedanken gemacht hast. Ich habe das Verzeichnis erstellt als root mit
Code:
mkdir /var/spool/cron/tabs/ -p
Leider startet bit nicht mehr soweit wie zuvor. Folgende Meldung erscheint noch sofern ich bit aus der Konsole starte:
Code:
>backintime-qt4

Back In Time
Version: 1.1.24

Back In Time comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type `backintime --license' for details.

ERROR:dbus.proxies:Introspect error on :1.55:/UdevRules: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: 
Rejected send message, 1 matched rules; type="method_call", sender=":1.109" (uid=1000 pid=5881 comm=
"python3 -Es /usr/share/backintime/qt4/app.py ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name=
"(unset)" requested_reply="0" destination=":1.55" (uid=0 pid=3288 comm="/usr/bin/python3 -Es /usr/share/backintime/qt4/ser")
Das war es auch schon - keine weitere Meldung. Kein Dialog - nichts. journalctl wirft praktisch nur das gleiche aus:
Code:
Nov 01 10:06:56 linux-hypnos dbus-daemon[2066]: [system] Rejected send message, 1 matched rules; type="method_call", 
sender=":1.126" (uid=1000 pid=6236 comm="python3 -Es /usr/share/backintime/common/backintim") interface=
"org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination=
":1.55" (uid=0 pid=3288 comm="/usr/bin/python3 -Es /usr/share/backintime/qt4/ser")
Ich denke ich verfolge die Sache nicht länger. Vielleicht beschäftige in mich lieber gleich mit
Code:
rsync
oder
Code:
borgbackup
und nochmals vielen Dank.
 

/dev/null

Moderator
Teammitglied
Hallo Boreas,

auch wenn es dir bei deinem Problem nicht helfen wird: ich nutze schon sehr lange Backintime für das tägliche automatische Sichern der (fast vollständigen) /home meiner (privaten) Benutzer auf mein NAS. Völlig problemlos und auch ohne das von dir beschriebene Problem.

Fragen:
1. Unter welchem User läuft bei dir BIT? (Bei mir startet das Programm jeweils unter dem Nutzer, dessen /home gerade gesichert werden soll. Und damit sich die einzelnen Sicherungsläufe nicht gegenseitig behindern, habe ich in den Einstellungen bei allen Nutzern eingestellt, dass BIT nur jeweils eine Sicherung machen darf.)
2. Hast du schon mal getestet, ob bei den beteiligten Nutzern auch grundsätzlich Cronjobs angelegt werden können und diese auch angezeigt werden? Also:
Code:
crontab -e
und dann irgend einen ungefährlichen Cronjob eintragen, dann mit
Code:
crontab -l
überprüfen ob der Job auch zu sehen ist und vielleicht auch mal bis zum Zeitpunkt warten, ob dieser auch wirklich ausgeführt wird. Die genannten Punkte natürlich auch bei allen betreffenden Usern.

Wenn dann das auch mit BIT funktioniert, sollte in etwa das folgende zu sehen sein:

Code:
peter@erde:~> crontab -l

#Back In Time system entry, this will be edited by the gui:
0 20 * * * /usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null
#Back In Time system entry, this will be edited by the gui:
0 21 * * 6 /usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime --profile-id 2 backup-job >/dev/null 2>&1
#Back In Time system entry, this will be edited by the gui:
0 21 * * 7 /usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime --profile-id 4 backup-job >/dev/null
Vielleicht liegt es nur daran?

MfG Peter
 
Zusätzlich zu meinem Vorposter:

Konsolenausgaben bitte immer incl. der kompletten Eingabezeile posten so kann man dann auch sehen, ob als root oder User.

Und bitte nicht mit
Code:
sudo
, sondern mit
Code:
su -
zum root wechseln.
 
OP
B

Boreas

Member
Entschuldigung hat alles ein bisschen länger gedauert, aber ganz ehrlich ich habe in den ganzen Jahren bisher noch nie ein cron-job
selbst erstellt. Also habe ich versucht, mich mit den Grundlagen ein wenig vertraut zu machen.
(Dabei kam ich nicht daran vorbei auch etwas über systemd-timer zu lesen - meinem persönlichen Eindruck nach
gefällt mir die die zeitgesteuerte Ausführung von Programmen, wie sie Systemd durch Timer-Unit löst, besser - sorry anderes Thema.)

Zunächst die Ausgaben crontab -l
Code:
jdoo@linux-hypnos:~
>crontab -l
no crontab for jdoo
Dann die Ausgabe von crontab -l nach dem Erstellen eines neuen cronjobs mit crontab -e
Code:
>crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.zutuNs installed on Fri Nov  2 09:09:00 2018)
# (Cronie version 4.2)
*/1 * * * * (echo "Hallo Welt") >>/home/jdoo/Vorlagen/ausgabecronjob.txt
hier hier die Ausgabe des Dateiinhalts von /home/jdoo/Vorlagen/ausgabecronjob.txt nach einige Minuten
Code:
cat /home/jdoo/Vorlagen/ausgabecronjob.txt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Hallo Welt
Anm.: Es gibt nur einen einfachen Benutzer auf meinem Rechner. Versuchsweise hatte ich einen 2. Benutzer auch schon angelegt, jedoch
hinsichtlich bit sah das auch nicht anders aus.

@Sauerland
I.d. R. öffne ich eine root-konsole und führe dann die Befehle aus. sudo benutze ich nicht. Ich habe immer die komplette Eingabezeile mit gepostet. Mein prompt hat einen Zeilenumbruch, da bei längeren Zeilen ich das als besser lesbar empfinde. (Wen es interessieren sollte - hier mein Prompt:
Code:
PS1="\[$(ppwd)\]\[\033[1;36m\]\u\[\033[1;35m\]\\100\[\033[1;33m\]\h:\[\033[1;37m\]\w\n>"
@Peter und Sauerland: herzlichen Dank für Eure Hilfe - in jedem Fall habe ich wieder dazugelernt. Im Ergebnis denke ich:
typischer Fall von PEBKAC. Ich werde am Wochenende die HDs tauschen und Leap neu installieren und dann prüfen, ob bit läuft.
Dann schrittweise die 3 weiteren Repos, die ich jetzt nutze einbinden und ...
Auf jeden Fall gebe ich anschließend an dieser Stelle noch ein Feedback.
(Ich weiß, dass dies nicht die Art ist wie man mit Problemen unter Linux umgeht, aber für mich als Anfänger doch tolerierbar;) .)
 
OP
B

Boreas

Member
Hier nun kurz das Ergebnis:
  • Neuinstallation von openSUSE Leap 15.0 vom USB-Stick.
  • Direkt danach bit installiert. Updates gefahren.
  • bit aus Konsole aufgerufen. Warnmeldung: import keyring failed. Erfolgreich Konfiguration und Backup
    auf externe Festplatte erstellt. Keine weiteren Fehlermeldungen.
  • Anschließend 3 weitere Repos eingebunden. Repos priorisiert.
  • Weitere Programme installiert, die ich üblicherweise verwende.
  • Erneut Updates gefahren.
  • Wieder bit aus Konsole aufgerufen. Warnmeldung: import keyring failed. Weitere Testkonfiguration und Backup erstellt.
Alles erfolgreich.
Das Problem ist offenbar verschwunden.
Schlussfolgerung: Tatsächlich typischer Fall von PEBKAC.
Ich danke all denen, die hier versucht haben mir zu helfen.
 
Oben