Arch Linux User Repository

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.

@buhtz - yes, 1.5.3-rc1 builds cleanly with this PKGBUILD

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.

https://github.com/bit-team/backintime/issues/1911

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.

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.

Scheduled backups are working for me with Cronie 1.7.2-1 and BackInTime 1.5.1-1.

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.

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.

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.

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?

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"