Looking at the source code in that package I also see that the -s option is available in squatter. Do you get an error message when you run squatter with that option?
If you run squatter in verbose mode, it should print messages such as "Skipping mailbox xyz"
On Mon, May 17, 2021, at 5:28 PM, Gabriele Bulfon via Info wrote:
I'm not building from a git clone of the tag, but downloading the tar gz from here:https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.4.1/cyrus-imapd-3.4.1.tar.gzDo you mean this archive may have "-s" disabled?Sonicle S.r.l. : http://www.sonicle.comeXoplanets : https://gabrielebulfon.bandcamp.com/album/exoplanetsDa: Robert Stepanek <rsto@xxxxxxxxxxxxxxxx>
A: Gabriele Bulfon <gbulfon@xxxxxxxxxxx>Gabriele Bulfon via Info <info@xxxxxxxxxxxxxxxxxx>
Data: 17 maggio 2021 13.56.53 CEST
Oggetto: Re: Solved: Squatter core dumpHi Gabriele,On Fri, May 14, 2021, at 5:11 PM, Gabriele Bulfon wrote:I've found that upgrading to Cyrus 3.4.1, squatter works fine on my cloned imap base!Now I will do more tests and check again the xapian backend.Great!This version of squatter misses the "-s" option, so I have no way to tell it to not consider unchanged mailboxes.I just checked out the 3.4.1 tag from Github and it does contain the -s option: https://github.com/cyrusimap/cyrus-imapd/blob/81629293ca4ced90bde67bc488e7c26537735adb/imap/squatter.c#L140I just pushed a Cassandane test that confirms this: https://github.com/cyrusimap/cassandane/commit/5a35100aab443c807607c1c9cb91249541dd4662Cheers,RobertThis is important on my ZFS based servers, where rewriting the entire cyrus.squat when nothing has changed will cause a useless lot of space used by zfs snapshots.Why is this "-s" option now available only on master branch?Thanks a lot,GabrieleSonicle S.r.l. : http://www.sonicle.comeXoplanets : https://gabrielebulfon.bandcamp.com/album/exoplanetsDa: Robert Stepanek <rsto@xxxxxxxxxxxxxxxx>
A: Gabriele Bulfon <gbulfon@xxxxxxxxxxx>Gabriele Bulfon via Info <info@xxxxxxxxxxxxxxxxxx>
Data: 11 maggio 2021 13.54.40 CEST
Oggetto: Re: Squatter core dumpYes, but unfortunately I didn't find time to do more than that. The log pretty much confirms that there's memory corruption, with invalid reads and writes all over the place.This line looks like a potential start to debug:==17293== Address 0xff28149a0 is 0 bytes inside a block of size 2,056 free'd==17293== at 0xFFFF64A29: free (vg_replace_malloc.c:549)==17293== by 0x407A28: write_trie_word_data (squat_build.c:1364)(interestingly, in my code the free happens at line 1363).As a very crude attempt, you could just comment out this free() call. It will leak memory, but if that omits the segfault then we have narrowed down what's causing the corruption.On Tue, May 11, 2021, at 1:38 PM, Gabriele Bulfon wrote:Hight, did you have any chance to check the valgrind log I've sent?Sonicle S.r.l. : http://www.sonicle.comeXoplanets : https://gabrielebulfon.bandcamp.com/album/exoplanetsDa: Robert Stepanek <rsto@xxxxxxxxxxxxxxxx>
A: Gabriele Bulfon via Info <info@xxxxxxxxxxxxxxxxxx>
Data: 7 maggio 2021 17.45.19 CEST
Oggetto: Re: Squatter core dumpOn Fri, May 7, 2021, at 5:31 PM, Gabriele Bulfon via Info wrote:Never did, it's our illumos distro, but I may have valgrind.Can you help on this?Just running "valgrind --leak-check=full <path-to-squatter> <your-args>" should do the trick.Cheers,Robert
