diff options
| author | Volker Lendecke <vl@samba.org> | 2019-12-10 11:48:07 +0100 |
|---|---|---|
| committer | Jeremy Allison <jra@samba.org> | 2019-12-10 20:31:40 +0000 |
| commit | 7535359602e8b33e38ef1e0e38dc070773a39ea8 (patch) | |
| tree | 9d365fcd01a4c51c43861098b63ea5aaf7db825c /selftest | |
| parent | 79b2ee8dc2382354750601ee3d57912442c09817 (diff) | |
| download | samba-7535359602e8b33e38ef1e0e38dc070773a39ea8.tar.gz | |
torture: Run durable_v2_reconnect_delay_msec with leases
This will show a leases.tdb record leak. If you SIGSTOP the smbtorture
process while it's in the 10-second wait, you will find locking.tdb
and share_entries.tdb empty after the scavenger has cleaned up. But
there will be an entry in leases.tdb left.
I have no clue how to test this properly, or how to have a reasonably
cheap assert in smbd during normal operations. The problem is that
this leak can't really be distinguished from a "normal" leak that a
crashed smbd would leave behind. Possibly we need a background job
walking leases.tdb to clean this up properly.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Diffstat (limited to 'selftest')
| -rw-r--r-- | selftest/knownfail.d/durable-v2-delay | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/selftest/knownfail.d/durable-v2-delay b/selftest/knownfail.d/durable-v2-delay new file mode 100644 index 00000000000..2a84749b0eb --- /dev/null +++ b/selftest/knownfail.d/durable-v2-delay @@ -0,0 +1,2 @@ +# In the ad_dc env leases are disabled +^samba3.smb2.durable-v2-delay.durable_v2_reconnect_delay_msec\(ad_dc\) |