LDAP Daemon Aborts

[patrickmoore]

Hi

Yep, I'm afraid I am still seeing occasional LDAP crashes. I noted one other post where the problem may have been related to spamassassin, but as I don't have this running on my server...

Sorry, forgot to add that I am running Centos 4.3 masquerading as RHEL4.

Any thoughts from the Scalix team on this one? Have we managed to stump you guys ?

[netcomrade]

We had the same issue twice in two days, running 'commercial' on rh4.
What I don't understand the most, is why scalix has to stop sending/receiving mail when some ldap module is broken. I understand if ppl can't login, but why does it need to stop functioning as a mail server?

[ScalixSupport]

Hi!

Check the permissions for scalix files using the command "omcheck -s -d", to actually fix
the problem if any of permissions, you should run omcheck to generate a shell script - on
standard output - that, when run, fixes the problem for permission issues.

Code: Select all

omcheck -s -d >fix_perms.sh
bash ./fix_perms.sh

You might want to review what the script is planning to do before actually executing
the second command.

This issue normally occurs due to permission problems and that is why it seems the
ldapmapper tends to crash.

Thanks,
Subir

[eyalm]

Died again 10 mins ago with this error:

SERIOUS ERROR LDAP Daemon (LDAP Listener ) 04.05.07 11:43:24
[OM 10270] Process about to terminate due to error.
Signal (Segmentation Violation) trapped by process 16776
Procedure trace follows:


SERIOUS ERROR LDAP Daemon (LDAP Listener ) 04.05.07 11:43:24
[OM 10272] BACKTRACE:
/opt/scalix/lib/libom_er.so(er_add_backtrace+0xc6)[0xf7ff5ee6]
/opt/scalix/lib/libom_er.so[0xf7ff61e6]
/opt/scalix/lib/libom_er.so(er_DumpProcAndExit+0x1f)[0xf7ff638f]
[0xffffe500]
/lib/tls/libpthread.so.0[0x535371]
/lib/tls/libc.so.6(__clone+0x5e)[0x48e9be]

[netcomrade]

Your omscheck found a crapload of files.

Why would they be with wrong permissions in the first place?

We upgraded from 10 to 11 recently.

-andrey

[ScalixSupport]

Hi!

Andrey, do run the script created by omcheck to resolve the permission issues.

Let's continue working on the LDAP error, I would suggest you all to run the ommaint
script, then try restarting ldapmapper and sendmail. Let see if this resolves the issue.

Find ommaint at:
http://www.scalix.com/wiki/index.php?ti ... th_ommaint
a brief description and its execution procedure has been explained in this page itself.

Steps to help resolve the issue:
1. Run ommaint from cron, wait until LDAP daemon is running,
2. Start ldapmapper using "service ldapmapper start", and
3. Restart sendmail using, "service sendmail restart"

Make sure you keep a track of the date and time. Please update me if the issue persists
or are they gone.

Thanks,
Subir

[jillrae]

I am also haveing the same LDAP aborting error and have the same boss who is not real happy with his email not running. So am most interested in this solution.

I ran the
omcheck -s -d >fix_perms.sh
command and it returned nothing. Should I go ahead and run the
bash ./fix_perms.sh
command?

I am currecntly running ommaint and have been since my inital install of version 9.

Just to be on the safe side, I will insert the LDAP restart script in a CRON job. The LDAP service always picks the most unopportune time to stop. Usually in the middle of the night on the weekend.

Shall I also gather any info for trouble shooting? I am running on a fully patched SLES 9 server. Most recent Scalix version and update.

jillrae

[jillrae]

BTW, shouldn't ommaint restart the LDAP daemon without another script? Or can the posted script be incorporated into ommaint?

jillrae

[lcastellanos]

Netcomrade and myself work for the same company. The issue persists:

SERIOUS ERROR LDAP Daemon (LDAP Listener ) 04.07.07 07:15:03
[OM 10270] Process about to terminate due to error.
Signal (Segmentation Violation) trapped by process 17127
Procedure trace follows:


SERIOUS ERROR LDAP Daemon (LDAP Listener ) 04.07.07 07:15:03
[OM 10272] BACKTRACE:
/opt/scalix/lib/libom_er.so(er_add_backtrace+0xc6)[0x676ee6]
/opt/scalix/lib/libom_er.so[0x6771e6]
/opt/scalix/lib/libom_er.so(er_DumpProcAndExit+0x1f)[0x67738f]
/lib/tls/libpthread.so.0[0x40c898]
/lib/tls/libpthread.so.0[0x406371]
/lib/tls/libc.so.6(__clone+0x5e)[0x370ffe]


SERIOUS ERROR LDAP Daemon (LDAP Listener ) 04.09.07 04:56:35
[OM 10270] Process about to terminate due to error.
Signal (Segmentation Violation) trapped by process 29675
Procedure trace follows:


SERIOUS ERROR LDAP Daemon (LDAP Listener ) 04.09.07 04:56:35
[OM 10272] BACKTRACE:
/opt/scalix/lib/libom_er.so(er_add_backtrace+0xc6)[0x8beee6]
/opt/scalix/lib/libom_er.so[0x8bf1e6]
/opt/scalix/lib/libom_er.so(er_DumpProcAndExit+0x1f)[0x8bf38f]
/lib/tls/libpthread.so.0[0x40c898]
/lib/tls/libpthread.so.0[0x406371]
/lib/tls/libc.so.6(__clone+0x5e)[0x1f4ffe]

[netcomrade]

btw, we have the maintenances setup as you have suggested, as well as this

Code: Select all

omcheck -s -d >fix_perms.sh
bash ./fix_perms.sh


no longer produces any errors

LDAP portion failed today a few hours after the maint scripts[/code]

[netcomrade]

Actually, I take that back, that omscheck suggested a bunch of permission corrections, however, my question is, why do they keep showing up, and how do we know they're the cause of LDAP issue(s)

[afassl]

Hi,

had the last two days "fun" with the side effects of imapsync, saw a lots of errors similar to those posted here.

Fast cure:
# omoff -d0 omscan
# omscan -Z
# omon omscan
Now check with
# omscan -t
until the message shows "Current Server cycle not started".

a
# omcheck -s -d >fix_perms.sh
# chmod +x fix_perms.sh
# ./fix_perms.sh

was needed as well.

Thereafter a
# omtidyallu -M

restart the processes, up and ready again.

[netcomrade]

Scalix,

We have tried all the suggestions here.
We have also emailed your support, but have recieved no reply.
This continues to be an issue with a few restarts per day by our script.
Are we, as a small customer, doomed at this point?

[florian]

We are investigating into the LDAP crash issue at highest priority, however haven't found a reproducible scenario just yet. In addition, thanks to Mr. Murphy it doesn't happen on our own server or in QA testing.

So if you can contribute any information that makes this reproducible, it would be helpful. What OS platforms are you using, are you using any external LDAP directories integrated with Scalix or is there anything else specific about your environment? Or can you even provide a set of steps to make this happen?

To answer one of the questions, incoming email messages need to be checked against the directory so that we can resolve addresses and see if the recipient is a scalix user after all. therefore, directory access is needed.

Florian.

[eyalm]

This is what we've got:

RHEL 4 rel.3
4GB ram
Using openldap in another server for authentication.

ldap crashes sometimes twice a day, but then it can stay more than a week before crashing again. (last time it crashed was more than a week ago).

I pasted my omshowlog -s ldap. Is there anything else that might help?