2.4.17 --> 2.5.3 Some mail folders no longer accessible
Upgrading from 2.4.17 to 2.5.3 resulted in one very strange problem. Some of the users have a large number of nested mail folders. After the upgrade, exactly one user found that some of his folders (say 3 out of 30) are now inaccessible. In Thunderbird they show up, but are greyed out. If you try to subscribe to the folder, the subscribe checkbox is missing. In roundcube they aren't visible at all. This is pretty clearly a permissions problem of some kind. The question is how could this happen and what's the least painless way of going about resetting the permissions so that he has access to these folders again? We're not doing anything fancy; for example, there are no shared folders; independent email addresses are configured for shared mail content and configured in the MUA. The problem folders are in an unshared account. Also, the manifestation of the permissions problem isn't consistent across the affected folders. As reported by the user: Archives Staff: grayed out, cannot see email Archives Staff Retreat: not grayed out, cannot see email, when you click on it, it says the action cannot be completed because the account does not exist General Convention Office: not grayed out, can see email, when you click on it, it says the action cannot be completed because the account does not exist. Thanks. 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: IMAP processes out of control
On Tue, 22 Sep 2015, Shaheen Bakhtiar wrote: It happened again….. although it took longer for it to happen, this has been happening only since the upgrade in Jun. The number of imap processes continues to increase until the server is completely OOM. the increase is drastic and all of a sudden. You should probably set maxchild to a value that won't run your server out of memory. :) Have you looked at the processes to see what they have in common? For example, sometimes an IMAP client will run amok and make hundreds or thousands of connections. Or perhaps the processes are all stuck waiting on a lock, etc. lsof, strace, netstat, and your Cyrus logs can help a lot. Andy 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: IMAP processes out of control
> On Sep 22, 2015, at 2:17 PM, Andrew Morgan wrote:
>
> On Tue, 22 Sep 2015, Shaheen Bakhtiar wrote:
>
>>
>> It happened again….. although it took longer for it to happen, this has been
>> happening only since the upgrade in Jun.
>>
>> The number of imap processes continues to increase until the server is
>> completely OOM. the increase is drastic and all of a sudden.
>
> You should probably set maxchild to a value that won't run your server out of
> memory. :)
>
> Have you looked at the processes to see what they have in common? For
> example, sometimes an IMAP client will run amok and make hundreds or
> thousands of connections. Or perhaps the processes are all stuck waiting on
> a lock, etc.
>
> lsof, strace, netstat, and your Cyrus logs can help a lot.
>
> Andy
[shawn@postoffice ~]$ ps aux | grep imapd | wc -l
255
[shawn@postoffice ~]# ps aux | grep imapds | wc -l
1
[shawn@postoffice ~]# ps aux | grep pop3d | wc -l
9
[shawn@postoffice ~]# ps aux | grep timseived | wc -l
1
[shawn@postoffice ~]# ps aux | grep lmtpunix | wc -l
1
Based on that output I changed the configuration file (below) adding maxchild.
Most likely all my users have their clients open, and from previous monitoring
I average about 200 instances of imapd:
# standard standalone server implementation
START {
# do not delete this entry!
recover cmd="ctl_cyrusdb -r"
# this is only necessary if using idled for IMAP IDLE
idled cmd="idled"
}
# UNIX sockets start with a slash and are put into /var/lib/imap/sockets
SERVICES {
# add or remove based on preferences
imap cmd="imapd" listen="imap" prefork=5 maxchild=300
imaps cmd="imapd -s" listen="imaps" prefork=1 maxchild=100
pop3 cmd="pop3d" listen="pop3" prefork=3 maxchild=5
pop3s cmd="pop3d -s" listen="pop3s" prefork=1 maxchild=5
sieve cmd="timsieved" listen="sieve" prefork=0
# these are only necessary if receiving/exporting usenet via NNTP
# nntp cmd="nntpd" listen="nntp" prefork=3
# nntpscmd="nntpd -s" listen="nntps" prefork=1
# at least one LMTP is required for delivery
# lmtp cmd="lmtpd" listen="lmtp" prefork=0
lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=1
# this is only necessary if using notifications
# notify cmd="notifyd" listen="/var/lib/imap/socket/notify" proto="udp"
prefork=1
}
EVENTS {
# this is required
checkpointcmd="ctl_cyrusdb -c" period=30
# this is only necessary if using duplicate delivery suppression,
# Sieve or NNTP
delprune cmd="cyr_expire -E 3" at=0400
# this is only necessary if caching TLS sessions
tlsprune cmd="tls_prune" at=0400
}
Comments, concerns??? I’m going to keep observium open on a separate screen and
watch when it starts going up, than do the lsof,netstat, and watch logs to see
if I can tell why the sudden upticks.
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: IMAP processes out of control
On 9/22/2015 18:12, Shaheen Bakhtiar wrote:
>> On Sep 22, 2015, at 2:17 PM, Andrew Morgan wrote:
>>
>> On Tue, 22 Sep 2015, Shaheen Bakhtiar wrote:
>>
>>> It happened again….. although it took longer for it to happen, this has
>>> been happening only since the upgrade in Jun.
>>>
>>> The number of imap processes continues to increase until the server is
>>> completely OOM. the increase is drastic and all of a sudden.
>> You should probably set maxchild to a value that won't run your server out
>> of memory. :)
>>
>> Have you looked at the processes to see what they have in common? For
>> example, sometimes an IMAP client will run amok and make hundreds or
>> thousands of connections. Or perhaps the processes are all stuck waiting on
>> a lock, etc.
>>
>> lsof, strace, netstat, and your Cyrus logs can help a lot.
>>
>> Andy
>
>
> [shawn@postoffice ~]$ ps aux | grep imapd | wc -l
> 255
> [shawn@postoffice ~]# ps aux | grep imapds | wc -l
> 1
> [shawn@postoffice ~]# ps aux | grep pop3d | wc -l
> 9
> [shawn@postoffice ~]# ps aux | grep timseived | wc -l
> 1
> [shawn@postoffice ~]# ps aux | grep lmtpunix | wc -l
> 1
>
> Based on that output I changed the configuration file (below) adding
> maxchild. Most likely all my users have their clients open, and from previous
> monitoring I average about 200 instances of imapd:
>
> # standard standalone server implementation
>
> START {
># do not delete this entry!
>recover cmd="ctl_cyrusdb -r"
>
># this is only necessary if using idled for IMAP IDLE
>idled cmd="idled"
> }
>
> # UNIX sockets start with a slash and are put into /var/lib/imap/sockets
> SERVICES {
># add or remove based on preferences
>imap cmd="imapd" listen="imap" prefork=5 maxchild=300
>imaps cmd="imapd -s" listen="imaps" prefork=1 maxchild=100
>pop3 cmd="pop3d" listen="pop3" prefork=3 maxchild=5
>pop3s cmd="pop3d -s" listen="pop3s" prefork=1 maxchild=5
>sieve cmd="timsieved" listen="sieve" prefork=0
>
># these are only necessary if receiving/exporting usenet via NNTP
> # nntp cmd="nntpd" listen="nntp" prefork=3
> # nntpscmd="nntpd -s" listen="nntps" prefork=1
>
># at least one LMTP is required for delivery
> # lmtp cmd="lmtpd" listen="lmtp" prefork=0
>lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=1
>
># this is only necessary if using notifications
> # notify cmd="notifyd" listen="/var/lib/imap/socket/notify"
> proto="udp" prefork=1
> }
>
> EVENTS {
># this is required
>checkpointcmd="ctl_cyrusdb -c" period=30
>
># this is only necessary if using duplicate delivery suppression,
># Sieve or NNTP
>delprune cmd="cyr_expire -E 3" at=0400
>
># this is only necessary if caching TLS sessions
>tlsprune cmd="tls_prune" at=0400
> }
>
>
>
> Comments, concerns??? I’m going to keep observium open on a separate screen
> and watch when it starts going up, than do the lsof,netstat, and watch logs
> to see if I can tell why the sudden upticks.
>
> 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
I have seen that when some of my users fiddle around on their iphone -
usually the complaints start with "I cannot get mail on my phone" and
around the same time the process count starts going up. Very
intermittent though, and has not occurred since all users upgraded to
IOS 9. Just my USD 0.02 worth...
--
--Moby
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: 2.4.17 --> 2.5.3 Some mail folders no longer accessible
Am 22.09.2015 12:01, schrieb Patrick Goetz: Upgrading from 2.4.17 to 2.5.3 resulted in one very strange problem. Some of the users have a large number of nested mail folders. After the upgrade, exactly one user found that some of his folders (say 3 out of 30) are now inaccessible. In Thunderbird they show up, but are greyed out. If you try to subscribe to the folder, the subscribe checkbox is missing. In roundcube they aren't visible at all. Hi Patrick, have you checked the contents of the subscription file for that user and if all the entries in the subscription file are really valid mailfolders? Regards, Konrad This is pretty clearly a permissions problem of some kind. The question is how could this happen and what's the least painless way of going about resetting the permissions so that he has access to these folders again? We're not doing anything fancy; for example, there are no shared folders; independent email addresses are configured for shared mail content and configured in the MUA. The problem folders are in an unshared account. Also, the manifestation of the permissions problem isn't consistent across the affected folders. As reported by the user: Archives Staff: grayed out, cannot see email Archives Staff Retreat: not grayed out, cannot see email, when you click on it, it says the action cannot be completed because the account does not exist General Convention Office: not grayed out, can see email, when you click on it, it says the action cannot be completed because the account does not exist. Thanks. 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 -- Hochschule Konstanz - Rechenzentrum Konrad Mauz km...@htwg-konstanz.de Tel: +497531206-472, Fax: -153 http://www.htwg-konstanz.de/rz.html smime.p7s Description: S/MIME Cryptographic Signature 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
