Discussion:
Slow start of imap service
Paul van der Vlis
2018-09-28 12:34:53 UTC
Permalink
Hello,

I am using Cyrus-imapd from Debian stable (2.5.10-3), and starting up
takes very long. I see processes starting, but no imapd.

In most cases I restart Cyrus more then ones before it works. Not sure I
have to wait longer, or restarting after some time helps.

This problem occurs on only one machine, on two other less busy machine
with the same Cyrus I don't have problems.

Maybe somebody here knows more about what could be wrong? Or how to
debug this?

(Cyrus-imapd from Debian has some problems, for this reason I restart
the service every night using a crontab.)

With regards,
Paul van der Vlis
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Michael Menge
2018-09-28 13:34:46 UTC
Permalink
Post by Paul van der Vlis
Hello,
I am using Cyrus-imapd from Debian stable (2.5.10-3), and starting up
takes very long. I see processes starting, but no imapd.
In most cases I restart Cyrus more then ones before it works. Not sure I
have to wait longer, or restarting after some time helps.
This problem occurs on only one machine, on two other less busy machine
with the same Cyrus I don't have problems.
Maybe somebody here knows more about what could be wrong? Or how to
debug this?
What is cyrus logging to your logfiles when you restart?
What is in the START section of your /etc/cyrus.conf?

Regards

Michael

--------------------------------------------------------------------------------
M.Menge Tel.: (49) 7071/29-70316
Universität Tübingen Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung mail:
***@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:
htt
Paul van der Vlis
2018-09-28 22:59:01 UTC
Permalink
Post by Michael Menge
Post by Paul van der Vlis
Hello,
I am using Cyrus-imapd from Debian stable (2.5.10-3), and starting up
takes very long. I see processes starting, but no imapd.
In most cases I restart Cyrus more then ones before it works. Not sure I
have to wait longer, or restarting after some time helps.
This problem occurs on only one machine, on two other less busy machine
with the same Cyrus I don't have problems.
Maybe somebody here knows more about what could be wrong? Or how to
debug this?
What is cyrus logging to your logfiles when you restart?
In my crontab I have this line:
00 4 * * * root /usr/sbin/service cyrus-imapd restart

First I see many of this lines in /var/log/mail.log:
Sep 25 04:00:01 sigmund cyrus/imap[21598]: graceful shutdown

Then I see this between those lines this:
-----
Sep 25 04:00:02 sigmund cyrus/idled[5844]: graceful shutdown initiated
by unexpected process 5838 (/usr/sbin/cyrmaster -l 32 -C /etc/imapd.conf
-M /etc/cyrus.conf)
Sep 25 04:00:02 sigmund cyrus/imaps[16434]: IDLE: error sending message
DONE to idled for mailbox user.nospam.Junk: Connection refused.
-----

This line:
Sep 25 04:00:02 sigmund cyrus/master[5838]: process type:SERVICE
name:notify path:/usr/lib/cyrus/bin/notifyd age:85080.426s pid:6024
exited, status 75

Many of these lines:
Sep 25 04:00:02 sigmund cyrus/master[5838]: process type:SERVICE
name:imap path:/usr/lib/cyrus/bin/imapd age:85073.234s pid:6027 exited,
status 75

Then this:
--------
Sep 25 04:00:05 sigmund cyrus/ctl_cyrusdb[21829]: skiplist: clean
shutdown file missing, updating recovery stamp
Sep 25 04:00:05 sigmund cyrus/ctl_cyrusdb[21829]: recovering cyrus databases
Sep 25 04:00:05 sigmund cyrus/ctl_cyrusdb[21829]: done recovering cyrus
databases
Sep 25 04:00:05 sigmund cyrus/cyr_expire[21834]: skiplist: recovered
/var/lib/cyrus/deliver.db (9290 records, 1759220 bytes) in 0 seconds
Sep 25 04:00:05 sigmund cyrus/cyr_expire[21834]: skiplist: checkpointed
/var/lib/cyrus/deliver.db (9290 records, 1412288 bytes) in 0.227 sec
Sep 25 04:00:19 sigmund cyrus/cyr_expire[21834]: Expired 0 and expunged
0 out of 1312483 messages from 2984 mailboxes
Sep 25 04:00:19 sigmund cyrus/cyr_expire[21834]: duplicate_prune:
pruning back 3.00 days
Sep 25 04:00:30 sigmund cyrus/cyr_expire[21834]: skiplist: longlock
/var/lib/cyrus/deliver.db for 1.8 seconds
Sep 25 04:00:33 sigmund cyrus/cyr_expire[21834]: skiplist: longlock
/var/lib/cyrus/deliver.db for 2.2 seconds
Sep 25 04:00:39 sigmund cyrus/cyr_expire[21834]: skiplist: longlock
/var/lib/cyrus/deliver.db for 1.3 seconds
Sep 25 04:05:36 sigmund cyrus/cyr_expire[21834]: duplicate_prune: purged
2217 out of 9290 entries
Sep 25 04:05:36 sigmund cyrus/tls_prune[21860]: skiplist: recovered
/var/lib/cyrus/tls_sessions.db (10219 records, 2235748 bytes) in 0 seconds
Sep 25 04:05:36 sigmund cyrus/tls_prune[21860]: skiplist: checkpointed
/var/lib/cyrus/tls_sessions.db (10219 records, 2147768 bytes) in 0.308 sec
Sep 25 04:09:47 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.4 seconds
Sep 25 04:10:23 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 2.2 seconds
Sep 25 04:10:45 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 2.2 seconds
Sep 25 04:12:21 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.3 seconds
Sep 25 04:12:47 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.0 seconds
Sep 25 04:12:49 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.8 seconds
Sep 25 04:17:33 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.0 seconds
Sep 25 04:23:11 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.0 seconds
Sep 25 04:25:31 sigmund cyrus/tls_prune[21860]: tls_prune: purged 4463
out of 10219 entries
Sep 25 04:25:31 sigmund cyrus/master[21826]: unable to
setsocketopt(IP_TOS) service lmtpunix/unix: Operation not supported
Sep 25 04:25:31 sigmund cyrus/master[21826]: unable to
setsocketopt(IP_TOS) service notify/unix: Operation not supported
Sep 25 04:25:31 sigmund cyrus/ctl_cyrusdb[22345]: checkpointing cyrus
databases
Sep 25 04:25:31 sigmund cyrus/ctl_cyrusdb[22345]: done checkpointing
cyrus databases
Sep 25 04:25:32 sigmund cyrus/imaps[22349]: inittls: Loading hard-coded
DH parameters
Sep 25 04:25:33 sigmund cyrus/imaps[22349]: starttls: TLSv1.2 with
cipher ECDHE-RSA-AES128-SHA (128/128 bits new) no authentication
Sep 25 04:26:20 sigmund cyrus/imap[22362]: inittls: Loading hard-coded
DH parameters
Sep 25 04:26:20 sigmund cyrus/imap[22363]: inittls: Loading hard-coded
DH parameters
---------

So you can see imap is active after 25 minutes...
Post by Michael Menge
What is in the START section of your /etc/cyrus.conf?
----
START {
# do not delete this entry!
recover cmd="/usr/sbin/cyrus ctl_cyrusdb -r"

# this is only necessary if idlemethod is set to "idled" in
# imapd.conf
idled cmd="idled"

# this is useful on backend nodes of a Murder cluster
# it causes the backend to syncronize its mailbox list with
# the mupdate master upon startup
#mupdatepush cmd="/usr/sbin/cyrus ctl_mboxlist -m"

# this is recommended if using duplicate delivery suppression
delprune cmd="/usr/sbin/cyrus expire -E 3"
# this is recommended if caching TLS sessions
tlsprune cmd="/usr/sbin/cyrus tls_prune"
}
---------

Thanks for you help!

With regards,
Paul van der Vlis
Post by Michael Menge
Regards
   Michael
--------------------------------------------------------------------------------
M.Menge                                Tel.: (49) 7071/29-70316
Universität Tübingen                   Fax.: (49) 7071/29-5912
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/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://l
ellie timoney
2018-10-01 02:32:03 UTC
Permalink
Post by Paul van der Vlis
Post by Michael Menge
Post by Paul van der Vlis
Hello,
I am using Cyrus-imapd from Debian stable (2.5.10-3), and starting up
takes very long. I see processes starting, but no imapd.
In most cases I restart Cyrus more then ones before it works. Not sure I
have to wait longer, or restarting after some time helps.
This problem occurs on only one machine, on two other less busy machine
with the same Cyrus I don't have problems.
Maybe somebody here knows more about what could be wrong? Or how to
debug this?
What is cyrus logging to your logfiles when you restart?
00 4 * * * root /usr/sbin/service cyrus-imapd restart
Sep 25 04:00:01 sigmund cyrus/imap[21598]: graceful shutdown
-----
Sep 25 04:00:02 sigmund cyrus/idled[5844]: graceful shutdown initiated
by unexpected process 5838 (/usr/sbin/cyrmaster -l 32 -C /etc/imapd.conf
-M /etc/cyrus.conf)
Sep 25 04:00:02 sigmund cyrus/imaps[16434]: IDLE: error sending message
DONE to idled for mailbox user.nospam.Junk: Connection refused.
-----
Sep 25 04:00:02 sigmund cyrus/master[5838]: process type:SERVICE
name:notify path:/usr/lib/cyrus/bin/notifyd age:85080.426s pid:6024
exited, status 75
Sep 25 04:00:02 sigmund cyrus/master[5838]: process type:SERVICE
name:imap path:/usr/lib/cyrus/bin/imapd age:85073.234s pid:6027 exited,
status 75
--------
Sep 25 04:00:05 sigmund cyrus/ctl_cyrusdb[21829]: skiplist: clean
shutdown file missing, updating recovery stamp
Sep 25 04:00:05 sigmund cyrus/ctl_cyrusdb[21829]: recovering cyrus databases
Sep 25 04:00:05 sigmund cyrus/ctl_cyrusdb[21829]: done recovering cyrus
databases
Sep 25 04:00:05 sigmund cyrus/cyr_expire[21834]: skiplist: recovered
/var/lib/cyrus/deliver.db (9290 records, 1759220 bytes) in 0 seconds
Sep 25 04:00:05 sigmund cyrus/cyr_expire[21834]: skiplist: checkpointed
/var/lib/cyrus/deliver.db (9290 records, 1412288 bytes) in 0.227 sec
Sep 25 04:00:19 sigmund cyrus/cyr_expire[21834]: Expired 0 and expunged
0 out of 1312483 messages from 2984 mailboxes
pruning back 3.00 days
Sep 25 04:00:30 sigmund cyrus/cyr_expire[21834]: skiplist: longlock
/var/lib/cyrus/deliver.db for 1.8 seconds
Sep 25 04:00:33 sigmund cyrus/cyr_expire[21834]: skiplist: longlock
/var/lib/cyrus/deliver.db for 2.2 seconds
Sep 25 04:00:39 sigmund cyrus/cyr_expire[21834]: skiplist: longlock
/var/lib/cyrus/deliver.db for 1.3 seconds
Sep 25 04:05:36 sigmund cyrus/cyr_expire[21834]: duplicate_prune: purged
2217 out of 9290 entries
Sep 25 04:05:36 sigmund cyrus/tls_prune[21860]: skiplist: recovered
/var/lib/cyrus/tls_sessions.db (10219 records, 2235748 bytes) in 0 seconds
Sep 25 04:05:36 sigmund cyrus/tls_prune[21860]: skiplist: checkpointed
/var/lib/cyrus/tls_sessions.db (10219 records, 2147768 bytes) in 0.308 sec
Sep 25 04:09:47 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.4 seconds
Sep 25 04:10:23 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 2.2 seconds
Sep 25 04:10:45 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 2.2 seconds
Sep 25 04:12:21 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.3 seconds
Sep 25 04:12:47 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.0 seconds
Sep 25 04:12:49 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.8 seconds
Sep 25 04:17:33 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.0 seconds
Sep 25 04:23:11 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.0 seconds
Sep 25 04:25:31 sigmund cyrus/tls_prune[21860]: tls_prune: purged 4463
out of 10219 entries
Sep 25 04:25:31 sigmund cyrus/master[21826]: unable to
setsocketopt(IP_TOS) service lmtpunix/unix: Operation not supported
Sep 25 04:25:31 sigmund cyrus/master[21826]: unable to
setsocketopt(IP_TOS) service notify/unix: Operation not supported
Sep 25 04:25:31 sigmund cyrus/ctl_cyrusdb[22345]: checkpointing cyrus
databases
Sep 25 04:25:31 sigmund cyrus/ctl_cyrusdb[22345]: done checkpointing
cyrus databases
Sep 25 04:25:32 sigmund cyrus/imaps[22349]: inittls: Loading hard-coded
DH parameters
Sep 25 04:25:33 sigmund cyrus/imaps[22349]: starttls: TLSv1.2 with
cipher ECDHE-RSA-AES128-SHA (128/128 bits new) no authentication
Sep 25 04:26:20 sigmund cyrus/imap[22362]: inittls: Loading hard-coded
DH parameters
Sep 25 04:26:20 sigmund cyrus/imap[22363]: inittls: Loading hard-coded
DH parameters
---------
So you can see imap is active after 25 minutes...
Post by Michael Menge
What is in the START section of your /etc/cyrus.conf?
----
START {
# do not delete this entry!
recover cmd="/usr/sbin/cyrus ctl_cyrusdb -r"
# this is only necessary if idlemethod is set to "idled" in
# imapd.conf
idled cmd="idled"
# this is useful on backend nodes of a Murder cluster
# it causes the backend to syncronize its mailbox list with
# the mupdate master upon startup
#mupdatepush cmd="/usr/sbin/cyrus ctl_mboxlist -m"
# this is recommended if using duplicate delivery suppression
delprune cmd="/usr/sbin/cyrus expire -E 3"
# this is recommended if caching TLS sessions
tlsprune cmd="/usr/sbin/cyrus tls_prune"
}
---------
Thanks for you help!
With regards,
Paul van der Vlis
Sep 25 04:05:36 sigmund cyrus/tls_prune[21860]: skiplist: recovered
/var/lib/cyrus/tls_sessions.db (10219 records, 2235748 bytes) in 0 seconds
Sep 25 04:05:36 sigmund cyrus/tls_prune[21860]: skiplist: checkpointed
/var/lib/cyrus/tls_sessions.db (10219 records, 2147768 bytes) in 0.308 sec
[...]
Sep 25 04:25:31 sigmund cyrus/tls_prune[21860]: tls_prune: purged 4463
out of 10219 entries
You could use the tls_sessions_db_path imapd.conf(5) option to put this database onto faster storage?
Post by Paul van der Vlis
tls_sessions_db_path: <none>
The absolute path to the TLS sessions db file. If not specified, will be
configdirectory/tls_sessions.db
If you have the RAM for it, you should be able to put tls_sessions.db on a tmpfs filesystem. This database is only a cache, so nothing valuable will be lost if the machine is rebooted; and as a cache, it benefits from being on the fastest storage you have available. :)

Cheers,

ellie
ellie timoney
2018-10-01 03:13:24 UTC
Permalink
Post by ellie timoney
You could use the tls_sessions_db_path imapd.conf(5) option to put this
database onto faster storage?
Post by Paul van der Vlis
tls_sessions_db_path: <none>
The absolute path to the TLS sessions db file. If not specified, will be
configdirectory/tls_sessions.db
If you have the RAM for it, you should be able to put tls_sessions.db on
a tmpfs filesystem. This database is only a cache, so nothing valuable
will be lost if the machine is rebooted; and as a cache, it benefits
from being on the fastest storage you have available. :)
Buuut, note that there's a bug in current releases of 2.5 where tls_prune will fail if the tls_sessions.db doesn't exist, preventing the server starting up. This will occur after ever reboot if you put this database on ephemeral storage! You can work around this by having your service init script touch the file before running master.

The real fix for this is already in git, so it will be included in 2.5.12, which will hopefully be out this week!

Cheers,

ellie
Paul van der Vlis
2018-10-01 08:32:14 UTC
Permalink
Post by ellie timoney
Post by ellie timoney
You could use the tls_sessions_db_path imapd.conf(5) option to put this
database onto faster storage?
Post by Paul van der Vlis
tls_sessions_db_path: <none>
The absolute path to the TLS sessions db file. If not specified, will be
configdirectory/tls_sessions.db
If you have the RAM for it, you should be able to put tls_sessions.db on
a tmpfs filesystem. This database is only a cache, so nothing valuable
will be lost if the machine is rebooted; and as a cache, it benefits
from being on the fastest storage you have available. :)
Buuut, note that there's a bug in current releases of 2.5 where tls_prune will fail if the tls_sessions.db doesn't exist, preventing the server starting up. This will occur after ever reboot if you put this database on ephemeral storage! You can work around this by having your service init script touch the file before running master.
When I understand you well, I could also remove the database and create
an empty file before starting. As a work-arround.
Post by ellie timoney
The real fix for this is already in git, so it will be included in 2.5.12, which will hopefully be out this week!
My problem is that I use the version in Debian, what is not good
maintained at the moment. Cyrus-imap is removed from Debian testing last
year. This means that when nobody cares, Cyrus will not be in the next
Debian version. And also not in many other Linux distro's like Ubuntu.
The freeze is in Januar/Februar.

https://tracker.debian.org/news/859151/cyrus-imapd-removed-from-testing/
https://tracker.debian.org/pkg/cyrus-imapd
https://release.debian.org/#release-dates

You will say: use the upstream version. But sorry, I have to worry about
many programs. My choice at the moment is to use software what's in
Debian. I am using Cyrus imap about 17 years now, but it's possible I
even have to switch to something else for this reason.

Much thanks for your support!

With regards,
Paul
Post by ellie timoney
Cheers,
ellie
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Paul van der Vlis
2018-10-01 22:56:06 UTC
Permalink
Post by Paul van der Vlis
Post by ellie timoney
Post by ellie timoney
You could use the tls_sessions_db_path imapd.conf(5) option to put this
database onto faster storage?
Post by Paul van der Vlis
tls_sessions_db_path: <none>
The absolute path to the TLS sessions db file. If not specified, will be
configdirectory/tls_sessions.db
If you have the RAM for it, you should be able to put tls_sessions.db on
a tmpfs filesystem. This database is only a cache, so nothing valuable
will be lost if the machine is rebooted; and as a cache, it benefits
from being on the fastest storage you have available. :)
Buuut, note that there's a bug in current releases of 2.5 where tls_prune will fail if the tls_sessions.db doesn't exist, preventing the server starting up. This will occur after ever reboot if you put this database on ephemeral storage! You can work around this by having your service init script touch the file before running master.
When I understand you well, I could also remove the database and create
an empty file before starting. As a work-arround.
I do this now, and restarting takes now 2-3 minutes. So much better.
But I will also investigatie for faster storage or tmpfs.

With regards,
Paul van der Vlis
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Paul van der Vlis
2018-10-01 08:04:57 UTC
Permalink
Post by ellie timoney
Post by Paul van der Vlis
Post by Michael Menge
Post by Paul van der Vlis
Hello,
I am using Cyrus-imapd from Debian stable (2.5.10-3), and starting up
takes very long. I see processes starting, but no imapd.
In most cases I restart Cyrus more then ones before it works. Not sure I
have to wait longer, or restarting after some time helps.
This problem occurs on only one machine, on two other less busy machine
with the same Cyrus I don't have problems.
Maybe somebody here knows more about what could be wrong? Or how to
debug this?
What is cyrus logging to your logfiles when you restart?
00 4 * * * root /usr/sbin/service cyrus-imapd restart
Sep 25 04:00:01 sigmund cyrus/imap[21598]: graceful shutdown
-----
Sep 25 04:00:02 sigmund cyrus/idled[5844]: graceful shutdown initiated
by unexpected process 5838 (/usr/sbin/cyrmaster -l 32 -C /etc/imapd.conf
-M /etc/cyrus.conf)
Sep 25 04:00:02 sigmund cyrus/imaps[16434]: IDLE: error sending message
DONE to idled for mailbox user.nospam.Junk: Connection refused.
-----
Sep 25 04:00:02 sigmund cyrus/master[5838]: process type:SERVICE
name:notify path:/usr/lib/cyrus/bin/notifyd age:85080.426s pid:6024
exited, status 75
Sep 25 04:00:02 sigmund cyrus/master[5838]: process type:SERVICE
name:imap path:/usr/lib/cyrus/bin/imapd age:85073.234s pid:6027 exited,
status 75
--------
Sep 25 04:00:05 sigmund cyrus/ctl_cyrusdb[21829]: skiplist: clean
shutdown file missing, updating recovery stamp
Sep 25 04:00:05 sigmund cyrus/ctl_cyrusdb[21829]: recovering cyrus databases
Sep 25 04:00:05 sigmund cyrus/ctl_cyrusdb[21829]: done recovering cyrus
databases
Sep 25 04:00:05 sigmund cyrus/cyr_expire[21834]: skiplist: recovered
/var/lib/cyrus/deliver.db (9290 records, 1759220 bytes) in 0 seconds
Sep 25 04:00:05 sigmund cyrus/cyr_expire[21834]: skiplist: checkpointed
/var/lib/cyrus/deliver.db (9290 records, 1412288 bytes) in 0.227 sec
Sep 25 04:00:19 sigmund cyrus/cyr_expire[21834]: Expired 0 and expunged
0 out of 1312483 messages from 2984 mailboxes
pruning back 3.00 days
Sep 25 04:00:30 sigmund cyrus/cyr_expire[21834]: skiplist: longlock
/var/lib/cyrus/deliver.db for 1.8 seconds
Sep 25 04:00:33 sigmund cyrus/cyr_expire[21834]: skiplist: longlock
/var/lib/cyrus/deliver.db for 2.2 seconds
Sep 25 04:00:39 sigmund cyrus/cyr_expire[21834]: skiplist: longlock
/var/lib/cyrus/deliver.db for 1.3 seconds
Sep 25 04:05:36 sigmund cyrus/cyr_expire[21834]: duplicate_prune: purged
2217 out of 9290 entries
Sep 25 04:05:36 sigmund cyrus/tls_prune[21860]: skiplist: recovered
/var/lib/cyrus/tls_sessions.db (10219 records, 2235748 bytes) in 0 seconds
Sep 25 04:05:36 sigmund cyrus/tls_prune[21860]: skiplist: checkpointed
/var/lib/cyrus/tls_sessions.db (10219 records, 2147768 bytes) in 0.308 sec
Sep 25 04:09:47 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.4 seconds
Sep 25 04:10:23 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 2.2 seconds
Sep 25 04:10:45 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 2.2 seconds
Sep 25 04:12:21 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.3 seconds
Sep 25 04:12:47 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.0 seconds
Sep 25 04:12:49 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.8 seconds
Sep 25 04:17:33 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.0 seconds
Sep 25 04:23:11 sigmund cyrus/tls_prune[21860]: skiplist: longlock
/var/lib/cyrus/tls_sessions.db for 1.0 seconds
Sep 25 04:25:31 sigmund cyrus/tls_prune[21860]: tls_prune: purged 4463
out of 10219 entries
Sep 25 04:25:31 sigmund cyrus/master[21826]: unable to
setsocketopt(IP_TOS) service lmtpunix/unix: Operation not supported
Sep 25 04:25:31 sigmund cyrus/master[21826]: unable to
setsocketopt(IP_TOS) service notify/unix: Operation not supported
Sep 25 04:25:31 sigmund cyrus/ctl_cyrusdb[22345]: checkpointing cyrus
databases
Sep 25 04:25:31 sigmund cyrus/ctl_cyrusdb[22345]: done checkpointing
cyrus databases
Sep 25 04:25:32 sigmund cyrus/imaps[22349]: inittls: Loading hard-coded
DH parameters
Sep 25 04:25:33 sigmund cyrus/imaps[22349]: starttls: TLSv1.2 with
cipher ECDHE-RSA-AES128-SHA (128/128 bits new) no authentication
Sep 25 04:26:20 sigmund cyrus/imap[22362]: inittls: Loading hard-coded
DH parameters
Sep 25 04:26:20 sigmund cyrus/imap[22363]: inittls: Loading hard-coded
DH parameters
---------
So you can see imap is active after 25 minutes...
Post by Michael Menge
What is in the START section of your /etc/cyrus.conf?
----
START {
# do not delete this entry!
recover cmd="/usr/sbin/cyrus ctl_cyrusdb -r"
# this is only necessary if idlemethod is set to "idled" in
# imapd.conf
idled cmd="idled"
# this is useful on backend nodes of a Murder cluster
# it causes the backend to syncronize its mailbox list with
# the mupdate master upon startup
#mupdatepush cmd="/usr/sbin/cyrus ctl_mboxlist -m"
# this is recommended if using duplicate delivery suppression
delprune cmd="/usr/sbin/cyrus expire -E 3"
# this is recommended if caching TLS sessions
tlsprune cmd="/usr/sbin/cyrus tls_prune"
}
---------
Thanks for you help!
With regards,
Paul van der Vlis
Sep 25 04:05:36 sigmund cyrus/tls_prune[21860]: skiplist: recovered
/var/lib/cyrus/tls_sessions.db (10219 records, 2235748 bytes) in 0 seconds
Sep 25 04:05:36 sigmund cyrus/tls_prune[21860]: skiplist: checkpointed
/var/lib/cyrus/tls_sessions.db (10219 records, 2147768 bytes) in 0.308 sec
[...]
Sep 25 04:25:31 sigmund cyrus/tls_prune[21860]: tls_prune: purged 4463
out of 10219 entries
Thanks for your conclusion!
Post by ellie timoney
You could use the tls_sessions_db_path imapd.conf(5) option to put this database onto faster storage?
Post by Paul van der Vlis
tls_sessions_db_path: <none>
The absolute path to the TLS sessions db file. If not specified, will be
configdirectory/tls_sessions.db
Interesting...

I use normal harddisks with software raid and LVM. And a qcow2-image for
the virtualisation.
Post by ellie timoney
If you have the RAM for it, you should be able to put tls_sessions.db on a tmpfs filesystem. This database is only a cache, so nothing valuable will be lost if the machine is rebooted; and as a cache, it benefits from being on the fastest storage you have available. :)
I will think about it, not sure how big it is.

With regards,
Paul van der Vlis
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Loading...