Admin remote ftp backup cron jobs not working!

zEitEr said:
Hello,

Make sure crond is installed and running:

Code: 
# rpm -qa | grep cron
crontabs-1.11-6.20121102git.el7.noarch
cronie-anacron-1.4.11-24.el7_9.x86_64
cronie-1.4.11-24.el7_9.x86_64

Code: 
# systemctl status crond
● crond.service - Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2022-11-13 21:34:21 +07; 5 days ago
 Main PID: 646 (crond)
   CGroup: /system.slice/crond.service
           └─646 /usr/sbin/crond -n
Click to expand...
hi, i have this issue and I m on ubuntu and crond is not running on my system, how can i get it going ?
 
Richard G said:
Try this.
sudo apt-get update sudeo apt-install cron
Click to expand...
forgot to mention, I get the msg that already installed when i try to install cron

"cron is already the newest version (3.0pl1-136ubuntu1)."

and when I check the status of "cornd", it says not found

but when i check status of "service corn status".

it says inactive in last 2 weeks
 
restarting cron didnt give any error, how do I check if its running properly now? my cron page on Directadmin is empty for all users
 
systemctl enable cron
will add it to autostart at reboot.
 
Last edited:
I have exactly the same problem. Since November, none of the dozen or so servers has been backed up. There is no trace of the execution attempt in the logs.
Directadm, what have you changed and why can't you fix it?
 
cURL changed to the one installed from a system repository? Directadmin dropped installation of cURL in favor of using a system one.
 
zEitEr said:
cURL changed to the one installed from a system repository? Directadmin dropped installation of cURL in favor of using a system one.
Click to expand...
I didn't change anything myself. Can you send a link to a manual?

PS. Manual backup works fine.
 
I don't know which manual you want. You might search here https://docs.directadmin.com/ and here https://docs.directadmin.com/changelog/

That was my guess about cURL, if manual backups works fine, then you either investigate the issue or get someone to do for you. If you want to investigate the issue by yourself, you might follow instructions and steps already posted in this thread and another similar threads.

I don't have exact steps on how to fix the issue. That's probably because I've never had a server with the same issue for an investigation.
 
I checked the changelog and the only cron entry is:

CustomBuild cronjob is dropped from using cron service and is now being handled and run by main DirectAdmin binary instead.
Click to expand...

but it shouldn't affect backups.

In the posts above, the "cron" service is mentioned all the time, I have "crond" everywhere, but it probably shouldn't affect the operation of the task scheduler either.

Another option I was considering is that Version 1.645 (which I'm using) has a bug, but again I don't see anything being fixed in the next version...
 
I don't have the issue on my end, neither my servers nor servers of my customers have the issue. The thread contains my suggestions on investigation, and different users checked them. I don't have other ideas as of now. Probably somebody else has.

If you are sure, directadmin has a bug, you might open a ticket with DirectAdmin support and let them investigate the issue)))
 
zEitEr said:
If you are sure, directadmin has a bug, you might open a ticket with DirectAdmin support and let them investigate the issue)))
Click to expand...
I'm sure it's a bug because everything broke after the update. In addition, in the cron logs you can see that the task is running (it is transferred to task.q):
Feb 28 10:35:01 CROND[3519725]: (diradmin) CMD (echo "action=backup&id=1&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 / usr/local/directadmin/data/task.q
Click to expand...
However, there is no trace of it in the DA logs (although the task.queue.da file immediately disappears).
The problem with reporting a bug is that we have a perpetual license, no support ;)
 
They do not respond to technical requests if you do not have purchased support.
 
erick85 said:
I'm sure it's a bug because everything broke after the update. In addition, in the cron logs you can see that the task is running (it is transferred to task.q):
Click to expand...


A difference between manual run of backups and a run with a cron, is who set a task in /usr/local/directadmin/data/task.queue.da. In the first case DirectAdmin adds a line in the file reacting your click in DirectAdmin web-interface, in the second case it's a crontask adding the line in the file.

The backend of processing the task.queue.da file is the same in both cases. I guess you know how to check whether your cron completes the task and adds the needed line in the file. So you might check the file and run /usr/local/directadmin/dataskq d800

If it was not mentioned in the ticket yet, the you might try and re-save your task. Just click to edit it in DirectAdmin and save it. Probably it will fix the issue. Just another guess.
 
I'm getting closer thanks to your advice. A manual run creates a task.queue file with ID = 31:
action=backup&id=%31&owner=admin&value=
Click to expand...
while the crontab -u diradmin -l command and the backup_crons.list file contain ID = 1:
08 11 * * * echo "action=backup&id=1&owner=admin"...
Click to expand...
Why this discrepancy? I have already modified the task many times (after all, I change the execution hours every now and then).
 
You must log in or register to reply here.
Back
Top