Hi My happiness did not last long Jan 18 13:33:22 postfix/master[3581]: warning: master_wakeup_timer_event: service qmgr(public/qmgr): Resource temporarily unavailable
I'm so confused beacuse I cannot resolv thats problem and I dont known where is realy problem W dniu 18.01.2022 o 10:34, natan pisze: > Hi > Thenx all :) for test i change to 300 for default_process_limit and > change 190 to 300 > > > > Wysłano z mojego Mi MIX 2 > Wietse Venema <wie...@porcupine.org> 17 sty 2022 18:34 napisał(a): > > natan: > > W dniu 17.01.2022 o?15:58, Wietse Venema pisze: > > > natan: > > >> W dniu 14.01.2022 o 22:18, Wietse Venema pisze: > > >>> natan: > > >>> Wietse: > > >>>> Do you know if the problem is a kernel limit or a > per-process limit? > > >>>> Does master have 4096 open files (including network > sockets: ip, > > >>>> unix-domain, etc.). > > >>> Wietse: > > >>>> BTW that last one was a trick question: you need a huge > number of > > >>>> services in master.cf <http://master.cf> to exceed the 4096 > limit. The master needs > > >>>> three sockets for each service with type 'unix' in > master.cf <http://master.cf>; > > >>>> services with type 'inet' require two sockets plus one > socket per > > >>>> address in inet_interfaces. > > >>> natan: > > >>>> "Do you know if the problem is a kernel limit or a > per-process limit?" > > >>>> > > >>>> I realy dont known where is it the problem - and how > diagnose this > > >>>> > > >>>> I long think about kernel limit but ... no have idea > > > Wietse: > > >> Were you the person who has a Postfix process limit in the > thousands? > > >> If that is the case, then I suggest that you reduce the Postfix > > >> process limit to half the number, do "postfix reload", wait > for a > > >> while, and keep reducing the limit to half its value until the > > >> "resource temporarily unavailable" warnings go away. Also, make > > >> arrangements for more (and more powerful) servers. > > > natan: > > >> I don't know if I am that man with limit thousands > > >> > > >> # postconf -nf > > > ... > > >> default_process_limit = 1200 > > >> > > >> from log: > > >> Jan 17 10:10:50 thebe4b postfix/postscreen[7103]: warning: > cannot > > >> connect to service private/smtpd: Resource temporarily > unavailable > > > postscreen maintains queues with connetions that still need to be > > > 'tested' (postscreen_pre_queue_limit) and that need to be > given to > > > an smtpd process (postscreen_post_queue_limit). > > > > > > Each postscreen queue size is $default_process_limit. Both queues > > > together add up to 2400 network sockets. > > > > > > If you make this amount the same as your internet-facing smtpd > > > process limits, then postscreen might leave more resources for > the > > > rest of Postfix. > > > > > > And then, reduce process limits by half and do "postfix reload", > > > until the 'Resource temporarily unavailable' message goes away. > > > > > >> This is a strong machine where load average: 0,95, 1,19, 2,08 > > > Obviously, it doesn't use much CPU power when it can't create a > > > UNIX-domain socket. > > > > > > Wietse > > > #for no scan amavis: > > 10.0.100.24/32 <http://10.0.100.24/32> FILTER > smtp:10.0.100.5:10025 <http://10.0.100.5:10025> > > xxx.xxx.xxx <http://xxx.xxx.xxx>.25/32 FILTER > smtp:10.0.100.5:10025 <http://10.0.100.5:10025> > > #go to amavis-klaster > > 0.0.0.0/0 FILTER smtp-amavis:[127.0.0.1 <http://127.0.0.1>]:10628 > > ########## > > OK, you're switching between after-queue content filters, > and there is no smtpd_proxy_filter. > > > That leaves the possibility that postscreen is hogging too many > network sockets. > > Reduce the default_process_limit to the same number as your "smtpd > pass" service (currently, 190). Then do "postfix reload", and wait > for some time. > > While Postfix logs "resource temporarily unavailable": > Halve the process limit for the "smtpd pass" SMTP service. > Halve the default_process_limit. > Do "postfix reload". > Wait for some time. > > Wietse > --
