You are not logged in.
Pages: 1
Hi, I would have a problem with the root of esxi hypervisor ver. 6.7.
I have documented both on the 33hops.com site guide, and on the internet but I could not solve it.
I start a priori that the cron of esxi root is started, and
I tested it working putting in the file / var / spool / cron / crontabs / root, this line of text * / 1 * * * * echo "$ (date)" >> /tmp/my-cron-test.txt.
By launching this other comado from another SSH window, tail -f /tmp/my-cron-test.txt, and every minute it updates.
Ultimately I can not get the job to esxibackup, I gave all the permissions, as explained the guide, but I could not solve the problem.
If someone has found themselves in my case, I ask you for help.
Thank you
Offline
I'm sorry that you are having dificulties with this, you are almost there. Your cron is working and your backup job is working too.
Unfortunately, we cannot offer you to find the problem for you, but the rest of users uses the cron, it's a bit picky if you are not used to debug Linux systems and you get nervous and launch multiple instances. Try to find somebody that can debug for you.
Offline
I had and still have the same issue as you. Unfortunately I'm still unable to identify the problem. Cron works but I cannot fire the job.
Offline
Hi Hyrules, I have tried all the documentation found on the Internet, but it is more than a month and a half that I can not find a solution. Administrator told me to find someone who would help me to find Linux debugging. I did not understand what he meant, I still try to solve, otherwise I leave it. I know this product from previous versions, but I did not have all these problems.
Offline
Hello:
We really would like to be able to connect to your systems and help you debugging your cases, but unfortunately we can't do that for everybody. Vincenzo has a working cron and a working backup job. Vincenzo, if you can fire any other script and you know your job script works, it should not be that difficult to find why the job does not fire.
[b]Tips:[/b] wrap it in another bash script that includes the shebang line: [b]#!/bin/sh[/b]
Then use the bash debug options (-x) to execute the wrapping script and see where it stops and why.
You can even do that adding the line to the job script.
Offline
I went with another backup application but here is an article that help me making the cron work : [url=https://apice.unibo.it/xwiki/bin/view/Apice/esxi6Scheduling]Job scheduling in (c)ESXi[/url] the trick is to have the rc.local.d have output the proper line in the cron file instead of having to modify it yourself. Do not edit the cron file by hand it seems that vmware does not like it and won't run your script. Have the local.sh in the rc.local.d echo your cron schedule in the root cron file and it will most likely work. You will need to reboot the server in order for that to happen. Just modify the local.sh file run auto-backup.sh and reboot. Mine is now working.
Last edited by Hyrules (2019-03-20 22:33:26)
Offline
XSIBackup provides the means to handle all this by using the [b][https://33hops.com/xsibackup-help-man-page.html#installcron]--install-cron[/url][/b] and [b][https://33hops.com/xsibackup-help-man-page.html#updatecron]--update-cron[/url][/b] arguments. We really don't know what you have been trying to do or why your cron wouldn't work.
Don't attribute human qualities to the OS, it can't want or like something, there isn't any malevolous spirit hanging around and keeping things from working. You can edit the cron just as long as you leave the file as it was before editing it, same permissions. Of course it's not persistent, that's why XSIBackup uses the --install-cron argument to move the cron logic to the init script.
Add [b]> /dev/null[/b] at the end of the cron line calling the XSIBackup job to redirect stdout to /dev/null and see if this helps.
0 2 * * * "/vmfs/volumes/datastore1/xsi-dir/jobs/001" > /dev/null # Added by XSIBackup
The crontab's default permissions are 1444:
Change them to 0700 to edit it with the root user
chmod 0700 /var/spool/cron/crontabs/root
And restore them back to 1444 afterwards, although leaving them as 0700 does not seem to be an issue on our test servers.
chmod 1444 /var/spool/cron/crontabs/root
Offline
Pages: 1