@buhtz - yes, 1.5.3-rc1 builds cleanly with this PKGBUILD
Search Criteria
Package Details: backintime 1.5.3-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/backintime.git (read-only, click to copy) |
---|---|
Package Base: | backintime |
Description: | Simple backup system inspired from the Flyback Project and TimeVault. Qt5 GUI version. |
Upstream URL: | https://github.com/bit-team/backintime |
Licenses: | GPL |
Submitter: | None |
Maintainer: | graysky |
Last Packager: | graysky |
Votes: | 297 |
Popularity: | 0.93 |
First Submitted: | 2009-01-09 20:46 (UTC) |
Last Updated: | 2024-11-13 15:34 (UTC) |
Dependencies (10)
- backintime-cliAUR (backintime-cli-gitAUR)
- polkit (polkit-gitAUR, polkit-consolekitAUR)
- python-dbus
- python-pyqt6
- sshfs
- xorg-xdpyinfo
- python (python37AUR, python311AUR, python310AUR) (make)
- kompare (kompare-gitAUR) (optional) – diff/patch frontend
- meld (meld-gitAUR) (optional) – diff/patch frontend
- qt6-translations (optional) – translate BIT dialogs into native language
Required by (1)
- backintime-cli (optional)
Sources (1)
graysky commented on 2024-10-26 05:55 (UTC)
buhtz commented on 2024-10-25 07:30 (UTC)
To support the diagnosis of a complex issue it would help to know if you (at Arch/AUR) are able to build and test the release candidate with(out) issues. Thanks in advance.
buhtz commented on 2024-10-20 12:50 (UTC)
Please allow me to announce Release Candidate for Back In Time 1.5.3.
https://github.com/bit-team/backintime/releases/tag/v1.5.3-rc1
Please report back if you use it, even if no issues are found.
stefan.skupin commented on 2024-08-29 09:52 (UTC)
Same problem as described by NickNackGus here, since upgrade to 1.5.x (currently backintime 1.5.2-1 and cronie 1.7.2-1). The described workaround (setting XDG_RUNTIME_DIR in backintime's crontab command) helps.
anarchotaoist commented on 2024-08-05 00:53 (UTC)
Scheduled backups are working for me with Cronie 1.7.2-1 and BackInTime 1.5.1-1.
NickNackGus commented on 2024-08-04 22:36 (UTC)
I've already confirmed that my crontab setup is working correctly for other commands, mainly echo for testing. My current crontab after removing those test commands (time adjusted for testing):
$ crontab -l
#Back In Time system entry, this will be edited by the gui:
15 17 * * * /usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime --debug backup-job >> /home/tim/bit.log 2>&1
# Temporary comment to ensure a newline after backintime
For whatever reason this did write to /home/tim/bit.log
:
Back In Time
Version: 1.5.1
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.
I added the --debug
flag a few minutes ago to try to get something more useful to go off of; you can see the pastebin result here:
$ journalctl -S '2024-08-04 17:15:00' --identifier backintime | curl -F 'file=@-' 0x0.st
http://0x0.st/XOCh.txt
Which indicates that there was a permission error trying to run file_path.touch(mode=0o666)
on /run/lock/backintime.lock
; the permissions for /run/lock
on my computer are:
$ ls -hAld /run/lock
drwxr-xr-x 5 root root 100 Aug 3 21:00 /run/lock
And for comparison, when I run the backup command manually:
$ journalctl -S '2024-08-04 17:40:00' -U '2024-08-04 17:42:00' --identifier backintime | curl -F 'file=@-' 0x0.st
http://0x0.st/XVrZ.txt
Which indicates that since /run/lock
is not writable, it attempts to create a lock at /run/user/1000/backintime.lock
, which succeeds. That, and nothing is written to /home/tim/bit.log
for whatever reason, though my file editor indicated that the file was modified, so I guess it wrote 0 bytes?
Checking the code, it got /run/user/1000
from XDG_RUNTIME_DIR
, and running a quick script through cron tells me that env var isn't set in cron's environment for whatever reason, likely causing an unhandled exception at common/flock.py:91
because that line uses dict[key]
notation instead of dict.get(key, default)
notation like the others. This would explain why there are no log messages past this point when run through cron. As for why that variable isn't set in cron - no idea. Now, if that were to also fail to create a lock file, I noticed that XDG_CACHE_HOME
is not set in cron nor in my graphical environment, also no idea why, so at that point I imagine I would get an error about being unable to create a lock file. For now I'll prefix backintime's crontab command with env XDG_RUNTIME_DIR=/run/user/1000
to get around this issue.
graysky commented on 2024-08-04 20:02 (UTC)
1.5.1-1 is working for me with cronie. If it is not for you check that you have cronie.service
enabled and that it is running. Also look in the output of crontab -l
which should show a line created by backintime.
NickNackGus commented on 2024-08-04 18:31 (UTC)
Using journalctl --identifier backintime
correctly shows the status of various backups. The last one to run at a scheduled time was the 26th, and everything after that was started manually at some arbitrary time in the day.
I found these two lines right next to each other in journalctl
with no output to bit.log
, even with a comment on the line after backintime's entry to ensure it would run, and no information in the log in the Back In Time graphical application for today:
Aug 04 13:55:00 Tim-Desktop-5 CROND[164528]: (tim) CMD (/usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >> /home/tim/bit.log 2>&1)
Aug 04 13:55:00 Tim-Desktop-5 CROND[164524]: (tim) CMDEND (/usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >> /home/tim/bit.log 2>&1)
However, if I run /usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >> /home/tim/bit.log 2>&1
in a terminal within my desktop environment, while it still returns immediately with no output to bit.log
, it does start the backup process and the graphical application confirms that the backup has started.
As noted earlier, if I add echo test >> /home/tim/test.log
to the same crontab, that does update correctly, and cronie hasn't updated since April - but backintime updated around the right time to affect my next scheduled backup (1.5.0). Perhaps there's some environmental difference between what cronie does and running in a normal terminal, like env vars? I'm not sure what could be different enough between the two to prevent all output, though.
buhtz commented on 2024-08-04 10:30 (UTC)
I fixed the missing newline behavior: https://github.com/bit-team/backintime/pull/1827
But still not sure what it is. Can you check your cronie please. Does it throw an error when there is no newline at the end of the file?
buhtz commented on 2024-08-04 09:48 (UTC) (edited on 2024-08-04 09:52 (UTC) by buhtz)
Did you used the following command to read the syslog? "journalctl --identifier backintime"?
Never used "cronie" but to my knowledge it is compatible to Vixie Cron. But maybe we hit an edge case here. I suggest you to contact the cronie community and ask for advise.
It is still not clear for me if cronie do not run BIT or if BIT is run but something fails.
Can you please add this at the end of the BIT crontab line: ">> /home/user/bit.log 2>&1" It should redirect every output into a file. So we can see if BIT runs and if it throws any error.
And maybe a simple "grep -i "cron" /var/log/syslog"
Pinned Comments
graysky commented on 2023-10-07 12:15 (UTC)
Using an AUR helper such as yay to build packages including backintime is HIGHLY discouraged. The recommended build method is to use a clean chroot. See: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot
I wrote a script that automates much of that called clean-chroot-manager offered here in the AUR.
Please stop posting build failures because you insist on building with yay or other AUR helpers.