Admin Backups / Crons dont work in AL9.2

[Yoshua]

I think that few clients use AlmaLinux 9 with Directadmin, we are going for version 9.2 and still basic things of Directadmin continue to fail even though they say that it is supported.



When creating backup programs, from admin, the saved schedule message does not appear and the scheduled time is not executed, but if a backup schedule is manually executed, it does work. In the directadmin error log we see the following message:

2023:06:25-02:58:07: generateCrontab: Bad file descriptor

If we create manually the "diradmin" cron file in "/var/spool/cron/" with:

0 0 * * * umask 0077; echo "action=backup&id=1" >> '/usr/local/directadmin/data/task.queue.da'
0 12 * * * umask 0077; echo "action=backup&id=2" >> '/usr/local/directadmin/data/task.queue.da'

does not run correctly either and we can see that the file it creates in "/usr/local/directadmin/data/task.queue.da" does so with an incorrect format:

 

[Yoshua]

As expected, when Directadmin touches something, it stops working. As soon as I saw that in 1.650 there were changes in the management of scheduled backups, was there a 99% chance that the problem was the fault of that improvement? ? We have changed the update channel of the current line to the stable one (1.649) and after downgrading and restarting Directadmin, the scheduled backups have started working again and the mentioned error no longer appears.

No comment!

 

[fln]

hi @Yoshua, I think this problem affects only your server. Backups triggered by crontab stores these tasks into dataskq task file. Default location of this file is /usr/local/directadmin/data/task.queue.da. It is configurable in directadmin.conf file. Based on the file name you have reported it seems you are not using default file location but have customized malformed entry which has extra carriage-return symbol at the end of it (\r).

Starting DA 1.650 performs strict file name escaping. This means it will accurately use the file name configured in directadmin.conf even if it contains spaces or other white-space symbols.

If this hypothesis is correct I would recommend removing the customized taskqueueda=/usr/local/directadmin/data/task.queue.da line from directadmin.conf. My guess would be that whole file was modified on windows systems and got stray carriage-return symbols appended to all the values which could lead to other things not working as expected.

TL;DR - it is caused by malformed directadmin.conf file, and it has nothing to do with AlmaLinux 9.

 

[fln]

If the file with surplus \r symbol is created not by DA but by your manual attempt of creating a crontab file then issue is somewhere else. Feel free to open a support ticket, this would give us a chance to get access to a server and verify it.

 

[Yoshua]

Hi, thanks for answering, the server is new (less than a month), the only directadmin.conf customization is "one_click_*", it has no special characters and the encoding is correct. The file "/usr/local/directadmin/data/task.queue.da" is not created badly after downgrading to 1649. What I don't understand is that it doesn't work with version 1.650, just downgrading to 1.649 already works correctly and the fault lies with "our server".



Again, thanks @fln for responding.

 

[Yoshua]

If the file with surplus \r symbol is created not by DA but by your manual attempt of creating a crontab file then issue is somewhere else. Feel free to open a support ticket, this would give us a chance to get access to a server and verify it.

I guess what you mean by this , but in this new server, the customization mentioned in the other thread has not been done, since DA does not allow creating hourly backups on the same schedule, we resort to creating different separate schedules for multiple backups on the same day, but these programs are created from directadmin itself without customizing anything or editing any file.

However, the first error, the one that occurs when the scheduled backup is created or edited from Directadmin (generateCrontab: Bad file descriptor) when we use version 1.650, I think is the starting point to find the cause.

Thank you.

 

[fln]

If there are no issues with directadmin.conf then my hypothesis is not correct. Would be great to get access to the server to investigate it further. Easiest way to get it is with our ticketing system at https://tickets.directadmin.com.

With each update we are making DirectAdmin more strict and more reliable, which unfortunately breaks stuff when systems rely on some unwanted behaviour that we want to eliminate. Of course if something stopped working after and upgrade it looks like the fault lies on new DA version, but more often than not it means we have revealed some deeper unrelated problem which would have resurfaced sooner or later.

For example previous DA versions could lead to backups crontab to get desynced from main backup config and lead to some backup tasks not being run at all. After upgrade when we ensured all configured backups are being run we got report that excessive backups are being created . While DA did fix the problem of ensuring all backups tasks are run, for this particular user it was a new problem - since he long forgotten the configured but non functional backup task and was happy it is not running. So fixing a bug in DA could be treated as a new bug for some people who liked or relied on the buggy behaviour.

 

[netsolid]

We have the same problem with a new install. Is there a solution for this problem? Never mind, the solution is in this thread. We changed to stable and it works.

 

[fln]

@Yoshua thanks for reporting and @netsolid thanks for confirming it. We found a way to reproduce it and released a fix for it in current release channel.