Behavior when running via "sudo -E" (was: Scheduled backups stopped working when configured as root) #1683
Comments
|
Thanks for reporting. Not sure what is going on. But your output indicates that BIT can not find a config. |
|
It appears there's a disconnect between the UI and the config files. Running as root requires a config file in |
emtiu
added
Distro-Specific
|
I still try to understand the problem and what you have done.
Do you mean that you start the BIT GUI as root but the configuration is stored in |
buhtz
added
the
Feedback
|
As of late April, I had to switch to a different backup solution. But ultimately I had used BiT for probably close to a decade with largely the same setup and configuration until it just stopped working. Because of this, my memory is a little fuzzy, but I have kept the package up to date. I believe what was happening is that any changes I made via the graphical interface when running via I did just try to run a scheduled backup and it failed still. The output of that event is below. I'm happy to take any instructions to see if it can be resolved, but I understand if it's maybe too specific to my setup to be worth the time. |
|
Thank you very much for reporting back. This does help. I am assuming this is related to the way you start BIT. I will investigate this. |
buhtz
added
Discussion
|
No worries. Just for what it's worth, and I think this is in another issue somewhere, if I try to start via the polkit launcher, I get this - It does prompt for my password if I run it without sudo, but both will result in that output... Which is why I have to run with |
|
When I run bit via sudo: It is clear that that BIT running via sudo will give you a warning and will still use the users config file. That behavior is intended because sudo is not root but the current user with root permissions. I see no bug. The only thing I see to change should be a more impressive warning/error message in the GUI about the situation. Any other suggestions? |
buhtz
changed the title
|
I guess with the elevated root permissions it used to work, but you're right in how it works now would be more correct. But in the end, the fact that backups fail to run, there's still an issue. It might be that I was going down the wrong path, but I still get errors when trying to let cron handle backups. There's nothing special to it. I've even reset it and tried a clean configuration. But ultimately, when I switched to wayland, things started to fail. I'll close this now as it must just be a very specific user case that causes this. |
|
Actually, it is working now that I waited long enough. I just assumed it was still broken because the GUI doesn't show activity anymore. It used to show a preview of files being backed up in the bottom and since that isn't happening, I assumed it was erroring out. |
output of the console command backintime --diagnostics
Version: backintime-git from the AUR built in clean chroot
Scheduled backups have stopped working when configuring BiT as root. I've read that it's not the recommended method, but the polkit option doesn't work with Wayland and there are some critical files that I like to back up from various directories like
/etcand/varthat a regular user can't touch. I've tried the every 5 minutes, anacron and custom hours (the latter being what I've always used) and the result is always the same -journal output after scheduled backup attempt.
I have tried creating alternate profiles and verified that rsync itself initiated by cron does work as I have a single rsync command running daily for another backup.
Running BiT via
sudo -E backintime-qtallows for manual snapshots under the same profile that failed when executed from the cronjob.Here's the cron as it is created by BiT -
The text was updated successfully, but these errors were encountered: