These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for New install but Postfix is instable on the new forum.
Web Hosting and Cloud Computing Control Panels
Howdy,
We see an unfortunately high number of issues with OpenVZ regarding resources.
It's easy for RAM to be taken away from your instance to be given to another user... and if your RAM isn't guaranteed, any service using that RAM could crash.
If you look at /proc/user_beancounters, are any of the rows in the failcnt field non-zero?
-Eric
I think the cause was a call in the master.cf file. Once I took it out, Postfix appears to remain up, but there is still no mail coming. I know this is the wrong place to ask this, but are there any obvious mistakes in my configuration?
alias_maps hash:/etc/aliasesallow_percent_hack no
append_dot_mydomain no
biff no
broken_sasl_auth_clients yes
home_mailbox Maildir/
mailbox_command /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit 0
mydestination localhost.localdomain, emea.netnic.ca, localhost.netnic.ca, localhost
mynetworks 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin /etc/mailname
readme_directory no
recipient_delimiter +
sender_bcc_maps hash:/etc/postfix/bcc
smtp_tls_session_cache_database btree:${data_directory}/smtp_scache
smtpd_banner $myhostname ESMTP $mail_name (Ubuntu)
smtpd_helo_required yes
smtpd_helo_restrictions permit_mynetworks, check_helo_access hash:/usr/local/etc/postfix/helo_access, reject_non_fqdn_hostname, reject_invalid_hostname, permit
smtpd_recipient_restrictions reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_sender_access hash:/usr/local/etc/postfix/sender_access, check_recipient_access hash:/usr/local/etc/postfix/recipient_access, check_helo_access hash:/usr/local/etc/postfix/secondary_mx_access, check_policy_service unix:private/spfpolicy check_policy_service inet:127.0.0.1:10023 permit
smtpd_sasl_auth_enable yes
smtpd_sasl_authenticated_header yes
smtpd_sender_restrictions permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit
smtpd_tls_cert_file /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database btree:${data_directory}/smtpd_scache
smtpd_use_tls yes
virtual_alias_maps hash:/etc/postfix/virtual
Which line did you remove from master.cf?
As andreychek noted, the ultimate problem is almost certainly resource related, specifically not enough stable memory.
And, .... with OpenVZ, you never know when you'll loose your "burst" ram, or which service will fail because of it.
The resources are not an issue, as there is 2GB guaranteed, and this is replacing an older system where everything ran with just 1 GB.
For now I have gone back to using the standard main.cf file but this does not answer the question of what is wrong with the original file:
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname = ns1.somedomain.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = localhost.localdomain, ns1.somedomain.com, localhost.somedomain.com, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
virtual_alias_maps = hash:/etc/postfix/virtual
sender_bcc_maps = hash:/etc/postfix/bcc
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
allow_percent_hack = no
Howdy,
Well, unfortunately, resources can be an issue even with a high amount of guaranteed RAM. The Linux kernel will attempt to use all RAM available to it, so eventually, any amount of RAM can become used.
If you're not having any problems, that's super!
But if you notice strange issues with services dieing, and general "instability" -- it's quite likely a resource issue of some sort -- folks not on OpenVZ don't tend to have those sorts of problems :-)
Nothing stands out as a problem in your Postfix config, though you'd also want to review your /var/log/mail.log file to see if any errors or warnings show up in there.
-Eric
Well, I am having a problem. I am trying to reduce load and spam by having Postfix turn away bad mail volumes so that they do not need to run through spam-checking software, and so on. With the full setup, the mail stops entirely, and with the vanilla setup it works, but with tons of spam.
It is very disconcerting, and since I do not speak SMTP very well, the changes in Postfix that I made are now out, and I have wasted a couple of days trying to get the server running.
If I had more of a budget I would not be on an OpenVZ instance, perhaps on AWS, but I am not sure how cost effective it is for mainly e-mail and static web sites.
So: here is what I added to the main.cf file, and until I pulled it all out, the mail just stopped.-
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
check_helo_access
hash:/usr/local/etc/postfix/helo_access,
reject_non_fqdn_hostname,
reject_invalid_hostname,
permit
smtpd_sender_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
permit
Here is the cat /proc/user_beancounters output:
Version: 2.5uid resource held maxheld barrier limit failcnt
81233: kmemsize 30541365 31510736 96636764 107374182 0
lockedpages 0 0 2059 2059 0
privvmpages 192732 245420 1048576 1101004 293
shmpages 3963 3963 65536 65536 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numproc 120 123 500 500 0
physpages 121648 172357 0 9223372036854775807 0
vmguarpages 0 0 524288 9223372036854775807 0
oomguarpages 121648 172357 9223372036854775807 9223372036854775807 0
numtcpsock 56 77 550 550 0
numflock 13 15 1000 1100 0
numpty 1 1 102 102 0
numsiginfo 0 1 1024 1024 0
tcpsndbuf 660912 904552 5280000 7392000 0
tcprcvbuf 570976 789928 5280000 7392000 0
othersockbuf 680568 718000 3840000 5376000 0
dgramrcvbuf 0 8752 3584000 3584000 0
numothersock 386 400 400 400 2002
dcachesize 1592544 1641372 14495514 16106127 0
numfile 6505 6622 17600 17600 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 38 38 9223372036854775807 9223372036854775807 0
Hi.
Every non-zero number in the failcnt column indicates that your virtual instance attempted to do, or did, something which the OpenVZ manager rejected; either refused to allocate the resource (memory or socket), or took it away.
It's life with OpenVZ. You can sometimes negotiate with your provider, maybe; or you could look at seriously reducing your system demands. Maybe you don't need 10 apache processes loaded. Or you could move to a Xen based VPS.
Yeah, as miner said, you may be able to tweak some things in order to reduce memory usage. But it'll be a battle you're fighting all the time.
Xen-based VPS's don't need to be crazy expensive... you can get a Linode with 1GB of RAM for $20/month, for example.
If you want to stick with the VPS you're using now, the key is to reduce memory usage as much as possible.
There's some information on doing that here:
https://www.virtualmin.com/documentation/system/low-memory
However, reducing memory usage just means it'll take longer before you run into this problem again, it won't go away altogether :-)
-Eric