Re: some watchdog timeout
On 10 oct. 2010, at 02:41, Wietse Venema wrote: > Postfix daemons terminate voluntarily when they receive no request > for $max_idle seconds. The watchdog timer is a safety mechanism; > it terminates a process when it appears to hang. > > The $max_idle timer uses select(2), poll(2), epoll(3) or /dev/poll > depending on the operating system type and version. Failure of this > timer is usually a symptom of virtualization bugs. That's interesting! Thank you. The FreeBSD server running those postfix is a virtual machine on top of VMWare ESXi, and running VMWare Tools. I'll try to get some support from VMWare (and FreeBSD users), but if someone here has an idea (vmware issue? bios tuning? freebsd tuning?...) I'd be happy to read about it. thanks, Patrick PRONIEWSKI -- Administrateur Système - SENTIER - Université Lumière Lyon 2 smime.p7s Description: S/MIME cryptographic signature
Re: some watchdog timeout
On 10/10/2010 10:33 AM, Patrick Proniewski wrote: On 10 oct. 2010, at 02:41, Wietse Venema wrote: Postfix daemons terminate voluntarily when they receive no request for $max_idle seconds. The watchdog timer is a safety mechanism; it terminates a process when it appears to hang. The $max_idle timer uses select(2), poll(2), epoll(3) or /dev/poll depending on the operating system type and version. Failure of this timer is usually a symptom of virtualization bugs. That's interesting! Thank you. The FreeBSD server running those postfix is a virtual machine on top of VMWare ESXi, and running VMWare Tools. I'll try to get some support from VMWare (and FreeBSD users), but if someone here has an idea (vmware issue? bios tuning? freebsd tuning?...) I'd be happy to read about it. thanks, I'd start with the version of postfix you're running - what is it ? I run postfix on half a dozen vmware ESX guests, all of them Ubuntu, never had any sort of problem with this. They all run 2.6 or higher. -- J.
Re: some watchdog timeout
On 10 oct. 2010, at 12:26, Jeroen Geilman wrote: >>> The $max_idle timer uses select(2), poll(2), epoll(3) or /dev/poll >>> depending on the operating system type and version. Failure of this >>> timer is usually a symptom of virtualization bugs. >> >> That's interesting! Thank you. The FreeBSD server running those postfix is a >> virtual machine on top of VMWare ESXi, and running VMWare Tools. >> I'll try to get some support from VMWare (and FreeBSD users), but if someone >> here has an idea (vmware issue? bios tuning? freebsd tuning?...) I'd be >> happy to read about it. > I'd start with the version of postfix you're running - what is it ? > I run postfix on half a dozen vmware ESX guests, all of them Ubuntu, never > had any sort of problem with this. > They all run 2.6 or higher. I'm running Postfix 2.7.1 on top of FreeBSD 7.3-RELEASE-p2 #0, amd64, on top of ESXi 4 But if it's linked to virtualization, it might be a vmware tools problem... Patrick PRONIEWSKI -- Administrateur Système - SENTIER - Université Lumière Lyon 2 smime.p7s Description: S/MIME cryptographic signature
Re: Postfix not create Maildir
Em 9/10/2010 11:36, mouss escreveu: >> mx# postmap -q mdon...@domain.com.br >> ldap:/usr/local/etc/postfix/ldap/ldap-mailbox-user.cf >> mdonada >> > > you need to add a trailing slash. the query should return "mdonada/" > (with a slash at the end), otherwise, postfix will consider that you > want mbox, not maildir. > Wonder was just that, it worked perfectly. Thank you for your attention. I created an attribute in LDAP "mailMessageStore" and take him to be the reference of the Maildir. -- Márcio Luciano Donada Aurora Alimentos - Cooperativa Central Oeste Catarinense Departamento de T.I.
Re: some watchdog timeout
Patrick Proniewski: > On 10 oct. 2010, at 02:41, Wietse Venema wrote: > > > Postfix daemons terminate voluntarily when they receive no request > > for $max_idle seconds. The watchdog timer is a safety mechanism; > > it terminates a process when it appears to hang. > > > > The $max_idle timer uses select(2), poll(2), epoll(3) or /dev/poll > > depending on the operating system type and version. Failure of this > > timer is usually a symptom of virtualization bugs. On FreeBSD it will use select(2) (Postfix < 2.4) or kqueue(2). > That's interesting! Thank you. The FreeBSD server running those postfix is >- a virtual machine on top of VMWare ESXi, and running VMWare Tools. > I'll try to get some support from VMWare (and FreeBSD users), but if someo >-ne here has an idea (vmware issue? bios tuning? freebsd tuning?...) I'd be h >-appy to read about it. You most likely suffer from the infamous "lost timer interrupt" problem that many virtual environments suffer from. Virtual machine monitors (including VMware) are known to cheat with timer interrupts, because it is incredibly expensive to deliver a thousand interrupts a second to each guest machine, and it is very hard to deliver those interrupts always at the right time. You can try to make your guest machine more VMware-friendly by reducing the kernel clock interrupt frequency. With FreeBSD guests you can reduce the kernel clock interrupt frequency without recompiling the kernel. This requires a reboot (FreeBSD can't change the kernel clock frequency on-the-fly with the sysctl command). /boot/loader.conf kern.hz="100" By reducing the interrupt rate in the guest (and by increasing it in the host) I keep the system clock sane on guests without having to rely on VMware- or VirtualBox-specific drivers in the guest machine. Instead it's sufficient to run NTP. But I must admit that I rarely run a guest machine long enough that any watchdog timer could go off. I use them primarily for testing. I don't know if this will help in your particular case. But, with a lower over-all interrupt rate for the system, it will be less likely to lose an interrupt (assuming that the other guest machines also reduce their timer interrupt rates). See also: http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf Wietse
