sorry : "think it should have any kind of problems for that"
I meant it shouldn't have.... Cheers! El 2022-07-06 12:43, [email protected] escribió: > 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-Mcf6a7f4c353b987679454a3e Delivery options: https://cyrus.topicbox.com/groups/info/subscription
