Pivotal Knowledge Base

Follow

GPMFR --list error "ValueError: invalid literal for long() with base 10:"

Environment

Pivotal Greenplum: 4.3.x

OS: RHEL 6.x

Symptom

When listing backups on DataDomain using gpmfr, the command fails with the following error.

Error Message

[gpadmin@sngrnp0901 gpAdminLogs]$ gpmfr --list -v 
20170605:07:22:34:003828 gpmfr:sngrnp0901:gpadmin-[INFO]:-Starting gpmfr with args: --list -v
Listing backups on local(dnddost15-2.backup.dtcc.com) Data Domain.
Default backup directory: dnddmgt15-GTRNDC/db_dumps
2017-May-22 02:45:23 (20170522024523)
2017-May-22 02:56:34 (20170522025634)
20170605:07:23:11:003828 gpmfr:sngrnp0901:gpadmin-[ERROR]:-gpmfr failed. exiting...
Traceback (most recent call last):
File "/usr/local/greenplum-db/lib/python/gppylib/mainUtils.py", line 281, in simple_main_locked
exitCode = commandObject.run()
File "/usr/local/greenplum-db/lib/python/gppylib/operations/__init__.py", line 53, in run
self.ret = self.execute()
File "/usr/local/greenplum-db/./bin/gpmfr.py", line 1180, in execute
self.listBackups()
File "/usr/local/greenplum-db/./bin/gpmfr.py", line 1315, in listBackups
bkpSets = self.parseBackupListing(lines)
File "/usr/local/greenplum-db/./bin/gpmfr.py", line 1255, in parseBackupListing
size = long(m.group(5))
ValueError: invalid literal for long() with base 10: ''

Cause 

gpmfr is using 'gpddboost --ls' in the background to get a list of the backup files. The list is then parsed and one of the values is a size of the file. parseBackupListing function located in /usr/local/greenplum-db-4.3.8.0/bin/gpmfr.py is not able to parse a 0 size file and returns an empty object. This further crashes the gpmfr tool.

List of Backup Files

[gpadmin@sngrnp0901 ~]$ gpddboost --ls dnddmgt15-GTRNDC/db_dumps/20170602
20170613:04:29:32|ddboost-[DEBUG]:-Libraries were loaded successfully
20170613:04:29:32|ddboost-[INFO]:-opening LB on /home/gpadmin/DDBOOST_CONFIG
20170613:04:29:32|gpddboost-[DEBUG]:-ddp_open_dir(dnddmgt15-GTRNDC/db_dumps/20170602)
NAME MODE SIZE(bytes)
===============================================================================================
gp_dump_0_134_20170602005725.gz 775 308
gp_dump_0_133_20170602005725.gz 775 308
(...)
gp_dump_0_11_20170602081532.gz 600 308
gp_dump_0_12_20170602081532.gz 600 308
gp_dump_1_1_20170602081532.gz 600 496
gp_dump_0_19_20170602081532.gz 600 308
gp_dump_0_8_20170602081532.gz 600 308
gp_dump_0_121_20170602081532.gz 600 308
gp_cdatabase_1_1_20170602081532 777 113
gp_dump_0_4_20170602081532.gz 600 308
gp_dump_1_1_20170602081532_post_data.gz 600 196
gp_dump_20170602081532_ao_state_file 600 0
gp_dump_20170602081532_co_state_file 600 0
gp_dump_20170602081532_last_operation 600 0

Gpmfr will fail on gp_dump_20170602081532_ao_state_file as it has a 0 size 

Resolution

The current workaround is to manually remove 0 size files from the DataDomain. Use "gpddboost --ls" to identify the 0 size files. 

This issue has been addressed in GPDB 4.3.13.0.

 

Comments

Powered by Zendesk