Admin remote ftp backup cron jobs not working!

[zEitEr]

The %31 is still 1. That's urldecode/urlencode in effect. Try it here: https://www.urldecoder.org

 

[erick85]

Yes, I just wanted to write this...

 

[erick85]

But I found one more difference and it is possible that this is where the problem lies. Well, manually running the backup creates a task.queue file, while cron creates a task.queue.da file.

 

[zEitEr]

And will it work if you modify crontasks to use a task.queue file?

 

[zEitEr]

I have these tasks working fine on my server:

0 1 * * 7  echo "action=backup&id=1&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da
0 2 * * *  echo "action=backup&id=2&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da
0 3 * * *  echo "action=backup&id=3&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da
0 4 * * *  echo "action=backup&id=4&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da

with /usr/local/directadmin/data/task.queue.da

 

[erick85]

I have these tasks working fine on my server:

My crontab looks the same.

And will it work if you modify crontasks to use a task.queue file?

No, manually renaming the file (via crontab -u diradmin -e) does not solve the problem, the backup still does not take place.
It's terribly frustrating, but it seems that the easiest way is to... create a cron job: create file /usr/local/directadmin/data/task.queue with the content: action=backup&id=%31&owner=admin&value= - which is exactly what happens when you start it manually. It should work... until the next update.

 

[zEitEr]

It's terribly frustrating

Yes, it is. Probably something is still behind the scope. A kind of a tunnel vision is probably in an effect. That's why I'd like to test a server and investigate it by myself. All obvious things are already tested, so we need to do a deep debugging. Not even sure that we would find anything yet.

 

[erick85]

When I manually enter the command via SSH:

echo "action=backup&id=1&owner=admin" >> /usr/local/directadmin/data/task.queue; /bin/chmod 600 /usr/local/directadmin/data/task.queue

This backup will be done. But the same cron command doesn't run the backup anymore (although the file is deleted as soon as it's created). I thought it might be an "echo" path/permissions issue, but adding /usr/bin/ doesn't help (and chmod is 755). But still, the problem is probably somewhere in the command itself, because I changed it so that a test file is created and even though cron is executing:

Feb 28 11:49:01 CROND[3685539]: (diradmin) CMD (/usr/bin/echo "action=backup&id=1&owner=admin" >> /usr/local/directadmin/data/test; /bin/chmod 600 /usr/local/directadmin/data/test)

then the test file is not in this location. Very strange... unless DA removes all unnecessary files.

 

[erick85]

DA doesn't delete unnecessary files. So why doesn't cron create this file then? This explains the lack of a trace in the DA logs.

 

[erick85]

Yes, it is.

Jesus, the solution was at the beginning of the thread, but I didn't use it because someone wrote that it didn't help. It's a question of permissions! The November update set the owner of the directadmin and data folder to "root", when it should be "diradmin" - hence the lack of cron privileges to create files. Thank you @zEitEr for your time and guidance to the cause!

 

[dataonline.vn]

And what will you see if you run as root the following commands?

echo "action=backup&id=4&owner=admin" >> /usr/local/directadmin/data/task.queue.da;
/usr/local/directadmin/dataskq d800

it's working for me. but few day later => get error