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, [email protected] 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! > > CYRUS [1] / Info / see discussions [2] + participants [3] + delivery options > [4] Permalink [5] Links: ------ [1] https://cyrus.topicbox.com/latest [2] https://cyrus.topicbox.com/groups/info [3] https://cyrus.topicbox.com/groups/info/members [4] https://cyrus.topicbox.com/groups/info/subscription [5] https://cyrus.topicbox.com/groups/info/Td155a4c12885169a-M30352657fddac1fe7efc4299 ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/Td155a4c12885169a-Mca972e45432c39805c877af8 Delivery options: https://cyrus.topicbox.com/groups/info/subscription
