<div dir="ltr"><div dir="ltr">On Wed, Jul 3, 2019 at 12:31 PM Jan Kowalsky <<a href="mailto:jankow@datenkollektiv.net">jankow@datenkollektiv.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Dashamir,<br>
<br>
sorry, it took some time for answering. Did you got any success meanwhile?<br>
<br>
Am 27.06.19 um 18:40 schrieb Dashamir Hoxha:<br>
> On Thu, Jun 27, 2019 at 3:11 PM Dashamir Hoxha <<a href="mailto:dashohoxha@gmail.com" target="_blank">dashohoxha@gmail.com</a>> wrote:<br>
> <br>
<br>
>><br>
>> The only messages that I can find on `/var/log/mail.log` are these<br>
>> (immediately after I try `systemctl start cyrus-imapd`):<br>
>> ```<br>
>> Jun 27 09:58:12 kolab ctl_cyrusdb[767]: skiplist: clean shutdown file<br>
>> missing, updating recovery stamp<br>
>> Jun 27 09:58:12 kolab ctl_cyrusdb[767]: recovering cyrus databases<br>
>> Jun 27 09:58:12 kolab ctl_cyrusdb[767]: done recovering cyrus databases<br>
>> Jun 27 09:58:12 kolab master[766]: process type:START name:idled<br>
>> path:/usr/lib/cyrus-imapd/idled age:0.000s pid:768 exited, status 1<br>
>> Jun 27 09:58:12 kolab master[766]: can't run startup<br>
>> Jun 27 09:58:12 kolab master[766]: exiting<br>
>> ```<br>
<br>
it looks like a problem with idled process.<br>
<br>
could you run cyrus from command line in debugging mode?<br>
<br>
cyrus-master -D<br>
<br>
(<a href="https://linux.die.net/man/8/cyrus-master" rel="noreferrer" target="_blank">https://linux.die.net/man/8/cyrus-master</a>)<br>
<br>
>><br>
>>> As long we haven't more information it's hard to guess. One point which<br>
>>> comes in my mind are file access rights for cyrus. Since cyrus is<br>
>>> running as user cyrus the databases and the mailspool needs the rights<br>
>>> set accordingly.<br>
>>><br>
>><br>
>> The ownership seems to be Ok (cyrus:mail) on `/var/spool/imap` and<br>
>> `/var/lib/imap`.<br>
>> The restore script also takes care of them:<br>
>> <a href="https://gitlab.com/docker-scripts/kolab/blob/master/scripts/restore.sh#L47" rel="noreferrer" target="_blank">https://gitlab.com/docker-scripts/kolab/blob/master/scripts/restore.sh#L47</a><br>
>><br>
>> If you had access to the server, would you be willing to have a look an<br>
>> try to find where is the problem?<br>
>> I can install sshd on it and give you access.<br>
<br>
If the problem still exists: Please try to send some debugging<br>
information. But, if nothing helps, I could. But I have very little<br>
experience with docker and do not feel very comfortable without direct<br>
access to the cyrus instance ;-). Or is it a single container with full<br>
stack and ssh?<br>
<br>
good luck and kind regard.<br></blockquote><div><br></div><div>I did not have any luck yet.</div><div><br></div><div>The container is a full stack system, with systemd and everything else (including ssh), so you don't need any docker experience and you will have direct access to everything.</div><div><br></div><div>The problem is that I am currently trying another solution (mailcow). As soon as I am done with this I may have another look at kolab (it is not possible to run to mail servers in parallel since they need to use the same ports). If I can't fix the problem again, I may ask again for help.</div><div><br></div><div>However, if someone has time to have a look at it, the scripts for building the container are here: <a href="https://gitlab.com/docker-scripts/kolab">https://gitlab.com/docker-scripts/kolab</a></div><div>You can reproduce the problem by making first a backup (with `ds backup`), then rebuild the container (with `ds make`), then install kolab again (`kolab-setup`), then restore the backup (with `ds restore backup-file.tgz`).</div><div><br></div><div>Thank you for trying to help anyway.</div><div>Best regards,</div><div>Dashamir</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Jan<br>
</blockquote></div></div>