Cron Daemon - Error reseller backup
- Thread starter fossie
- Start date
- Joined
- Feb 27, 2003
- Messages
- 8,437
Hello,
1) The task.queue.da is a valid file. The reason we use it is because it will only have the "diradmin" user permssion on it. The task.queue can have root, thus any diradmin processes wouldn't be able to write to it, thus we created a second file for diradmin related things, like diradmin cronjobs.
2) The missing task.queue.da file is actually normal. The reason the chmod cannot see it is because the cronjob is run exactly on the minute. The dataskq is also run exactly on the minute, so the task.queue.da file is create at the same moment the dataskq runs.. the dataskq then reads it, renames it to task.queue.da.tmp to process it. Then a fraction of a second later the chmod happens. We do the chmod for the case that the dataskq didn't see it right away, so that we're sure that it's not chmod to a world readable value. This ensure the file is either deleted/renamed instantly by the dataskq, or chmod to 600, so that the world can't see it. Either way, it's secure. I could move the diradmin cronjobs to be run at 30 seconds by starting off the echo with a "sleep 30;", so that it only ever happens one way.
John
1) The task.queue.da is a valid file. The reason we use it is because it will only have the "diradmin" user permssion on it. The task.queue can have root, thus any diradmin processes wouldn't be able to write to it, thus we created a second file for diradmin related things, like diradmin cronjobs.
2) The missing task.queue.da file is actually normal. The reason the chmod cannot see it is because the cronjob is run exactly on the minute. The dataskq is also run exactly on the minute, so the task.queue.da file is create at the same moment the dataskq runs.. the dataskq then reads it, renames it to task.queue.da.tmp to process it. Then a fraction of a second later the chmod happens. We do the chmod for the case that the dataskq didn't see it right away, so that we're sure that it's not chmod to a world readable value. This ensure the file is either deleted/renamed instantly by the dataskq, or chmod to 600, so that the world can't see it. Either way, it's secure. I could move the diradmin cronjobs to be run at 30 seconds by starting off the echo with a "sleep 30;", so that it only ever happens one way.
John
Can I try that solution? Is there some setting I can change before you put it in a release?
I do like the idea about a file being safe if it is or isn't processed.
The thing is that the backups aren't create the times I recieve this error. If the error isn't sent, the backups are created the normal way.
So maybe there is another reason why the cron fails;
but I can't see this in the logs.
The file is written (if it's written, I can't check), but the cron log stats that the command is issued.
Some other ideas?
I do like the idea about a file being safe if it is or isn't processed.
The thing is that the backups aren't create the times I recieve this error. If the error isn't sent, the backups are created the normal way.
So maybe there is another reason why the cron fails;
but I can't see this in the logs.
The file is written (if it's written, I can't check), but the cron log stats that the command is issued.
Some other ideas?
Yes, I understand what you've told me, but
- I can change this in the /var/spool ... manually (did change it and it worked)
- But I can't change it at the reseller page (Manage user backups), is there a template file where I can change it?
Today another cron errer, like yesterday and... the day before. Once in a while it's processed, but I can't see when or why.
Fossie
- I can change this in the /var/spool ... manually (did change it and it worked)
- But I can't change it at the reseller page (Manage user backups), is there a template file where I can change it?
Today another cron errer, like yesterday and... the day before. Once in a while it's processed, but I can't see when or why.
Fossie