Hallo ! Habe seit einer Woche ein problem das postfix "spinnt" Oct 21 17:23:15 capricorn postfix/local[19845]: fatal: setuid(1000): Resource temporarily unavailable und das andauernd (aber immer wieder mit verschiedenen Prozessnummern), die Kiste hat dann ne Load von 2,6 oder so und ist fast unbedienbar.... das installierte Postfix ist 2.1.5-3.4 es laeuft avmailgate als content filter und assp als Spamfilter front (die Kombination laeuft so schon laenger als ein Jahr.....) Was will Postfix da ueberhaupt machen ? mache ich das komplette Mailzeugs tot und fahre wieder hoch ,dann laeuft alles wieder fuer ne Weile.... Ciao Gerd
Am Friday 21 October 2005 21:01 schrieb newsmail@hoerst.net:
Habe seit einer Woche ein problem das postfix "spinnt"
Oct 21 17:23:15 capricorn postfix/local[19845]: fatal: setuid(1000): Resource temporarily unavailable
und das andauernd (aber immer wieder mit verschiedenen Prozessnummern), die Kiste hat dann ne Load von 2,6 oder so und ist fast unbedienbar....
das installierte Postfix ist 2.1.5-3.4 es laeuft avmailgate als content filter und assp als Spamfilter front (die Kombination laeuft so schon laenger als ein Jahr.....)
Was will Postfix da ueberhaupt machen ? mache ich das komplette Mailzeugs tot und fahre wieder hoch ,dann laeuft alles wieder fuer ne Weile....
Zeig doch mal: # cat /etc/security/limits.conf | grep -v ^# # postconf -n # cat /etc/postfix/master.cf | grep -v ^# -- Andreas
Zeig doch mal: OK steht aber nix weltbewegendes drinne....
# cat /etc/security/limits.conf | grep -v ^# :-) nix....
# postconf -n alias_maps = hash:/etc/postfix/aliases, hash:/etc/postfix/aliases.local allow_percent_hack = no append_at_myorigin = yes append_dot_mydomain = yes command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp:127.0.0.1:824 daemon_directory = /usr/lib/postfix debug_peer_level = 2 default_destination_concurrency_limit = 2 empty_address_recipient = MAILER-DAEMON header_checks = regexp:/etc/postfix/header_checks html_directory = /usr/share/doc/packages/postfix/html local_destination_concurrency_limit = 2 mailbox_command = /usr/bin/procmail mailbox_size_limit = 512000000 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, envelope_recipient masquerade_domains = $mydomain maximal_queue_lifetime = 8d message_size_limit = 100000000 mailbox_command = /usr/bin/procmail mailbox_size_limit = 512000000 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, envelope_recipient masquerade_domains = $mydomain maximal_queue_lifetime = 8d message_size_limit = 100000000 mydestination = /etc/postfix/domain myhostname = mail.hoerst.net mynetworks_style = subnet myorigin = mail.hoerst.net newaliases_path = /usr/bin/newaliases qmgr_message_active_limit = 150 qmgr_message_recipient_limit = 150 readme_directory = /usr/share/doc/packages/postfix/README_FILES sample_directory = /usr/share/doc/packages/postfix/samples sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) smtpd_delay_reject = yes transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 450
# cat /etc/postfix/master.cf | grep -v ^# localhost:smtp-assp inet n - n - - smtpd pickup fifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - n - - smtp relay unix - - n - - smtp showq unix n - n - - showq error unix - - n - - error local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil localhost:smtp-backdoor inet n - n - - smtpd -o content_filter= maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient} cyrus unix - n n - - pipe user=cyrus argv=/usr/lib/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient) ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient procmail unix - n n - - pipe flags=R user=nobody argv=/usr/bin/procmail -t -m /etc/procmailrc ${sender} ${recipient}
Ciao Gerd
Am Sunday 23 October 2005 18:52 schrieb newsmail@hoerst.net:
Zeig doch mal:
OK steht aber nix weltbewegendes drinne....
# cat /etc/security/limits.conf | grep -v ^#
:-) nix.... :
Postfix ist modular aufgebaut, da laufen einige Dämonen. Und bei einem stark ausgelasteten Server können es auch ein paar Hundert oder gar tausend sein. Die Fehlermeldung kommt, wenn der Start eines Dämons fehlschlägt, weil nicht mehr genug Prozesse im System frei sind. Dies ist auch eine endliche Zahl. Und man kann sie auch noch einschränken z.B. in der /etc/security/limits.conf. Da dies nicht passiert ist, würde ich mal vermuten Dein System ist einfach so am ende und bei Postfix fällt es Dir als erstes auf. Wenn der Fehler wieder auftritt, check mal in der Prozessliste (ps / man ps) was soviele Prozesse benutzt. Müssten sich bei nem normalen System so im 5-Stelligen Bereich (ca. 16.000) bewegen. Ist es ein VServer? Sind die von dort aus begrenzt? -- Andreas
Hi ! On Sun, 23 Oct 2005, Andreas Winkelmann wrote:
Postfix ist modular aufgebaut, da laufen einige Dämonen. Und bei einem stark ausgelasteten Server können es auch ein paar Hundert oder gar tausend sein. Die Fehlermeldung kommt, wenn der Start eines Dämons fehlschlägt, weil nicht mehr genug Prozesse im System frei sind. Dies ist auch eine endliche Zahl. Und man kann sie auch noch einschränken z.B. in der /etc/security/limits.conf. Da dies nicht passiert ist, würde ich mal vermuten Dein System ist einfach so am ende und bei Postfix fällt es Dir als erstes auf. Hmmm mal schaun... ob es da ne Regelmaessigkeit gibt mit der das ganze auftritt.
Wenn der Fehler wieder auftritt, check mal in der Prozessliste (ps / man ps) was soviele Prozesse benutzt. Müssten sich bei nem normalen System so im 5-Stelligen Bereich (ca. 16.000) bewegen. Ist es ein VServer? Sind die von dort aus begrenzt? Ist eigentlich en SuSE Standart inst. auf nem Semprom 2200+ mit 512 MB Ram
Ciao Gerd
participants (2)
-
Andreas Winkelmann
-
newsmail@hoerst.net