Process saslauthd consuming 100% of CPU.

[Alfspace]

Hi, I'm getting this behaviour from the MTA server using open source edition 3.1.4 and the users cannot send messages.

Sometimes stopping/restarting with zmsaslauthdctl solves the problem but sometimes I need to reboot the server.

The process appears like 3 or 4 times in the display from the 'top' command.

The server is an HPBlade with dual opteron processors and 6GB or RAM.

[anand]

next time this happens, can you please pstack the offending process ids? Would be interesting to see what these processes are so busy doing.

Do the pstack a few times. That would give us an idea of what sequence of functions are being called.

You could also use gdb and attach and do a "where" if you'd like.

When you have the stack traces, please open a bug in bugzilla also.

[Alfspace]

sorry for my ignorance but what do you mean by pstack and gdb ?

are those linux commands ?
Could you please tell me how to use them ?

thanks for your help.

[Matt Rhoades]

Here's a man page on pstack:

http://www.linuxcommand.org/man_pages/pstack1.html

Also, look here at a similar bug: http://bugzilla.zimbra.com/show_bug.cgi?id=11381 ... I'm not sure if that is the same problem that you are experiencing.

[rasjani]

I've been running saslauthd (and openssh and other apps that use encryption and random numbers) in different email project that wasnt using zimbra (just postfix installation that i've setup myself) and *if i remember correctly* saslauthd draining cpu was caused by its requirement to use /dev/random .. This device file generates its random data gathered from entropy happening in the machine (keypresses/mouse movements and such). In server machines that do not have mouse/keyboards even attached, reading of the /dev/random is sometimes blocking and using all available cpu as there is random data available..

To fix this without recompling or reconfiguring saslauthd, remove or move /dev/random to a new name and use mknod to create new version with mknod that machines the same major/minor number pair as /dev/urandom ..

*note*

This ofcourse is a tradeoff in security and in same cases this is not an option. however, many cases using /dev/urandom instead of /dev/random is "secure enough" ..