Project

General

Profile

Bug #76431

fix map_source variable leaking in for loop in autorepl.py under certain failure condition

Added by Caleb St. John over 2 years ago. Updated over 2 years ago.

Status:
Done
Priority:
No priority
Assignee:
Caleb St. John
Category:
Middleware
Seen in:
TrueNAS - TrueNAS 11.1-U5
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
No
Needs Doc:
No
Needs Merging:
No
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

When there is a certain failure condition in autorepl.py, we start a for loop that recursively iterates over all the replication jobs and associates the snapshots accordingly. If inside that loop, there is an error we will use the last for loops snaplist initialization value which will send the wrong dataset from the source side, to the wrong dataset to the receiving side.

Logs look something like this:

Feb 15 13:41:09 tn1-c1-igb0 /autorepl.py: [tools.autorepl:291] Checking dataset Zpool-1/LUN-Fs2-4
Feb 15 13:41:10 tn1-c1-igb0 /autorepl.py: [tools.autorepl:425] snaplist = ['Zpool-1/LUN-Fs2-4@auto-20190202.0600-2w\t1549116006', 'Zpool-1/LUN-Fs2-4@auto-20190203.0600-2w\t1549202406', 'Zpool-1/LUN-Fs2-4@auto-20190204.0600-2w\t1549288806', 'Zpool-1/LUN-Fs2-4@auto-20190205.0600-2w\t1549375206', 'Zpool-1/LUN-Fs2-4@auto-20190206.0600-2w\t1549461606', 'Zpool-1/LUN-Fs2-4@auto-20190207.0600-2w\t1549548007', 'Zpool-1/LUN-Fs2-4@auto-20190208.0600-2w\t1549634406', 'Zpool-1/LUN-Fs2-4@auto-20190209.0600-2w\t1549720806', 'Zpool-1/LUN-Fs2-4@auto-20190210.0600-2w\t1549807206', 'Zpool-1/LUN-Fs2-4@auto-20190211.0600-2w\t1549893606', 'Zpool-1/LUN-Fs2-4@auto-20190212.0600-2w\t1549980006', 'Zpool-1/LUN-Fs2-4@auto-20190213.0600-2w\t1550066406', 'Zpool-1/LUN-Fs2-4@auto-20190214.0600-2w\t1550152806', 'Zpool-1/LUN-Fs2-4@auto-20190215.0600-2w\t1550239206']
Feb 15 13:41:10 tn1-c1-igb0 /autorepl.py: [tools.autorepl:291] Checking dataset Zpool-1/LUN-Fs2-6
Feb 15 13:41:10 tn1-c1-igb0 /autorepl.py: [tools.autorepl:131] Sending zfs snapshot: /sbin/zfs send -V -p Zpool-1/LUN-Fs2-4@auto-20190202.0600-2w | /usr/local/bin/pipewatcher $$ | /usr/local/bin/ssh -c arcfour256,arcfour128,blowfish-cbc,aes128-ctr,aes192-ctr,aes256-ctr -i /data/ssh/replication -o BatchMode=yes -o StrictHostKeyChecking=yes -o ConnectTimeout=7 -p 22 tn2-ix1.vpl.ca "/sbin/zfs receive -F -d 'Zpool-1/ds-MC-Archives' && echo Succeeded"

This ticket is to fix 2 items.

1. ensure the output and error variables are stripped of leading/trailing whitespace
2. initialize the map_source variable to an empty value for each loop iteration before trying to send the snapshot.


Related issues

Copied to FreeNAS - Bug #77215: Ensure replication variables are stripped of leading/trailing whitespace Ready for Testing
Copied to FreeNAS - Bug #77224: Ensure replication variables are stripped of leading/trailing whitespace Done

History

#1 Updated by Caleb St. John over 2 years ago

Unfortunately, I was unable to re-create this problem on the customers system. Even though, we were trivially reproducing it at the time I saw this problem.

However, the logs indicate a certain failure condition that the current code doesn't check. I'll be adding this patch to the current code based on a discussion with William.

#2 Updated by Caleb St. John over 2 years ago

  • Target version deleted (TrueNAS 11.1-U8)

#3 Updated by Caleb St. John over 2 years ago

  • Description updated (diff)

#4 Updated by Caleb St. John over 2 years ago

  • Description updated (diff)

#5 Updated by Caleb St. John over 2 years ago

  • Description updated (diff)

#6 Updated by Caleb St. John over 2 years ago

  • Subject changed from fix snaplist variable leaking in for loop in autorepl.py under certain failure condition to fix map_source variable leaking in for loop in autorepl.py under certain failure condition

#7 Updated by Bug Clerk over 2 years ago

  • Status changed from Unscreened to Ready for Testing

#8 Updated by Bug Clerk over 2 years ago

  • Target version set to 11.3-BETA1

#9 Updated by Bug Clerk over 2 years ago

  • Copied to Bug #77215: Ensure replication variables are stripped of leading/trailing whitespace added

#10 Updated by Bug Clerk over 2 years ago

  • Copied to Bug #77224: Ensure replication variables are stripped of leading/trailing whitespace added

#11 Updated by Dru Lavigne over 2 years ago

  • Status changed from Ready for Testing to Done
  • Target version changed from 11.3-BETA1 to Master - FreeNAS Nightlies
  • Needs QA changed from Yes to No
  • Needs Merging changed from Yes to No

Also available in: Atom PDF