Skip to main content
cPanel Technical Support has been heavily impacted by hurricane Beryl and our ability to respond to tickets has been hindered as a result. We appreciate your understanding and patience as we address these delays.

pkgacct via cron doesn't appear to run

Comments

9 comments

  • cPRex Jurassic Moderator
    Hey there! Are you trying to create that cron as a cPanel user or under the root user? Under a standard cPanel installation, users would not have access to pkgacct. The cron output looks like this is under root, but I just wanted to confirm. On my personal server I was able to create a cron under root like this: * * * * * /usr/local/cpanel/scripts/pkgacct username and I confirmed it did run as expected. It's important to note that pkgacct will not create multiple files, but will overwrite any existing /home/cpmove-username.tar.gz files it finds, so you won't get multiple copies if that is what you are expecting to happen.
    0
  • competitions
    Thanks cPRex I believe it's root via terminal in WHM: [root@example ~]# su - Last login: Fri Jul 9 21:39:47 AEST 2021 from 103.xxx.xxx.xx on pts/0 [root@example ~]# crontab -e crontab: installing new crontab [root@example ~]# Extract from crontab: 09,39 * * * * /usr/local/cpanel/scripts/clean_user_php_sessions > /dev/null 2>&1 7 16 * * * /usr/local/cpanel/scripts/pkgacct example Directory listing after cronjob pkgacct should have run: [root@example home]# ls -l total 144 -rw-r--r-- 1 root root 530 Jun 29 18:00 0_README_BEFORE_DELETING_VIRTFS drwxr-xr-x 2 root root 4096 Jun 29 18:00 cPanelInstall -rw------- 1 root root 78384 Jul 10 16:04 cpmove-example100721.tar.gz (this is a copied file after manually running pkgacct via command line, then removed cpmove-example.tar.gz just to ensure an existing same file name doesn't interfere with crontab created file ) drwx--x--x 13 example example 4096 Jul 5 19:53 example -rw-r--r-- 1 root root 44226 Jun 29 17:54 latest drwx--x--x 3 root root 4096 Jun 29 18:00 virtfs The long game for this is to compare using pkgacct versus WHM Backup -> Additional Destinations. Ideally I want to have a backup server running WHM already configured to match the production server and in the scenario of the production server crashing, importing the relevant account backup into the backup server. Hopefully using whichever is easiest and fastest to import, assuming the file is already on the backup server. From what I've read, pkgacct appears to be quicker to import an account (once it's on the server) as it's designed for an account move, the downside is no existing scripts to rotate backups/dates and no scripts to copy from one server to another. WHM Backup -> Additional Destinations has the backup/dates rotation sorted and scripts exist to copy to multiple option servers. I have chosen only one account to be backed up. Downside of WHM Backup -> Additional Destinations appears to be perhaps need to unpack the backup file on the backup server before importing the account? I supposed while I'm trying to get pkgacct working via cron, I should reconfigure WHM Backup -> Additional Destinations to the backup server and see what the file looks like once it's copied there and then see how to import the account.
    0
  • competitions
    Well this is odd. It appears pkgacct has run, but at a completely different time to the cron job: -rw------- 1 root root 81831 Jul 12 02:07 cpmove-example.tar.gz It's done this at the same time for three days, even when I change the cronjob time - which appears to have no effect. Server time is correct, no crons in the actual cPanel account.
    0
  • competitions
    Using WHM Backup -> Additional Destinations to a remote WHM server and then doing a Backup Restoration onto the remote server doesn't work. No matter if the backup file is in root or /home [as per Restore a Full Backup/cpmove File | cPanel & WHM Documentation], the restore function doesn't see the tar file. The workaround is: To restore onto the remote server, delete the account from the account listing in WHM, then copy the latest backup, eg: cp root/2021-07-12/accounts/example.tar /backup/2021-07-12/accounts/example.tar Then in WHM Backup Restoration, choose the account and date and restore.
    0
  • cPRex Jurassic Moderator
    Let's try and keep the thread focused on one issue for now so things don't get too confusing. For the cron job time, can you see what time the job was triggered in /var/log/cron? It's possible this ran at the correct time and then just didn't finish until the timestamp you are seeing.
    0
  • competitions
    Let's try and keep the thread focused on one issue for now so things don't get too confusing. For the cron job time, can you see what time the job was triggered in /var/log/cron? It's possible this ran at the correct time and then just didn't finish until the timestamp you are seeing.

    crontab: 7 16 * * * /usr/local/cpanel/scripts/pkgacct example grep pkgacct /var/log/cron Jul 11 16:07:02 example CROND[18473]: (root) CMD (/usr/local/cpanel/scripts/pkgacct example) (doesn't appear to have run today - it's way past Jul 12 16:07 AEST time zone here) [root@example home]# ls -l -rw------- 1 root root 81831 Jul 12 02:07 cpmove-example.tar.gz While server time appears correct, I'm going to change the cron to 17 6 * * * /usr/local/cpanel/scripts/pkgacct example reboot the server in case there's a time issue and report back tomorrow (if the cPanel trial licence on the remote server hasn't expired overnight :) )
    0
  • cPRex Jurassic Moderator
    That sounds good - let me know what you find!
    0
  • competitions
    Who says Unixy boxes don't need reboots? :) It's 9:45 AM here. Crontab as expected shows 17 6 * * * /usr/local/cpanel/scripts/pkgacct example grep pkgacct /var/log/cron shows Jul 11 16:07:02 example CROND[18473]: (root) CMD (/usr/local/cpanel/scripts/pkgacct example) Jul 13 06:17:01 example CROND[15277]: (root) CMD (/usr/local/cpanel/scripts/pkgacct example) [root@example home]# ls -l -rw------- 1 root root 83779 Jul 13 06:17 cpmove-example.tar.gz Looks correct to me. Remember to reboot for funky cron issues (or anyone that comes across this thread: maybe a service crond restart might suffice)
    0
  • cPRex Jurassic Moderator
    I'm glad that took care of the issue! Inside WHM >> Server Time we do have this warning: "To ensure consistency, we strongly recommend that you reboot the server after you change the time zone." so it can definitely lead to odd behavior with the system if that is changed and a reboot doesn't happen. I'm glad things are working well now.
    0

Please sign in to leave a comment.