Storage server failed

[Hernan Saltiel]

Hi Daniel,
Thanks a lot for your answer!
I'll create a script to check this every minute, and restart those service
in case of death.
What can be the root cause of this? Can this happen because of the night
backup process, pushing the disks to have higher I/O? (higher is less than
30%, but is higher than the usual, that is almost 1%)
Thanks again, and best regards,
HeCSa.


On Fri, May 15, 2020 at 10:26 AM Daniel Hoffend <dh at dotlan.net> wrote:

> Hi Hernan
>
> Storage Server fails means that roundcubemail is not able to community
> or authenticate with the backend (aka imap server port 143).
>
> I would check the following points
> * is guam running (systemctl status guam). Guam is the imap proxy
> sitting
>    in front of cyrus.
> * is cyrus-imapd server running (process table)
> * do you see any authentication related error messages from cyrus
> * is kolab-saslauthd and/or dirsrv running correctly?
> * is kolabd running?
>
> Another thing could be that guam/cyrus is running but the kolabd server
> has not created the mailbox yet. Restarting/Checking kolabd might help
> (as well checking the pykolab logfiles). Otherwise run "kolab sync" via
> cli to execute the mailbox sync/creating run manually.
>
> --
> regards
> Daniel Hoffend
>
>
> Am 2020-05-14 15:05, schrieb Hernan Saltiel:
> > Hi everybody!
> > Hope you are doing well.
> > I'm sending this email because of a strange issue I'm having using
> > Kolab 16 on CentOS 7.7.
> > We are in the process of migrating users from an old Kolab to this new
> > one, and starting a week ago, every morning the users are telling us
> > that they cannot connect to the server. The clients appear to be
> > disconnected.
> > Trying to access the server via webmail, I see a "server storage
> > failed" message.
> > Checking the docs, it seems to be a Cyrus related issue...on the docs
> > I can see:
> >
> > "...
> > In Kolab Groupware, this data storage layer is the IMAP spool,
> > accessible by any client software that speaks the IMAP protocol.
> > Kolab Groupware ships Cyrus IMAP by default, which, with its so-called
> > murder topology, provides the aforementioned transparent access to
> > IMAP spools spread out over multiple individual systems.
> > ..."
> >
> > On messages I do not see any "max connections reached", or something
> > like this.
> >
> > Did anybody had the same issue, or has some tip about where to start
> > digging?
> >
> > Thanks a lot in advance, and best regards,
> >
> > --
> > HeCSa
> > _______________________________________________
> > users mailing list
> > users at lists.kolab.org
> > https://lists.kolab.org/mailman/listinfo/users
>


-- 
HeCSa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20200515/c156ba67/attachment.html>