[I should have gone to bed way before]
Am Sonntag, 4. November 2007 schrieben Sie:
>
> It's not a ACL problem, afaics:
No wonder, if beaten with blindness:
> lam shared.text*
> shared.test:
> test lrswipkxtecd
> cyrus lrswipkxtecda
> anyone p
> shared.test.Gesendet:
> test lrswipkxtecd
>
Brian Wong wrote:
> On Nov 2, 2007 12:39 PM, Rudy Gevaert <[EMAIL PROTECTED]> wrote:
>> Brian Wong wrote:
>>> I was testing out Cyrus 2.3.10 and realized that when I set the option
>>>
>>> delete_mode: delayed
>>>
>>> I can not delete top-level mailboxes.
>>>
>>> localhost.localdomain> lm
>>> local
On 03 Nov 2007, at 23:20, Rich Wales wrote:
> Wesley Craig wrote:
>> It usually dies for a reason, i.e., some discrepancy that either
>> sync_client or sync_server couldn't handle. The typical way to
>> handle it is to contact someone.
>
> What sort of debugging output am I going to need to genera
Wesley Craig wrote:
> Both sync_client and sync_server typically log problems. Those
> logs are probably immediately helpful. Further information would
> depend on the reason for the bail out.
Where would I find this log info? As I said earlier, the only info I've
found so far are the "Error i
On 04 Nov 2007, at 13:11, Rich Wales wrote:
> Where would I find this log info? As I said earlier, the only info
> I've
> found so far are the "Error in do_sync(): bailing out!" notices in the
> /var/log/messages file. Are there some other log files saved
> somewhere
> else? I do have "-l" a
Wesley Craig wrote:
> The replica sync_server will also log to syslog.
No, sorry, as best I can tell, there isn't anything non-routine in any
of the log files on my replica server.
Do I need to specify any command-line flags to sync_server?
--
Rich Wales === Palo Alto, CA, USA =
On 04 Nov 2007, at 14:27, Rich Wales wrote:
> No, sorry, as best I can tell, there isn't anything non-routine in any
> of the log files on my replica server.
> Do I need to specify any command-line flags to sync_server?
No, sync_server doesn't take much in the way of command line
options. If th
Wesley Craig wrote:
> No, sync_server doesn't take much in the way of command line options.
Hmmm. OK, thanks.
> If the problem appears to be reproducible, you can enable telemetry
> logging or examine the mailboxes that are causing problem.
I currently have absolutely no idea as to what is cau
Wesley Craig wrote:
> The log files are pretty obvious in what they say, e.g., they just
> list mailboxes or users to check. So I suspect they would reveal
> to you which mailboxes are problematic. I sort of assume that
> you're running sync_client with -l, otherwise it doesn't log much.
> If it
What is the current status of 2.3.10? Right after it was announced
a couple of weeks ago, I saw some people reporting problems. Are
there any patches? Or is 2.3.10 still believed to be OK as is?
I'm running 2.3.9 on a FreeBSD 6.2 master and an Ubuntu 7.10 replica
server setup, and I want to upg
If you're running with -r -l (-v is for interactive use -- it causes
printf output), you should be getting messages like:
APPEND user.marie
in syslog at level INFO. If you're not seeing those, then you have
syslog configured to filter them. See the man page for syslog.conf.
:wes
O
The log files are pretty obvious in what they say, e.g., they just
list mailboxes or users to check. So I suspect they would reveal to
you which mailboxes are problematic. I sort of assume that you're
running sync_client with -l, otherwise it doesn't log much. If it's
run with -l, it sho
Wesley Craig wrote:
> If you're running with -r -l . . . , you should be getting messages
> like:APPEND user.mariein syslog at level INFO. If you're
> not seeing those, then you have syslog configured to filter them.
Thanks. It looks like that's what was happening. I modified my
syslog
On 04 Nov 2007, at 22:57, Rich Wales wrote:
> Should I be looking for similar syslog messages on my replica server
> too (and checking syslog.conf on that system if necessary)?
No, not similar. But most sync_server errors that will cause
sync_client to bail out ought to cause sync_server to giv
Wesley Craig wrote:
> But most sync_server errors that will cause sync_client to bail out
> ought to cause sync_server to give a reasonably unique log message
> for the failure.
As I explained earlier this evening, I didn't see ANYTHING AT ALL in
the replica server's logs that resembled any sort
15 matches
Mail list logo