Re: About session disconnect and an slow response some time later

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!


I suppose too it can't affect but... we are not starting master as root. We run it as user and we use ports like 1430 or 1100 for listening and avoid the need of using user root. I can't see nothing bad or wrong there... but... just telling because master is awaited to be started as root but.... I think it should have any kind of problems for that because the user has no meaningful limits... not file descriptor limits, sockets... etc etc.... concretely....

 ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  33554432
stack size              (kbytes, -s)  524288
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  89999
open files                      (-n)  3763710
virtual mem size        (kbytes, -v)  unlimited
swap limit              (kbytes, -w)  unlimited
socket buffer size       (bytes, -b)  unlimited
pseudo-terminals                (-p)  unlimited
kqueues                         (-k)  unlimited
umtx shared locks               (-o)  unlimited


Any idea mates :) ?


Cheers!

 


El 2022-07-05 19:40, egoitz via Info escribió:


ATENCIÓN: este correo se ha enviado desde fuera de la organización. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro.

Hi again :)


One question. I have seen that have been able to see info needed for debugging this by launching master with -v or -vv. I would not like to have launched that way master, because it could take months for this to reproduce. I need that a user to disconnect it's sessions and to have several ones for disconnect. Does exist some way, of enabling that verbosity when you know you are "near" to need it, because you suspect the bug is going to happen again?. Or... how could I achieve for enabling verbosity when I need it?. I think I don't get that verbosity info when using debug:1 in imapd.conf... so HUP signal is discarded....


Cheers!

 


El 2022-06-29 15:45, egoitz via Info escribió:


ATENCIÓN: este correo se ha enviado desde fuera de la organización. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro.

Hi!


I have been looking deeply at this, at reap_child() and process_msg() and this seems to be fine... so my suspect is just noise.... sorry for it...

I'll go on trying to reproduce it.... or try enabling debug to 1 in imapd.conf with a HUP signal when I have the problem.... if the suspect I had that ready_works was not totally right decremented I suppose (should look more deeply) that enabling debug in that moment would allow me (to see ready_workers value because I see are logged with debug in master.c in some place...)...


Thanks anyway,

Cheers!

 


El 2022-06-22 12:58, egoitz@xxxxxxxxxxxxx escribió:

Good morning,


I wrote to the list some time ago due to this topic. I have noted that when a user asks to disconnect his/her sessions (imap sessions normally the disconnected ones) after some time like an hour or a half an hour passes I start having some slow responses to new connections. I have monitored them and it's slightly intermittent, KO and OK of server responding alert in less than 3 seconds. This intermittency lasts like 10 minutes and later the response delays increase. Obviously for avoid bigger service outages I stop and start Cyrus and all works fine later.

I have been trying to figure why it could be happening because I have seen it only happens when I launch TERM for a disconnection to several imap proccesses (the user that requested proccesses). It doesn't happen at the moment. As said for instance yesterday happened when an hour passed of the disconnection.

I don't have prefork param set in cyrus.conf, so... Cyrus spawns on demand. After doing some examinations my theory is that perhaps Cyrus is not calling spawn_service() every time gets needed. I would say it should happen in master.c :

2610               if (!in_shutdown && Services[i].exec &&
2611                    Services[i].nactive < Services[i].max_workers &&
2612                    Services[i].ready_workers == 0 &&
2613                    y >= 0 && FD_ISSET(y, &rfds))
2614                {
2615                    /* huh, someone wants to talk to us */
2616                    spawn_service(i);
2617                }

I think that perhaps ready_workers is not properly decremented when I launch this TERM and perhaps this causes Cyrus not to spawn any new more services of the kind of the terminated service. As yesterday happened in a more or less peak accesses hour it needed to have more services spawned but... as it seen ready_workers not to be 0 for that service... it didn't spawn new more services and as consequence, connections started becoming queued in being accepeted awaiting that happened when a proccess gets idle because it's client has disconnected or idled timeout or imap timeout happened....

So, I was wondering if in reap_child() for the states SERVICE_STATE_UNKNOWN and SERVICE_STATE_BUSY shouldn't be decremented the ready_workers in the service struct... Concretely in master.c in :

1121                case SERVICE_STATE_BUSY:
1122                    s->nactive--;
1123                   if (!in_shutdown && failed) {
1124                       syslog(LOG_DEBUG,
1125                               "service %s/%s pid %d in BUSY state: "
1126                               "terminated abnormally",
1127                               SERVICEPARAM(s->name),
1128                               SERVICEPARAM(s->familyname), pid);
1129                    }
1130                    break;
1131
1132                case SERVICE_STATE_UNKNOWN:
1133                    s->nactive--;
1134                   syslog(LOG_WARNING,
1135                           "service %s/%s pid %d in UNKNOWN state: exited",
1136                           SERVICEPARAM(s->name),
1137                           SERVICEPARAM(s->familyname), pid);

Obviously, another possible solution is to specify prefork in cyrus.conf but I'd rather avoid wasting memory when it's not needed...

What's your opinion mates?. Or what do you think Ellie, Bron :) . Have you ever seen something like it?.


Cheers!


[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux