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, [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-Mca972e45432c39805c877af8 ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/Td155a4c12885169a-M78e9f08046135ac03292798e Delivery options: https://cyrus.topicbox.com/groups/info/subscription
