Re: Sieve script not working
On 2/2/19 8:25 PM, Bron Gondwana wrote:
What is being written to syslog by your lmtpd?
Absolutely nothing (apart from transient errors on the rare occasions
when I reboot the server and sendmail comes up before imapd).
Is this log to be enabled somehow?
There's also a sieve-test binary that you can build in the Cyrus source
code. I don't think it's built by default on most platforms though, we
build it specially at FM. It takes a script and a raw email and spits
out a list of actions.
I don't have this (FreeBSD 11.2).
AFAICT the port doesn't disable this (in configure) or leave it behind
when installing.
I tried searching for this binary between "make" and "make install"
phases (*), but I didn't find it (or any source named anything like it).
What's the procedure to compile it?
(*)
# cd work/cyrus-imapd-2.5.12/
# find .|grep -i "sieve-test"
# find . -type f -exec grep -i "sieve-test" "{}" ";"
bye & Thanks
av.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Fatal error: Exists wrong 513 512 483 17057
Awesome - yes, the IOERROR messages are because files it expected to find weren't there. It's frustrating that reconstruct isn't robust enough to bring a slightly bogus cyrus.index back from the dead, but the end result is a working mailbox with a fully correct cyrus.index file :) The only thing that may have happened is that some emails which were previously deleted in the TareasCron folder came back from the dead - and of course all the flags on those messages will have gone away too. But the mailbox will work correctly now. Cheers, Bron. On Tue, Feb 5, 2019, at 03:26, Daniel Bareiro wrote: > Hi, Bron. Thanks for your reply. > > On 4/2/19 05:45, Bron Gondwana wrote: > > > Oh how frustrating... > > >> I tried using 'reconstruct' as you suggested and this was the result: > >> > >> -- > >> # /usr/lib/cyrus/bin/reconstruct -r user.admin > >> user.admin > >> user.admin.Backups > >> user.admin.Drafts > >> user.admin.Sent > >> user.admin.TareasCron: record corrupted 13 (maybe uid 9836) > >> user.admin.TareasCron: Mailbox format corruption detected Failed to > >> reconstruct mailbox > >> user.admin.Trash > >> -- > > > This clearly isn't syslogging enough! Can you check the permissions on > > the underlying filesystem! Also, try running reconstruct with -G, > > though it shouldn't make a difference. > > The previous thing was the output that I was obtaining in the console > when executing 'reconstruct'. This is what I get in the syslog when > executing the command with the '-G' flag: > > -- > Feb 4 11:48:29 mail cyrus/reconstruct[22727]: reconstructing user.admin > Feb 4 11:48:47 mail cyrus/reconstruct[22727]: mailbox: longlock > user.admin for 17.8 seconds > Feb 4 11:48:47 mail cyrus/reconstruct[22727]: Repacking mailbox > user.admin version 13 > Feb 4 11:48:48 mail cyrus/reconstruct[22727]: reconstructing > user.admin.Backups > Feb 4 11:48:50 mail cyrus/reconstruct[22727]: mailbox: longlock > user.admin.Backups for 2.5 seconds > Feb 4 11:48:50 mail cyrus/reconstruct[22727]: Repacking mailbox > user.admin.Backups version 13 > Feb 4 11:48:50 mail cyrus/reconstruct[22727]: reconstructing > user.admin.Drafts > Feb 4 11:48:51 mail cyrus/reconstruct[22727]: reconstructing > user.admin.Sent > Feb 4 11:48:51 mail cyrus/reconstruct[22727]: reconstructing > user.admin.TareasCron > -- > > But in essence the console shows the same output as without adding '-G': > > -- > # /usr/lib/cyrus/bin/reconstruct -G -r user.admin > user.admin > user.admin.Backups > user.admin.Drafts > user.admin.Sent > user.admin.TareasCron: record corrupted 13 (maybe uid 9836) > user.admin.TareasCron: Mailbox format corruption detected Failed to > reconstruct mailbox > user.admin.Trash > -- > > >> Just 'TasksCron' is the folder that I can not open. What do you suggest > >> to do in this case? > > > I'd take a backup, and then delete the cyrus.index file in that folder > > and run reconstruct again... That's a pretty extreme approach, but it > > should work. > > Let's try the pretty extreme approach... :-D > > -- > Feb 4 12:04:43 mail cyrus/reconstruct[22990]: reconstructing user.admin > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: reconstructing > user.admin.Backups > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: reconstructing > user.admin.Drafts > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: reconstructing > user.admin.Sent > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: reconstructing > user.admin.TareasCron > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: IOERROR: opening index > user.admin.TareasCron: System I/O error > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: create new mailbox > user.admin.TareasCron > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: failed to read index > header for user.admin.TareasCron > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 9837 found - adding > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 9838 found - adding > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 9839 found - adding > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 9840 found - adding > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 9841 found - adding > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 9842 found - adding > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 9843 found - adding > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 9844 found - adding > Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 9845 found - adding > [...] > Feb 4 12:07:21 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 27841 found - adding > Feb 4 12:07:21 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid > 27842 found - adding > Feb 4 12:07:21 mail cyrus/reconstruct[22990]: mailbox: longlock > user.admin.TareasCron for 157.3 seconds > Feb
Re: Fatal error: Exists wrong 513 512 483 17057
Hi, Bron. Thanks for your reply. On 4/2/19 05:45, Bron Gondwana wrote: > Oh how frustrating... >> I tried using 'reconstruct' as you suggested and this was the result: >> >> -- >> # /usr/lib/cyrus/bin/reconstruct -r user.admin >> user.admin >> user.admin.Backups >> user.admin.Drafts >> user.admin.Sent >> user.admin.TareasCron: record corrupted 13 (maybe uid 9836) >> user.admin.TareasCron: Mailbox format corruption detected Failed to >> reconstruct mailbox >> user.admin.Trash >> -- > This clearly isn't syslogging enough! Can you check the permissions on > the underlying filesystem! Also, try running reconstruct with -G, > though it shouldn't make a difference. The previous thing was the output that I was obtaining in the console when executing 'reconstruct'. This is what I get in the syslog when executing the command with the '-G' flag: -- Feb 4 11:48:29 mail cyrus/reconstruct[22727]: reconstructing user.admin Feb 4 11:48:47 mail cyrus/reconstruct[22727]: mailbox: longlock user.admin for 17.8 seconds Feb 4 11:48:47 mail cyrus/reconstruct[22727]: Repacking mailbox user.admin version 13 Feb 4 11:48:48 mail cyrus/reconstruct[22727]: reconstructing user.admin.Backups Feb 4 11:48:50 mail cyrus/reconstruct[22727]: mailbox: longlock user.admin.Backups for 2.5 seconds Feb 4 11:48:50 mail cyrus/reconstruct[22727]: Repacking mailbox user.admin.Backups version 13 Feb 4 11:48:50 mail cyrus/reconstruct[22727]: reconstructing user.admin.Drafts Feb 4 11:48:51 mail cyrus/reconstruct[22727]: reconstructing user.admin.Sent Feb 4 11:48:51 mail cyrus/reconstruct[22727]: reconstructing user.admin.TareasCron -- But in essence the console shows the same output as without adding '-G': -- # /usr/lib/cyrus/bin/reconstruct -G -r user.admin user.admin user.admin.Backups user.admin.Drafts user.admin.Sent user.admin.TareasCron: record corrupted 13 (maybe uid 9836) user.admin.TareasCron: Mailbox format corruption detected Failed to reconstruct mailbox user.admin.Trash -- >> Just 'TasksCron' is the folder that I can not open. What do you suggest >> to do in this case? > I'd take a backup, and then delete the cyrus.index file in that folder > and run reconstruct again... That's a pretty extreme approach, but it > should work. Let's try the pretty extreme approach... :-D -- Feb 4 12:04:43 mail cyrus/reconstruct[22990]: reconstructing user.admin Feb 4 12:04:44 mail cyrus/reconstruct[22990]: reconstructing user.admin.Backups Feb 4 12:04:44 mail cyrus/reconstruct[22990]: reconstructing user.admin.Drafts Feb 4 12:04:44 mail cyrus/reconstruct[22990]: reconstructing user.admin.Sent Feb 4 12:04:44 mail cyrus/reconstruct[22990]: reconstructing user.admin.TareasCron Feb 4 12:04:44 mail cyrus/reconstruct[22990]: IOERROR: opening index user.admin.TareasCron: System I/O error Feb 4 12:04:44 mail cyrus/reconstruct[22990]: create new mailbox user.admin.TareasCron Feb 4 12:04:44 mail cyrus/reconstruct[22990]: failed to read index header for user.admin.TareasCron Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 9837 found - adding Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 9838 found - adding Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 9839 found - adding Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 9840 found - adding Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 9841 found - adding Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 9842 found - adding Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 9843 found - adding Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 9844 found - adding Feb 4 12:04:44 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 9845 found - adding [...] Feb 4 12:07:21 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 27841 found - adding Feb 4 12:07:21 mail cyrus/reconstruct[22990]: user.admin.TareasCron uid 27842 found - adding Feb 4 12:07:21 mail cyrus/reconstruct[22990]: mailbox: longlock user.admin.TareasCron for 157.3 seconds Feb 4 12:07:21 mail cyrus/reconstruct[22990]: reconstructing user.admin.Trash -- I guess the 'IOERROR' is because the cyrus.index file can not be found. When afterwards it says 'create new mailbox user.admin.TareasCron' what it is creating is the index? Because, if so, I don't understand why later it says 'failed to read index header for user.admin.TareasCron'. In any case, I am now able to access the 'TareasCron' folder without problems. Thank you so much! >> I'm using Cyrus 2.5.10-3 on Debian Stretch. A few days ago I upgraded >> the entire operating system with Debian Jessie and Cyrus 2.4.17. > That upgrade should be fine, and 2.5.10 should be fine as well. I just > poked around in the code there to see how the reconstruct might be > failing, and there's not enough information to
Re: another problem with conversations db
On Mon, Feb 4, 2019, at 22:00, Michael Menge wrote:
>
> Quoting Bron Gondwana :
>
> > On Mon, Feb 4, 2019, at 20:21, Michael Menge wrote:
> >> Hi,
> >>
> >> Quoting Bron Gondwana :
> >>
> >> > Hi Michael,
> >> >
> >> > Sorry about the delay in looking at this - I was mad crazy busy
> >> > getting ready to go overseas. At Fosdem now, about to give a talk
> >> > about JMAP!
> >> >
> >> > OK, let's start with the things that give me a little bit of hives...
> >> >
> >> > configdirectory: /srv/cyrus-be
> >> > partition-default: /srv/cyrus-be
> >> > partition-ssd: /srv/cyrus-be/ssd-part
> >> >
> >> > Ouch. There's a couple of things I wouldn't do there - having the
> >> > partition be the same as the config directory, and having a separate
> >> > partition be a subdirectory of a partition. They're both asking for
> >> > trouble. I would probably lay my system out like:
> >> >
> >> > configdirectory: /srv/cyrus-be/conf
> >> > partition-default: /srv/cyrus-be/default-part
> >> > partition-ssd: /srv/cyrus-be/ssd-part
> >> >
> >>
> >> partition-default isn't used any more. To use the metapartition we moved
> >> all accounts form the default partition to the ssd partition which is the
> >> the new defaultpartition ("defaultpartition: ssd")
> >
> > Right - that makes sense.
> >
> >> > And then each tree would only have one type of thing in it.
> >> >
> >> > Anyway, I don't think that would break anything.
> >> >
> >> > metapartition-ssd: /srv/cyrus-ssd-be/meta/ssd-part
> >> > metapartition_files: header index cache expunge squat annotations
> >> > lock dav archivecache
> >> >
> >> > Ooh, I haven't tested having cache and archivecache on the same
> >> > location. That's really interesting. Again, I'd be in favour of
> >> > separation here, give them different paths. That might be tricky
> >> > with ssd though, the way this is laid out. I assume you have some
> >> > kind of symlink farm going on?
> >> >
> >>
> >> I didn't know that there could be a problem with cache and archivecache.
> >> At the time we decided on the configuration for cyrus 3.0 I looked at the
> >> imapd.conf man page and for metapartition_files decided that I want all
> >> meta files on the ssd storage. There was no indication in the man page
> >> that there could be a problem.
> >
> > Fair. I'd have to test that to see if it works correctly. I would
> > hope so, but I haven't tested that configuration. This is the
> > downside with having lots of different ways to do things!
> >
> >> How do I separate location of archivecache from the other
> >> metapartition path?
> >> And fix the cache and archivecache files?
> >
> > This I don't know a good answer for. I will test if having the same
> > path for cache and archivecache could fail. I THINK that I made the
> > code safe for it, but I'm not sure that it's been tested.
> >
> >> No there is no sysmlink farm. We have mounted different iSCSI volumes to
> >> /srv/cyrus-ssd-be, /srv/cyrus-hdd-be and /srv/cyrus-be
> >
> > Right. That makes sense.
> >
> >> > Otherwise it all looks OK. Are you getting other IOERRORs in your
> >> > log files which could show things aborting? It really looks like
> >> > your conversations DB is getting out of sync due to other failures.
> >>
> >> I found a few instances of 3 related errors.
> >>
> >> Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR: opening
> >> /srv/cyrus-be/ssd-part/L/user//2185.: No such file or directory
> >> Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR: opening
> >> /srv/cyrus-be/ssd-part/L/user//2185.: No such file or directory
> >> Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR archive
> >> user. 2185 failed to copyfile
> >> (/srv/cyrus-be/ssd-part/L/user//2185. =>
> >> /srv/cyrus-hdd-be/archive/ssd-part/L/user//2185.): Unknown code
> >> 255
> >
> >
> > Ouch. Yeah, that could have been caused by a bug in delivery, and
> > would definitely cause conversations DB corruption if the index file
> > was updated but the conversations DB wasn't or vice versa.
> >
> >> The file was already at
> >> /srv/cyrus-hdd-be/archive/ssd-part/L/user//2185.
> >
> > Right! I do wonder if there are some bugs in 3.0.x which are fixed
> > on master around delivery to archive partition. We definitely had
> > bugs on master, but I thought they were newly introduced on master
> > as well, which is why the fixes weren't backported. But if you're
> > having files be in the wrong location, maybe there are bugs on 3.0.x
> > as well.
> >
> > Do you have the syslog lines at the time that email was delivered?
>
> I dont' have the log, for that message, but I will search for a
> more recent example.
Great.
>
> From the mail headers i know that it was not dilivered to the archive
> partition
> but moved by cyr_expire. The conversation db was not used at that time.
OK - that shouldn't matter then - because the conversations rebuild should have
found it.
> PS.: the timesamp of the file is not the internal date but
Re: another problem with conversations db
Quoting Bron Gondwana :
On Mon, Feb 4, 2019, at 20:21, Michael Menge wrote:
Hi,
Quoting Bron Gondwana :
> Hi Michael,
>
> Sorry about the delay in looking at this - I was mad crazy busy
> getting ready to go overseas. At Fosdem now, about to give a talk
> about JMAP!
>
> OK, let's start with the things that give me a little bit of hives...
>
> configdirectory: /srv/cyrus-be
> partition-default: /srv/cyrus-be
> partition-ssd: /srv/cyrus-be/ssd-part
>
> Ouch. There's a couple of things I wouldn't do there - having the
> partition be the same as the config directory, and having a separate
> partition be a subdirectory of a partition. They're both asking for
> trouble. I would probably lay my system out like:
>
> configdirectory: /srv/cyrus-be/conf
> partition-default: /srv/cyrus-be/default-part
> partition-ssd: /srv/cyrus-be/ssd-part
>
partition-default isn't used any more. To use the metapartition we moved
all accounts form the default partition to the ssd partition which is the
the new defaultpartition ("defaultpartition: ssd")
Right - that makes sense.
> And then each tree would only have one type of thing in it.
>
> Anyway, I don't think that would break anything.
>
> metapartition-ssd: /srv/cyrus-ssd-be/meta/ssd-part
> metapartition_files: header index cache expunge squat annotations
> lock dav archivecache
>
> Ooh, I haven't tested having cache and archivecache on the same
> location. That's really interesting. Again, I'd be in favour of
> separation here, give them different paths. That might be tricky
> with ssd though, the way this is laid out. I assume you have some
> kind of symlink farm going on?
>
I didn't know that there could be a problem with cache and archivecache.
At the time we decided on the configuration for cyrus 3.0 I looked at the
imapd.conf man page and for metapartition_files decided that I want all
meta files on the ssd storage. There was no indication in the man page
that there could be a problem.
Fair. I'd have to test that to see if it works correctly. I would
hope so, but I haven't tested that configuration. This is the
downside with having lots of different ways to do things!
How do I separate location of archivecache from the other
metapartition path?
And fix the cache and archivecache files?
This I don't know a good answer for. I will test if having the same
path for cache and archivecache could fail. I THINK that I made the
code safe for it, but I'm not sure that it's been tested.
No there is no sysmlink farm. We have mounted different iSCSI volumes to
/srv/cyrus-ssd-be, /srv/cyrus-hdd-be and /srv/cyrus-be
Right. That makes sense.
> Otherwise it all looks OK. Are you getting other IOERRORs in your
> log files which could show things aborting? It really looks like
> your conversations DB is getting out of sync due to other failures.
I found a few instances of 3 related errors.
Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR: opening
/srv/cyrus-be/ssd-part/L/user//2185.: No such file or directory
Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR: opening
/srv/cyrus-be/ssd-part/L/user//2185.: No such file or directory
Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR archive
user. 2185 failed to copyfile
(/srv/cyrus-be/ssd-part/L/user//2185. =>
/srv/cyrus-hdd-be/archive/ssd-part/L/user//2185.): Unknown code
255
Ouch. Yeah, that could have been caused by a bug in delivery, and
would definitely cause conversations DB corruption if the index file
was updated but the conversations DB wasn't or vice versa.
The file was already at /srv/cyrus-hdd-be/archive/ssd-part/L/user//2185.
Right! I do wonder if there are some bugs in 3.0.x which are fixed
on master around delivery to archive partition. We definitely had
bugs on master, but I thought they were newly introduced on master
as well, which is why the fixes weren't backported. But if you're
having files be in the wrong location, maybe there are bugs on 3.0.x
as well.
Do you have the syslog lines at the time that email was delivered?
I dont' have the log, for that message, but I will search for a
more recent example.
From the mail headers i know that it was not dilivered to the archive
partition
but moved by cyr_expire. The conversation db was not used at that time.
PS.: the timesamp of the file is not the internal date but the time
the mail was moved to the archive partition. I was wondering about the reason.
Michael
M.MengeTel.: (49) 7071/29-70316
Universität Tübingen Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung mail:
michael.me...@zdv.uni-tuebingen.de
Wächterstraße 76
72074 Tübingen
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
Re: another problem with conversations db
On Mon, Feb 4, 2019, at 20:21, Michael Menge wrote:
> Hi,
>
> Quoting Bron Gondwana :
>
> > Hi Michael,
> >
> > Sorry about the delay in looking at this - I was mad crazy busy
> > getting ready to go overseas. At Fosdem now, about to give a talk
> > about JMAP!
> >
> > OK, let's start with the things that give me a little bit of hives...
> >
> > configdirectory: /srv/cyrus-be
> > partition-default: /srv/cyrus-be
> > partition-ssd: /srv/cyrus-be/ssd-part
> >
> > Ouch. There's a couple of things I wouldn't do there - having the
> > partition be the same as the config directory, and having a separate
> > partition be a subdirectory of a partition. They're both asking for
> > trouble. I would probably lay my system out like:
> >
> > configdirectory: /srv/cyrus-be/conf
> > partition-default: /srv/cyrus-be/default-part
> > partition-ssd: /srv/cyrus-be/ssd-part
> >
>
> partition-default isn't used any more. To use the metapartition we moved
> all accounts form the default partition to the ssd partition which is the
> the new defaultpartition ("defaultpartition: ssd")
Right - that makes sense.
> > And then each tree would only have one type of thing in it.
> >
> > Anyway, I don't think that would break anything.
> >
> > metapartition-ssd: /srv/cyrus-ssd-be/meta/ssd-part
> > metapartition_files: header index cache expunge squat annotations
> > lock dav archivecache
> >
> > Ooh, I haven't tested having cache and archivecache on the same
> > location. That's really interesting. Again, I'd be in favour of
> > separation here, give them different paths. That might be tricky
> > with ssd though, the way this is laid out. I assume you have some
> > kind of symlink farm going on?
> >
>
> I didn't know that there could be a problem with cache and archivecache.
> At the time we decided on the configuration for cyrus 3.0 I looked at the
> imapd.conf man page and for metapartition_files decided that I want all
> meta files on the ssd storage. There was no indication in the man page
> that there could be a problem.
Fair. I'd have to test that to see if it works correctly. I would hope so, but
I haven't tested that configuration. This is the downside with having lots of
different ways to do things!
> How do I separate location of archivecache from the other metapartition path?
> And fix the cache and archivecache files?
This I don't know a good answer for. I will test if having the same path for
cache and archivecache could fail. I THINK that I made the code safe for it,
but I'm not sure that it's been tested.
> No there is no sysmlink farm. We have mounted different iSCSI volumes to
> /srv/cyrus-ssd-be, /srv/cyrus-hdd-be and /srv/cyrus-be
Right. That makes sense.
> > Otherwise it all looks OK. Are you getting other IOERRORs in your
> > log files which could show things aborting? It really looks like
> > your conversations DB is getting out of sync due to other failures.
>
> I found a few instances of 3 related errors.
>
> Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR: opening
> /srv/cyrus-be/ssd-part/L/user//2185.: No such file or directory
> Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR: opening
> /srv/cyrus-be/ssd-part/L/user//2185.: No such file or directory
> Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR archive
> user. 2185 failed to copyfile
> (/srv/cyrus-be/ssd-part/L/user//2185. =>
> /srv/cyrus-hdd-be/archive/ssd-part/L/user//2185.): Unknown code
> 255
Ouch. Yeah, that could have been caused by a bug in delivery, and would
definitely cause conversations DB corruption if the index file was updated but
the conversations DB wasn't or vice versa.
> The file was already at /srv/cyrus-hdd-be/archive/ssd-part/L/user//2185.
Right! I do wonder if there are some bugs in 3.0.x which are fixed on master
around delivery to archive partition. We definitely had bugs on master, but I
thought they were newly introduced on master as well, which is why the fixes
weren't backported. But if you're having files be in the wrong location, maybe
there are bugs on 3.0.x as well.
Do you have the syslog lines at the time that email was delivered?
Bron.
--
Bron Gondwana
br...@fastmail.fm
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: another problem with conversations db
Hi,
Quoting Bron Gondwana :
Hi Michael,
Sorry about the delay in looking at this - I was mad crazy busy
getting ready to go overseas. At Fosdem now, about to give a talk
about JMAP!
OK, let's start with the things that give me a little bit of hives...
configdirectory: /srv/cyrus-be
partition-default: /srv/cyrus-be
partition-ssd: /srv/cyrus-be/ssd-part
Ouch. There's a couple of things I wouldn't do there - having the
partition be the same as the config directory, and having a separate
partition be a subdirectory of a partition. They're both asking for
trouble. I would probably lay my system out like:
configdirectory: /srv/cyrus-be/conf
partition-default: /srv/cyrus-be/default-part
partition-ssd: /srv/cyrus-be/ssd-part
partition-default isn't used any more. To use the metapartition we moved
all accounts form the default partition to the ssd partition which is the
the new defaultpartition ("defaultpartition: ssd")
And then each tree would only have one type of thing in it.
Anyway, I don't think that would break anything.
metapartition-ssd: /srv/cyrus-ssd-be/meta/ssd-part
metapartition_files: header index cache expunge squat annotations
lock dav archivecache
Ooh, I haven't tested having cache and archivecache on the same
location. That's really interesting. Again, I'd be in favour of
separation here, give them different paths. That might be tricky
with ssd though, the way this is laid out. I assume you have some
kind of symlink farm going on?
I didn't know that there could be a problem with cache and archivecache.
At the time we decided on the configuration for cyrus 3.0 I looked at the
imapd.conf man page and for metapartition_files decided that I want all
meta files on the ssd storage. There was no indication in the man page
that there could be a problem.
How do I separate location of archivecache from the other metapartition path?
And fix the cache and archivecache files?
No there is no sysmlink farm. We have mounted different iSCSI volumes to
/srv/cyrus-ssd-be, /srv/cyrus-hdd-be and /srv/cyrus-be
Otherwise it all looks OK. Are you getting other IOERRORs in your
log files which could show things aborting? It really looks like
your conversations DB is getting out of sync due to other failures.
I found a few instances of 3 related errors.
Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR: opening
/srv/cyrus-be/ssd-part/L/user//2185.: No such file or directory
Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR: opening
/srv/cyrus-be/ssd-part/L/user//2185.: No such file or directory
Feb 4 01:10:55 mailserv03 be/cyr_expire[7626]: IOERROR archive
user. 2185 failed to copyfile
(/srv/cyrus-be/ssd-part/L/user//2185. =>
/srv/cyrus-hdd-be/archive/ssd-part/L/user//2185.): Unknown code
255
The file was already at /srv/cyrus-hdd-be/archive/ssd-part/L/user//2185.
stat 2185.
File: '2185.'
Size: 424542 Blocks: 832IO Block: 4096 regular file
Device: 860h/2144d Inode: 4677438462 Links: 1
Access: (0600/-rw---) Uid: ( 96/ cyrus) Gid: ( 12/mail)
Context: system_u:object_r:unlabeled_t:s0
Access: 2018-11-27 01:12:46.585864239 +0100
Modify: 2018-11-27 01:12:46.585864239 +0100
Change: 2018-11-27 01:12:46.585864239 +0100
Birth: -
Cheers,
Bron.
On Thu, Jan 31, 2019, at 19:36, Michael Menge wrote:
Quoting Bron Gondwana :
> On Fri, Jan 25, 2019, at 20:00, Michael Menge wrote:
>> Hi Bron
>>
>>
>> Quoting Bron Gondwana :
>>
>> > Sorry I haven't been following along with this earlier. Can you post
>> > your imapd.conf and cyrus.conf as well as let her know if you run
>> > anything which directly messes with files on disk.
>>
>> Thanks for looking into it. I have attached the backend and replica
>> configs. There should be nothing messing with the files on disk
>> directly. Some times we need to restore mails from file based
>> backup (bacula) followed by a reconstruct but this was not the
>> case this time.
>
> Do you always rebuild the conversations db after doing the
> reconstruct? That will be necessary now. We switched to doing all
> our restores using IMAP append a while back so we're never fiddling
> the file system under Cyrus.
>
>> >
>> > Also, what operating system is this on and what Cyrus version?
>> >
>>
>> We are running a cyrus 3.0.8 compiled with the following Options
>> (./configure --enable-murder --enable-http --enable-calalarmd
>> --enable-replication --enable-backup --enable-idled
>> --enable-autocreate CFLAGS="-fPIC -g")
>> in a murder configuration on a RHEL 7.5 System. As filesystem we use xfs.
>
> They should be fine. I'll have a read of the config when I'm at a
> real computer.
>
did you find anything in the config that would explain the problems?
>>
>> > Bron.
>> >
>> > On Fri, Jan 25, 2019, at 04:08, Michael Menge wrote:
>> >> Hi,
>> >>
>> >> I have discovered an other problem with the conversations db:
>> >>
>> >> Thousends of lines with
Re: Fatal error: Exists wrong 513 512 483 17057
Oh how frustrating... On Mon, Feb 4, 2019, at 08:48, Daniel Bareiro wrote: > Hi, Bron. Thanks for your reply. > > On 3/2/19 08:33, Bron Gondwana wrote: > > > Wow. A reconstruct should fix that. What version are you running? > > I tried using 'reconstruct' as you suggested and this was the result: > > -- > # /usr/lib/cyrus/bin/reconstruct -r user.admin > user.admin > user.admin.Backups > user.admin.Drafts > user.admin.Sent > user.admin.TareasCron: record corrupted 13 (maybe uid 9836) > user.admin.TareasCron: Mailbox format corruption detected Failed to > reconstruct mailbox This clearly isn't syslogging enough! Can you check the permissions on the underlying filesystem! Also, try running reconstruct with -G, though it shouldn't make a difference. > user.admin.Trash > -- > > Just 'TasksCron' is the folder that I can not open. What do you suggest > to do in this case? I'd take a backup, and then delete the cyrus.index file in that folder and run reconstruct again... That's a pretty extreme approach, but it should work. > I'm using Cyrus 2.5.10-3 on Debian Stretch. A few days ago I upgraded > the entire operating system with Debian Jessie and Cyrus 2.4.17. That upgrade should be fine, and 2.5.10 should be fine as well. I just poked around in the code there to see how the reconstruct might be failing, and there's not enough information to know what's happening. Bron. -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
