Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cronjob failing due to missing PATH #10

Closed
rantanlan opened this issue Mar 6, 2021 · 3 comments
Closed

Cronjob failing due to missing PATH #10

rantanlan opened this issue Mar 6, 2021 · 3 comments
Assignees
Labels
enhancement New feature or request fixed This issue has been resolved

Comments

@rantanlan
Copy link

rantanlan commented Mar 6, 2021

Sorry, me again. Just checked today if my cronjob was running last night and found ou it did not.
Little debugging later the cronjob throws a ERROR: BORG is not installed on this system!

Any idea how that could be? borg is installed as binary in /usr/local/bin and executed fine manually.
The if ! command -v borg statement looks fine for me, must have to do something with the context in which crontab jobs are started!?

Edit: Looks like my crontab env is different and is missing the PATH. I just added the PATH variable to the crontab file maybe as a feature request to minimize this issue for other, specify a location for borg in the details file?

@rantanlan rantanlan changed the title Cronjob failing Cronjob failing due to missing PATH Mar 6, 2021
@asifbacchus
Copy link
Owner

It seems pretty common for many programs to expect the user to alter their cron path manually as needed. Also, the borg documentation specifically suggests installing/symlinking to /usr/bin/borg so that it can be found by all systems.

However, it is not a difficult change to make to the script directly to detect the path and use it. I think that's easier and better than assuming the user can find the right path and add it to the details file. Plus, you're probably right, it should be using full paths wherever possible since it's designed to run in a cron environment. I'll add it to my weekend-workflow and hopefully have the change pushed before Monday.

Cheers. Glad you got the path thing figured out, btw. I forgot about it in the documentation since I'm used to just updating my crontab paths -- nice catch :-)

@asifbacchus asifbacchus self-assigned this Mar 7, 2021
@asifbacchus asifbacchus added the enhancement New feature or request label Mar 7, 2021
asifbacchus added a commit that referenced this issue Mar 8, 2021
- parameter to specify non-default borg program location

Closes github #10
@rantanlan
Copy link
Author

thanks for considering. I must have missed that in the borg documenation and never stunbled over that crontab issue. But I'll guess you learn something new every day :)

@asifbacchus
Copy link
Owner

I decided to go with a command-line parameter instead of auto-detecting in the script or a variable in the details file. Here's my reasoning:

  • borg should be installed with a symlink to /usr/bin/borg (and really /usr/bin/borgfs for compatibility) as per the program documentation. If it is installed in that location, it should be in the path for most systems' cronjobs.
  • putting it in the details file I feel would be confusing to some users. The packaged installation and those following the direct-install instructions in the documentation would be installing to the default location anyways, so having this in the details file might make people think they need to install a separate version or something. I'm not sure about this confusion, but it was suggested to me as a possible problem by a few other people I talked to.
  • I considered having the script just 'find' borg. But then I thought about people with very large file systems and the fact that even on NVMe/SSD drives a full disk search can eat time. That could be annoying if you (like me) run a backup every few hours instead of just once a day or something.

I'm closing this for now, but if you disagree with this choice, please let me know and I'll take it under consideration. Obviously, I value your opinion since this was on your suggestion anyways so I feel free to speak up if you want :-) Just re-open the issue if you like.

For reference, this change is implemented in Version 3.5

@asifbacchus asifbacchus added the fixed This issue has been resolved label Mar 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fixed This issue has been resolved
Projects
None yet
Development

No branches or pull requests

2 participants