[Resolved] Automated backups not working correctly via cron (Linux-VServer)

[Daniel15]

Since about a month ago, the automated cPanel/WHM backups haven't been working correctly. They used to work perfectly, but suddenly stopped working one day. My set up is as follows:
Backup interval = Weekly
Backup retention = Weekly and Monthly
Days to run backup = Wednesday
Backup type = Remote FTP

In the "Configure cPanel Cron Times" plugin I have cpbackup set to run every day at midnight. If I run /scripts/cpbackup manually, it works and I get an email about the backup being successful. The only log file in /usr/local/cpanel/logs/cpbackup is the log from when I ran the backup manually.

Any ideas on how to diagnose this issue?

 

[Infopro]

In Configure cPanel Cron, what do you have for cpbackup exactly?

Could it be wrong there?

 

[Daniel15]

It's configured like this:

 

[cPanelDon]

Since about a month ago, the automated cPanel/WHM backups haven't been working correctly. They used to work perfectly, but suddenly stopped working one day. My set up is as follows:
Backup interval = Weekly
Backup retention = Weekly and Monthly
Days to run backup = Wednesday
Backup type = Remote FTP

In the "Configure cPanel Cron Times" plugin I have cpbackup set to run every day at midnight. If I run /scripts/cpbackup manually, it works and I get an email about the backup being successful. The only log file in /usr/local/cpanel/logs/cpbackup is the log from when I ran the backup manually.

Any ideas on how to diagnose this issue?

To more accurately diagnose the situation it will help to know some additional detail. Please let us know the output of the following commands, as entered via root SSH access:

# grep -H '' /usr/local/cpanel/version /var/cpanel/envtype
# cat /etc/cpbackup.conf

 

[Daniel15]

Thanks for your reply, cPanelDon. Here's the output of those commands:

root@quimby [/]# grep -H '' /usr/local/cpanel/version /var/cpanel/envtype
/usr/local/cpanel/version:11.26.8-CURRENT_48361
/var/cpanel/envtype:vserver
root@quimby [/]# cat /etc/cpbackup.conf
BACKUP2 yes
BACKUPACCTS yes
BACKUPCHECK yes
BACKUPDAYS 3
BACKUPDIR /backup
BACKUPENABLE yes
BACKUPFILES no
BACKUPFTPDIR
BACKUPFTPHOST ralph.youareaninja.com
BACKUPFTPPASSIVE yes
BACKUPFTPUSER backups
BACKUPINC no
BACKUPINT weekly
BACKUPLOGS no
BACKUPMOUNT no
BACKUPRETDAILY 0
BACKUPRETMONTHLY 1
BACKUPRETWEEKLY 1
BACKUPTYPE ftp
COMPRESSACCTS yes
DIEIFNOTMOUNTED no
GZIPRSYNCOPTS --rsyncable
MYSQLBACKUP accounts
root@quimby [/]#

 

[cPanelDon]

The cpbackup configuration appears normal; according to your configuration I believe that cpbackup should run each Wednesday assuming there is nothing that may interfere.

Please use the following command to see if cpbackup is being executed by cron; there should be log entries that mention /scripts/cpbackup:

# zgrep cpbackup /var/log/cron*

The following command will confirm the crontab entry that is setup, similar to what was seen in WebHost Manager via the Cron Config plug-in:

# crontab -l -u root | grep cpbackup

 

[Daniel15]

root@quimby [/]# zgrep cpbackup /var/log/cron*
/var/log/cron:2010-07-26T00:00:01.498240+10:00 quimby crond[21271]: (root) CMD (/scripts/cpbackup)
/var/log/cron.1:2010-07-19T00:00:01.881070+10:00 quimby crond[21961]: (root) CMD (/scripts/cpbackup)
/var/log/cron.1:2010-07-20T00:00:01.737961+10:00 quimby crond[29446]: (root) CMD (/scripts/cpbackup)
/var/log/cron.1:2010-07-21T00:00:01.060633+10:00 quimby crond[5057]: (root) CMD (/scripts/cpbackup)
/var/log/cron.1:2010-07-22T00:00:01.632585+10:00 quimby crond[3819]: (root) CMD (/scripts/cpbackup)
/var/log/cron.1:2010-07-23T00:00:01.884980+10:00 quimby crond[655]: (root) CMD (/scripts/cpbackup)
/var/log/cron.1:2010-07-24T00:00:01.512385+10:00 quimby crond[27713]: (root) CMD (/scripts/cpbackup)
/var/log/cron.1:2010-07-25T00:00:01.881696+10:00 quimby crond[23912]: (root) CMD (/scripts/cpbackup)
/var/log/cron.2:2010-07-12T00:00:01.508964+10:00 quimby crond[32092]: (root) CMD (/scripts/cpbackup)
/var/log/cron.2:2010-07-13T00:00:01.766116+10:00 quimby crond[27437]: (root) CMD (/scripts/cpbackup)
/var/log/cron.2:2010-07-14T00:00:01.980970+10:00 quimby crond[17221]: (root) CMD (/scripts/cpbackup)
/var/log/cron.2:2010-07-15T00:00:01.551515+10:00 quimby crond[19689]: (root) CMD (/scripts/cpbackup)
/var/log/cron.2:2010-07-16T00:00:01.624959+10:00 quimby crond[22189]: (root) CMD (/scripts/cpbackup)
/var/log/cron.2:2010-07-17T00:00:01.393738+10:00 quimby crond[28609]: (root) CMD (/scripts/cpbackup)
/var/log/cron.2:2010-07-18T00:00:01.860378+10:00 quimby crond[15206]: (root) CMD (/scripts/cpbackup)
/var/log/cron.3:2010-07-05T00:00:01.128481+10:00 quimby crond[21318]: (root) CMD (/scripts/cpbackup)
/var/log/cron.3:2010-07-06T00:00:01.327235+10:00 quimby crond[22165]: (root) CMD (/scripts/cpbackup)
/var/log/cron.3:2010-07-07T00:00:01.146342+10:00 quimby crond[18925]: (root) CMD (/scripts/cpbackup)
/var/log/cron.3:2010-07-08T00:00:01.933055+10:00 quimby crond[15052]: (root) CMD (/scripts/cpbackup)
/var/log/cron.3:2010-07-09T00:00:01.978167+10:00 quimby crond[21696]: (root) CMD (/scripts/cpbackup)
/var/log/cron.3:2010-07-10T00:00:01.571237+10:00 quimby crond[29030]: (root) CMD (/scripts/cpbackup)
/var/log/cron.3:2010-07-11T00:00:01.736376+10:00 quimby crond[3810]: (root) CMD (/scripts/cpbackup)
/var/log/cron.4:2010-06-28T00:00:01.632265+10:00 quimby crond[818]: (root) CMD (/scripts/cpbackup)
/var/log/cron.4:2010-06-29T00:00:01.048261+10:00 quimby crond[31473]: (root) CMD (/scripts/cpbackup)
/var/log/cron.4:2010-06-30T00:00:01.584439+10:00 quimby crond[26868]: (root) CMD (/scripts/cpbackup)
/var/log/cron.4:2010-07-01T00:00:01.677384+10:00 quimby crond[16894]: (root) CMD (/scripts/cpbackup)
/var/log/cron.4:2010-07-02T00:00:01.619161+10:00 quimby crond[15361]: (root) CMD (/scripts/cpbackup)
/var/log/cron.4:2010-07-03T00:00:01.076488+10:00 quimby crond[10540]: (root) CMD (/scripts/cpbackup)
/var/log/cron.4:2010-07-04T00:00:01.420931+10:00 quimby crond[17575]: (root) CMD (/scripts/cpbackup)
root@quimby [/]# crontab -l -u root | grep cpbackup
0 0 * * * /scripts/cpbackup

It stopped working at the end of July, and there's no records for the cronjob since then.

 

[cPanelDon]

It stopped working at the end of July, and there's no records for the cronjob since then.

Is the cron daemon running and set to automatically start?

# /etc/init.d/crond status
# chkconfig --list crond

 

[Daniel15]

Yes:

root@quimby [/]# /etc/init.d/crond status
crond (pid  2030) is running...
root@quimby [/]# chkconfig --list crond
crond           0: off   1: off   2: on    3: on    4: on    5: on    6: off

I did notice the following in /var/log/cron, which is a bit odd:

2010-09-08T16:00:01.424856+10:00 quimby crond[12575]: Cannot make/remove an entry for the specified session
2010-09-08T16:00:01.424995+10:00 quimby crond[12575]: CRON (root) ERROR: failed to open PAM security session: Success
2010-09-08T16:00:01.425004+10:00 quimby crond[12575]: CRON (root) ERROR: cannot set security context
2010-09-08T16:01:01.427069+10:00 quimby crond[14658]: Cannot make/remove an entry for the specified session
2010-09-08T16:01:01.427246+10:00 quimby crond[14658]: CRON (root) ERROR: failed to open PAM security session: Success
2010-09-08T16:01:01.427254+10:00 quimby crond[14658]: CRON (root) ERROR: cannot set security context

Tried searching around but couldn't find any definite explanations on what's causing this. SELinux is disabled.

Edit: Trying the fix at 0002191: pam_loginuid fails with message: set_loginuid failed opening loginuid - CentOS Bug Tracker and seeing if that fixes it.
Edit 2: That appears to have fixed it. I edited the cpbackup cron to run now, and it ran correctly!
Also see: http://linux-vserver.org/Frequently_Asked_Questions#Why_do_neither_sshd_nor_crond_.28vixie-cron.29_work_correctly_in_my_CentOS_.2F_Fedora_guest.3F_I_get_.27pam_loginuid.28crond:session.29:_set_loginuid_failed_opening_loginuid.27_and_similar_lines_in_my_logs. (I'm using Linux-Vserver)

 

[cPanelDon]

Yes:

root@quimby [/]# /etc/init.d/crond status
crond (pid  2030) is running...
root@quimby [/]# chkconfig --list crond
crond           0: off   1: off   2: on    3: on    4: on    5: on    6: off

I did notice the following in /var/log/cron, which is a bit odd:

2010-09-08T16:00:01.424856+10:00 quimby crond[12575]: Cannot make/remove an entry for the specified session
2010-09-08T16:00:01.424995+10:00 quimby crond[12575]: CRON (root) ERROR: failed to open PAM security session: Success
2010-09-08T16:00:01.425004+10:00 quimby crond[12575]: CRON (root) ERROR: cannot set security context
2010-09-08T16:01:01.427069+10:00 quimby crond[14658]: Cannot make/remove an entry for the specified session
2010-09-08T16:01:01.427246+10:00 quimby crond[14658]: CRON (root) ERROR: failed to open PAM security session: Success
2010-09-08T16:01:01.427254+10:00 quimby crond[14658]: CRON (root) ERROR: cannot set security context

Tried searching around but couldn't find any definite explanations on what's causing this. SELinux is disabled.

Edit: Trying the fix at 0002191: pam_loginuid fails with message: set_loginuid failed opening loginuid - CentOS Bug Tracker and seeing if that fixes it.
Edit 2: That appears to have fixed it. I edited the cpbackup cron to run now, and it ran correctly!
Also see: Frequently Asked Questions - Linux-VServer (I'm using Linux-Vserver)

Thank you for following-up with details about the resolution; the information is greatly appreciated.

 

[Daniel15]

No worries, I thought it might be helpful to others. Now I just have to figure out what caused this issue. I'm using Linux-VServer and several vservers but actually own the server myself. I restarted the host server around the time it stopped working for kernel updates, so I might try and work out if an update was the cause.

Too bad I didn't notice it until now!