Obsolete Releases > SME 8.x Contribs
Problem with AFFA after upgrade prodbox to SME 8.0
idp_qbn:
I support a volunteer group 300 Km from my home. I set up affa to make backups of the production server ('artserver') to an AFFA box ('affa-server')
This worked fine when both servers were SME7.5. I upgraded 'affa-server' to SME 8.0 and all was still OK. That was actually an 'upgrade' not a 're-install'.
I have the same set-up at home and it works OK.
I then , a month or so later, upgraded 'artserver' to SME8.0 and AFFA stopped working. I was unable to check the system remotely (they changed ISP) for a while and have now discovered that something is preventing AFFA from completing a backup. I am not sure if the problem is on 'affa-server' or 'artserver'
I would appreciate any advice on how to solve the problem.
I have already uninstalled and re-installed AFFA and have spent hours reading logs and searching the forums and bug-zilla but have not come up with anything that helps.
Below are excerpts of log files from the two servers.....some obvious errors are highlighted in red
========================================================================
/var/log/affa/prodbox.log: Viewed at Mon 16 Jul 2012 08:02:05 AM EST
Mon Jul 16 08:00:24[3612]: ##################
Mon Jul 16 08:00:24[3612]: # Affa 2.0.0-rc4 #
Mon Jul 16 08:00:24[3612]: ##################
Mon Jul 16 08:00:24[3612]: Starting job prodbox scheduled (192.168.1.32)
Mon Jul 16 08:00:24[3612]: Description: Artserver Backup
Mon Jul 16 08:00:24[3612]: Checking SSH connection to 192.168.1.32
Mon Jul 16 08:00:25[3612]: Installing watchdog on 192.168.1.32 with dt=87000 seconds
Mon Jul 16 08:00:26[3612]: signaling pre-backup event on 192.168.1.32
Mon Jul 16 08:00:27[3612]: Error 881 in 'main': signaling pre-backup event failed. <========= Hmmmm?
Mon Jul 16 08:00:27[3612]: Starting re-run 1 of 3 in the background.
Mon Jul 16 08:00:27[3612]: Total execution time: 0h00m03s
Mon Jul 16 08:00:27[3612]: Email sent to admin
Mon Jul 16 08:00:27[3612]: Exiting.
Mon Jul 16 08:00:27[3612]: .
Mon Jul 16 08:00:31[3658]: ##################
Mon Jul 16 08:00:31[3658]: # Affa 2.0.0-rc4 #
Mon Jul 16 08:00:31[3658]: ##################
Mon Jul 16 08:00:31[3658]: Starting job prodbox scheduled (192.168.1.32)
Mon Jul 16 08:00:31[3658]: Description: Artserver Backup
Mon Jul 16 08:00:31[3658]: Sleeping 597 seconds. Continuing at 08:10:28
========================================================================
Email from affa-server
To: admin@artsound.local
Subject: Error on affa-server.artsound.local (192.168.1.240): Job 'prodbox' failed.
Excerpt from log file /var/log/affa/prodbox.log:
Affa_2.0.0-rc4:_Running_/sbin/e-smith/affa_--run_prodbox
Job_configuration:
__AutoUnmount=yes
__ChunkSize=921600
__ChunkThresholdSize=2
__ConnectionCheckTimeout=120
__Debug=no
__Description=Artserver_Backup
__DiskSpaceWarn=strict
__EmailAddresses=admin
__RPMCheck=no
__RetryAfter=600
__RetryAttempts=3
__RetryNotification=yes
__RootDir=/var/affa
__SMEServer=yes
__SambaShare=yes
__TimeSchedule=1000,1300,1700,2230
__Watchdog=yes
__dailyKeep=7
__doneDaily=-1
__doneMonthly=-1
__doneWeekly=-1
__doneYearly=-1
__monthlyKeep=12
__remoteHostName=192.168.1.32
__remoteOS=centos
__rsync--inplace=yes
__rsyncCompress=no
__rsyncTimeout=900
__rsyncdMode=no
__rsyncdModule=AFFA
__rsyncdPassword=<not_shown>
__rsyncdUser=affa
__scheduledKeep=1
__sendStatus=weekly
__sshPort=2222
__status=enabled
__type=job
__weeklyKeep=4
__yearlyKeep=1
##################
#_Affa_2.0.0-rc4_#
##################
Starting_job_prodbox_scheduled_(192.168.1.32)
Description:_Artserver_Backup
Checking_SSH_connection_to_192.168.1.32
Exec_Out:_OK
Exec_Out:_exitstatus=0
Installing_watchdog_on_192.168.1.32_with_dt=87000_seconds
Watchdog_parameters:
___TRIGGER=>201207170810
___JOBNAME=>'prodbox'
___EMAIL=>'admin'
___BACKUPHOST=>'affa-server.artsound.local_(192.168.1.240)'
___SCHEDULED=>'Mon_Jul_16_08:00:25_2012'
___WDSCRIPT=>'affa-watchdog-prodbox-192.168.1.240'
Exec_Out:_exitstatus=0
Exec_Out:_exitstatus=0
signaling_pre-backup_event_on_192.168.1.32
Exec_Out:_exitstatus=1
Error_881_in_'main':_signaling_pre-backup_event_failed. <============= Hmmmm (just a repeat of the previous)
Starting_re-run_1_of_3_in_the_background.
Total_execution_time:__0h00m03s
========================================================================
Excerpt from messages.log on 'artserver' (prodbox)
Jul 16 08:00:26 artserver esmith::event[3940]: Processing event: pre-backup desktop
Jul 16 08:00:26 artserver esmith::event[3940]: Running event handler: /etc/e-smith/events/actions/generic_template_expand
Jul 16 08:00:26 artserver esmith::event[3940]: expanding /etc/dar/DailyBackup.dcf
Jul 16 08:00:26 artserver esmith::event[3940]: generic_template_expand=action|Event|pre-backup|Action|generic_template_expand|Start|1342389626 624066|End|1342389626 923901|Elapsed|0.299835
Jul 16 08:00:26 artserver esmith::event[3940]: Running event handler: /etc/e-smith/events/pre-backup/S10mysql-delete-dumped-tables
Jul 16 08:00:26 artserver esmith::event[3940]: S10mysql-delete-dumped-tables=action|Event|pre-backup|Action|S10mysql-delete-dumped-tables|Start|1342389626 924655|End|1342389626 929729|Elapsed|0.005074
Jul 16 08:00:26 artserver esmith::event[3940]: Running event handler: /etc/e-smith/events/pre-backup/S20mysql-dump-tables
Jul 16 08:00:27 artserver esmith::event[3940]: mysqldump: Got error: 1017: Can't find file: 'procs_priv' (errno: 2) when using LOCK TABLES
Jul 16 08:00:27 artserver esmith::event[3940]: S20mysql-dump-tables=action|Event|pre-backup|Action|S20mysql-dump-tables|Start|1342389626 930524|End|1342389627 235840|Elapsed|0.305316|Status|256
Jul 16 08:00:27 artserver esmith::event[3940]: Running event handler: /etc/e-smith/events/pre-backup/S30ldap-dump
Jul 16 08:00:27 artserver esmith::event[3940]: S30ldap-dump=action|Event|pre-backup|Action|S30ldap-dump|Start|1342389627 236566|End|1342389627 504449|Elapsed|0.267883
Jul 16 08:00:27 artserver esmith::event[3940]: Running event handler: /etc/e-smith/events/pre-backup/S50rewind-tape
Jul 16 08:00:27 artserver esmith::event[3940]: S50rewind-tape=action|Event|pre-backup|Action|S50rewind-tape|Start|1342389627 505268|End|1342389627 654810|Elapsed|0.149542
========================================================================
Both servers are SME8.0, 2 disk RAID1
artserver is 192.68.1.32
affa-server is 192.168.1.240
My gut feeling is that :
a) something went wrong with the upgrade of 'artserver' and I did not notice at the time, OR
b) I have something configured incorrectly OR
c) I inadvertently deleted something when I was removing contribs from 'artserver' before upgrading.
Or all three
Cheeers
Ian
janet:
idp_qbn
Without analysing your problem greatly, I would guess you should recreate the secure keys.
See step 5 here
http://wiki.contribs.org/Affa#Quick_start_example
idp_qbn:
Thanks for your reply, Mary.
I have tried that without success, unfortunately.
I think the message on the AFFA (affaserver)box that says
Error 881 in 'main': signaling pre-backup event failed
combined with the message on the production server (artserver) that says
mysqldump: Got error: 1017: Can't find file: 'procs_priv' (errno: 2) when using LOCK TABLES
together indicate the problem lies in the pre-backup process.
Perhaps 'artserver' can't complete the pre-backup and signals back to 'affaserver' which then halts the process (after a few more retries).
But I don't know what to do about it....
Cheers
Ian
janet:
idp_qbn
I'd say the mysql error is your starting point. Something is wrong with a mysql table & this causes the pre-backup event to fail.
You could manually disable the affa backup temporarily.
Then try manually instigating the pre-backup event.
Then review the log files & I assume you may still see the mysql error. If so that just proves the
theory/possibility of where the problems lies.
Then I would start looking at the mysql tables, perhaps fire up phpmyadmin or use the mysql command line to check tables etc. I'd have to refer to my mysql notes re troubleshooting, it's early & my mysql memory bank has not yet dumped it's contents into my frontal lobes.
I vaguely recall some similar error to this going back approx 2 or 3 years, so you could try searching the forums on mysql.
Perhaps a table was not converted correctly during the sme8.0 upgrade and that table cannot be locked to perform the mysql dump during the pre-backup.
Hope that helps.
nicolatiana:
Please post the result of:
--- Quote --- mysql -BNre "show databases;"
--- End quote ---
maybe there's something to be cleaned/rebuilt in Mysql after the unistallation of some contrib.
I leave the place to some mysql "guru" to give You some more help . . . . :-?
Nicola
Addendum after Mary post: in italian forum there's this post: http://forums.contribs.org/index.php/topic,47580.msg235020.html#msg235020
The user installed and then removed zabbix (maybe not correctly or there's some bug in uninstall, I don't know) and he got similar error using DAR & DAR2 contribs: there was a "ghost" table named "history" belonging to zabbix and not removed. The user then installed phpmysqladmin contrib and made some wash&clean in the database and solved.
Be careful in washing & cleaning :shock: .
Navigation
[0] Message Index
[#] Next page
Go to full version