backintime
backintime copied to clipboard
Support for fcrontab
Please add support for fcrontab, one of the cron alternatives.
One issue when fcrontab is installed is that you cannot create configuration file ~/.config/backintime/config from the GUI. BIT fails with a dialog message: "Can't find crontab.\nAre you sure cron is installed ?\nIf not you should disable all automatic backups."
A solution is to try to call fcrontab if crontab cannot be found.
I have tested this by changing files:
- common/config.py
- common/test/test_tools.py
- common/tools.py
-
Changed calls to crontab into calls to fcrontab
-
Ignored stderr output in common/tools.py by changing:
out, err = proc.communicate()
if proc.returncode or err:
into:
out, err = proc.communicate()
if proc.returncode:
Please fix this.
Here's the backintime output when trying to use fcrontab:
ERROR: Failed to get crontab lines: 0, 2016-08-24 17:24:22 INFO listing wschlich's fcrontab
2016-08-24 17:24:22 INFO user wschlich has no fcrontab.
ERROR: Failed to write lines to crontab: 0, 2016-08-24 17:24:22 INFO installing file /tmp/tmp1nql0kvx for user wschlich
2016-08-24 17:24:22 INFO wschlich's fcrontab contains no entries : removed.
Modifications will be taken into account at 17:25.
Afterwards, my user crontab looks like this:
[wschlich@zephyr(pts/3):~]$ crontab -l
2016-08-24 17:25:17 INFO listing wschlich's fcrontab
#Back In Time system entry, this will be edited by the gui:
#Please don't delete these two lines, or all custom backintime entries are going to be deleted next time you call the gui options!
[wschlich@zephyr(pts/3):~]$
Yes please, without crontab i can't even save the configured profile. I'm trying to link /bin/true to /bin/crontab to trick it... EDIT Did that:
#cat /usr/bin/crontab:
#!/bin/bash
echo "$@" >/tmp/crontab.out.txt
cat "$@" >>/tmp/crontab.out.txt
so that i have the command to execute
To anybody having problems to upgrade to 1.3.0 and used my bad hack, remove it and try again or the install will fail in the tests.
fcrontab seems to be rather common, so this should have some priority.
The code need to be re-designed to better encapsulate the used scheduling technic. After that we can have modules for Vixie Cron, fcron, cronie (Debian will migrate to it in the future), systemd based scheduling, etc.
So it is a big job.
I have also issues with fcron. I'm on gentoo with BiT 1.3.3. The symlink /usr/bin/crontab -> fcrontab is automaticly created when installing BiT. I run BiT as root (backintime-qt_polkit)
The output from crontab looks like this:
gentoo ~ # crontab -l
2024-01-02 21:36:05 INFO listing root's fcrontab
15 * * * * touch ~/cron_hourly
Running BiT, I get the same error as wschlich when opening the settings dialog:
ERROR: [common/tools.py:1403 readCrontab] Failed to get crontab lines: 0, 2024-01-01 17:54:33 INFO listing root's fcrontab
Note that the returncode is 0, but the err contains "2024-01-02 20:35:02 INFO listing root's fcrontab". So for some reason fcron is directing the INFO line to stderr:
gentoo ~ # crontab -l > crontab.stdout 2> crontab.stderr
gentoo ~ # cat crontab.stdout
15 * * * * touch ~/cron_hourly
gentoo ~ # cat crontab.stderr
2024-01-02 21:39:33 INFO listing root's fcrontab
This causes BiT to handle it as an error and the actual line from stdout is not returned from readCrontab().
Then when you close the settings dialog by clicking OK, the writeCrontab(lines) function writes the new crontab without anything in lines, and thus the complete crontab is wiped out and only the new lines from BiT are written.
Then it also gives the same error because again the INFO directed to stderr, and you can't save your settings:
ERROR: [common/tools.py:1443 writeCrontab] Failed to write lines to crontab: 0, 2024-01-01 17:54:33 INFO installing file /tmp/tmpanrocdpp for user root
As a work around I removed the "or err" from the readCrontab() and writeCrontab(lines) function:
gentoo ~ # diff /usr/share/backintime/common/tools.py tmp/backintime-1.3.3/common/tools.py
1402c1402
< if proc.returncode:
---
> if proc.returncode or err:
1442c1442
< if proc.returncode:
---
> if proc.returncode or err:
But maybe there is a better way to handle this. It would be nice to get a confirmation before writing the new crontab, because now everything is wiped out without warning. Also when the schedule is disabled, it could be completely skipped.