<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 02/14/2018 10:35 AM, Lists Nethead wrote:<br>
<blockquote type="cite"
cite="mid:20180214173505.Horde.VPJr30cs4XQGuAK5e-DZMDg@webmail.nethead.se">Quoting
Nic Bernstein <a class="moz-txt-link-rfc2396E" href="mailto:nic@onlight.com"><nic@onlight.com></a>:
<br>
<br>
<blockquote type="cite">The advice to move it to START is actually
based on a recently discovered bug, referred to in that issue
report (#2234). It /should/ be in DAEMON, but for that
bug, which has been fixed. The fix will be in the next
release.
<br>
<br>
In general, the mailing is a grand place to start, and IRC is
also your friend (#cyrus on freenode).
<br>
<br>
Cheers,
<br>
-nic
<br>
<br>
On 02/14/2018 04:58 AM, Lists Nethead wrote:
<br>
<blockquote type="cite">Quoting Sebastian Hagedorn
<a class="moz-txt-link-rfc2396E" href="mailto:Hagedorn@uni-koeln.de"><Hagedorn@uni-koeln.de></a>:
<br>
<br>
<blockquote type="cite">--On 14. Februar 2018 um 11:13:15
+0100 Lists Nethead <a class="moz-txt-link-rfc2396E" href="mailto:lists@nethead.se"><lists@nethead.se></a> wrote:
<br>
<br>
<blockquote type="cite">I am testing Xapian in a 3.0.5 setup
on FreeBSD using most default
<br>
setting. If I start imapd with "squatter cmd="squatter
-R", more and more
<br>
"squatter" processes are created and eventually grabs all
resources.
<br>
</blockquote>
<br>
Where did you put that statement? You can't put it in the
DAEMON section with 3.0.5. Put it in START instead. See this
issue for more information:
<br>
<br>
<a class="moz-txt-link-rfc2396E" href="https://github.com/cyrusimap/cyrus-imapd/issues/2234"><https://github.com/cyrusimap/cyrus-imapd/issues/2234></a>
<br>
</blockquote>
<br>
A-ha. So it is better to look at Github instead of the mailing
list apparently.
<br>
<br>
<a class="moz-txt-link-freetext" href="https://www.cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html">https://www.cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html</a>
still advises DAEMON, that is why it ended up there.
<br>
</blockquote>
</blockquote>
<br>
Thanks to the advise above and I believe I got it working now.
<br>
<br>
One more thing though, if replication is involved, it appears one
needs one log for squatter and another for replication, am I
correct? I got replication to work only after I added another log,
like,
<br>
<br>
sync_log_channels: squatter replog
<br>
and
<br>
syncclient cmd="/usr/local/cyrus/sbin/sync_client -r -n
replog"
<br>
<br>
Not sure if this is mentioned in the docs somewhere.
<br>
<br>
Cheers,
<br>
<br>
//per
<br>
</blockquote>
<br>
In general, for each consumer of a sync_log, a new log should be
defined in `sync_log_channels:`. I use the word "consumer" there
intentionally, as the processes which use these logs actually
consume them, and leave nothing behind (assuming it all works as
expected). So if more than one process tries to eat up the same
log, you'll have problems.<br>
<br>
The overloading of the sync_log framework for purposes beyond
replication is new in 3.0, so we're still getting the documentation
up to snuff in that regard. However, the documentation already
makes this concept clear in that when using more than one replica
you need to specify more than one sync_log via the
`sync_log_channels:` directive (see
<a class="moz-txt-link-freetext" href="https://www.cyrusimap.org/imap/reference/admin/sop/replication.html#channels">https://www.cyrusimap.org/imap/reference/admin/sop/replication.html#channels</a>
for details). <br>
<br>
We obviously do need to produce more generalized documentation for
this whole scheme, and I'll be using this discussion as a guide in
that regard. sync_log, as the name implies, started life as a way
for the "master" server to provide a list of "units" -- either users
or mailboxes -- it has touched, so that a replica knows what to
request in updates. This is such a useful concept, however, that it
is spreading to other subsystems which need to know what might have
changed in a potentially large data set (the typical mail store) and
so we need to explain this not just in the Replication
documentation, but in a more general way.<br>
<br>
Note also that there is a `sync_log_unsuppressable_channels:`
directive, which defaults to "squatter". This is defined as:<br>
<blockquote>
<blockquote>
<div>If specified, the named channels are exempt from the effect
of setting
sync_log_chain:off, i.e. they are always logged to by the
sync_server
process. This is only really useful to allow rolling search
indexing
on a replica.</div>
</blockquote>
</blockquote>
If you are going to use a name other than "squatter" for your
rolling indexing sync_log channel, then you need to update this as
well.<br>
<br>
Cheers,<br>
-nic<br>
</body>
</html>