[7.301] SMTP not working. POSTGRESQL Errors.

Everthing else seems to work OK.  But I am seeing postgres errors in the system log.

What errors do you get from your postgres? Plaese post som log entries.

Is postgres running? What does ps waux |grep [p]ostgres say.

Does your /var/chroot-smtp/etc/hosts file have correct rights? Should be 644.

Is smtpd running? ps waux |grep [s]mtpd.

I see :    Can not handle pid file /var/run/ulogd.pid with pid`'

During boot time, PostgreSQL is failing to start.  It sits there for about a minute before reporting that it failed to start.

Final report after boot is:
Failed services in runlevel 3: ulog postgresql sshd

ps waux |grep [p]ostgres says:
(See image here)
http://www.micromine.com/STH72089.JPG

Log shows:
2008:09:19-09:22:03 (none) selfmonng[3431]: W child returned status: exit='0' signal='0'
2008:09:19-09:22:03 (none) selfmonng[3431]: W check Failed increment ulogd_running counter 3 - 3
2008:09:19-09:22:03 (none) selfmonng[3431]: W NOTIFYEVENT Name=ulogd_running Level=INFO Id=114 sent
2008:09:19-09:22:03 (none) selfmonng[3431]: W triggerAction: 'cmd'
2008:09:19-09:22:03 (none) selfmonng[3431]: W actionCmd(+): '/etc/init.d/ulog restart'
2008:09:19-09:22:03 (none) selfmonng[3431]: W child returned status: exit='1' signal='0'
2008:09:19-09:22:03 (none) selfmonng[3431]: I check Failed increment nextgen-agent_running counter 1 - 3
2008:09:19-09:22:03 (none) selfmonng[3431]: W check Failed increment postgresql_running counter 3 - 3
2008:09:19-09:22:03 (none) selfmonng[3431]: W triggerAction: 'cmd'
2008:09:19-09:22:03 (none) selfmonng[3431]: W actionCmd(+): '/etc/init.d/postgresql restart' 

I have tried restoring a different backup without luck.

The only thing I can think of, is the new hardware is one NIC short of the old system, however I am not using that NIC on this new system...
Sorry for the slow reply.  Lot on here...

I see :    Can not handle pid file /var/run/ulogd.pid with pid`'

During boot time, PostgreSQL is failing to start.  It sits there for about a minute before reporting that it failed to start.

Final report after boot is:
Failed services in runlevel 3: ulog postgresql sshd

ps waux |grep [p]ostgres says:
(See image here)
http://www.micromine.com/STH72089.JPG

Log shows:
2008:09:19-09:22:03 (none) selfmonng[3431]: W child returned status: exit='0' signal='0'
2008:09:19-09:22:03 (none) selfmonng[3431]: W check Failed increment ulogd_running counter 3 - 3
2008:09:19-09:22:03 (none) selfmonng[3431]: W NOTIFYEVENT Name=ulogd_running Level=INFO Id=114 sent
2008:09:19-09:22:03 (none) selfmonng[3431]: W triggerAction: 'cmd'
2008:09:19-09:22:03 (none) selfmonng[3431]: W actionCmd(+): '/etc/init.d/ulog restart'
2008:09:19-09:22:03 (none) selfmonng[3431]: W child returned status: exit='1' signal='0'
2008:09:19-09:22:03 (none) selfmonng[3431]: I check Failed increment nextgen-agent_running counter 1 - 3
2008:09:19-09:22:03 (none) selfmonng[3431]: W check Failed increment postgresql_running counter 3 - 3
2008:09:19-09:22:03 (none) selfmonng[3431]: W triggerAction: 'cmd'
2008:09:19-09:22:03 (none) selfmonng[3431]: W actionCmd(+): '/etc/init.d/postgresql restart' 

I have tried restoring a different backup without luck.

The only thing I can think of, is the new hardware is one NIC short of the old system, however I am not using that NIC on this new system...
Sorry for the slow reply.  Lot on here...

I have a client with a cluster of two 220s.  Astaro developers said that PostgreSQL on node 1 got bollixed.  I'm guessing that this was in the transition from 7.202 to 7.300 three weeks ago.  The upgrade had to be forced, and I wish now that I had imaged it as I later had to do with node 2.

The phenomenon we've been dealing with is that, at times, 20% of emails are flagged as delivered in the SMTP log, but they don't leave the cluster.  Then, some thing causes the cluster to hiccup again, and a flood of emails is released.  There were 1,800 on Tuesday morning from the prior 48 hours.  On a normal day, they get 55,000 emails which are 95% spam.

Presently, the only way to keep the cluster from bogging down is to disable IPS.  They take credit cards and are audited on an on-going basis, so we can't leave the situation as it is.

My problem was solved by reinstalling the ISO. 

A factory reset of the system still booted with Postgresql errors (ie failed to start).

Reinstalled ISO, up2dated again, restored a different backup and the system now works.