6

Woke up today to see my site slow/unresponsive. Pulled up top and it looks like a ton of saslauthd processes have spun up using about 64m of RAM each, causing the machine to enter swap space. I've never seen this many used on there.

top - 16:54:13 up 85 days, 11:48,  1 user,  load average: 0.32, 0.50, 0.38
Tasks: 143 total,   1 running, 142 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.7%us,  0.3%sy,  0.0%ni, 97.3%id,  0.2%wa,  0.0%hi,  0.0%si,  1.4%st
Mem:   1048796k total,  1025904k used,    22892k free,    14032k buffers
Swap:  2097144k total,   332460k used,  1764684k free,   194348k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                  
  848 admin     20   0  263m 115m 4840 S    0 11.3   5:02.91 ruby                                                                                      
  906 admin     20   0  265m 113m 4828 S    0 11.1   5:37.24 ruby                                                                                      
30484 admin     20   0  248m  91m 4256 S    6  9.0 219:02.30 delayed_job                                                                               
 4075 root      20   0  160m  65m  952 S    0  6.4   0:24.22 saslauthd                                                                                 
 4080 root      20   0  162m  64m  936 S    0  6.3   0:24.48 saslauthd                                                                                 
 4079 root      20   0  162m  64m  936 S    0  6.3   0:24.70 saslauthd                                                                                 
 4078 root      20   0  164m  63m  936 S    0  6.2   0:24.66 saslauthd                                                                                 
 4077 root      20   0  163m  62m  936 S    0  6.1   0:24.66 saslauthd                                                                                 
 3718 mysql     20   0  312m  52m 3588 S    1  5.1   3499:40 mysqld                                                                                    
  699 root      20   0 72744 7640 2164 S    0  0.7   0:00.50 ruby                                                                                      
15701 postfix   20   0  106m 5712 4164 S    1  0.5   0:00.50 smtpd                                                                                     
15702 postfix   20   0 52444 3252 2452 S    1  0.3   0:00.06 cleanup                                                                                   
 4062 postfix   20   0 41884 3104 1788 S    0  0.3 125:26.01 qmgr                                                                                      
15683 root      20   0 51504 2780 2180 S    0  0.3   0:00.04 sshd                                                                                      
14595 postfix   20   0 52308 2548 2304 S    1  0.2   0:24.60 proxymap                                                                                  
15483 postfix   20   0 43380 2544 1992 S    0  0.2   0:00.38 smtp                                                                                      
15486 postfix   20   0 43380 2544 1992 S    0  0.2   0:00.36 smtp                                                                                      
15488 postfix   20   0 43380 2540 1992 S    0  0.2   0:00.38 smtp                                                                                      
15485 postfix   20   0 43380 2532 1984 S    0  0.2   0:00.36 smtp                                                                                      
15489 postfix   20   0 43380 2532 1984 S    0  0.2   0:00.40 smtp 

Wasn't sure what Saslauthd is, Google says it handles plantext authentication. The machine has been sending a lot of email through postfix, so this could be related.

Anyone know why so many may have spun up? Are they safe to kill? Thanks!

2
  • 1
    As an update, I was able to to sudo /etc/init.d/saslauthd restart which seemed to work fine. Still - wondering how/why it may have happened all of the sudden and if there is a way to limit the number than can spin up in the future to avoid getting to swap. Thanks! Aug 24, 2010 at 17:06
  • You can limit how many threads it spawns in the config.
    – ptman
    Sep 24, 2010 at 10:12

3 Answers 3

6

I have the same issue - it should be possible to disable caching.

To disable caching in debian you need to edit /etc/default/saslauhtd:

OPTIONS="-r -c -m /var/spool/postfix/var/run/saslauthd"

To limit the cache size to 5MB you can add the -s parameter:

OPTIONS="-s 5120 -r -c -m /var/spool/postfix/var/run/saslauthd"

To limit the number of daemons in the same file:

THREADS=2

The OPTIONS variable contains parameters for the saslauthd daemon - you can use them in other linux systems too.

But it seems to have no effect sometimes...

There are some known memory leaks if you use pam and/or mysql.

E.G. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379810

1

Saslauth permit to your users to send mail after an authentication. You could use it in SMTPS protocol to allow your authenticated users to relay mails by your server. Do you configure it ? The is a bunch of authentication mechanisms available with the -a option. Check your ps/top with the complete command line to see the -a option.

As it interact with Postfix, it should be placed in the postfix var environment. I remember that it was not the case in Debian by default and eats cpu or memory. Check the -m option if the directory you want is really existent and if the rights are good

1
  • I don't remember ever configuring it. If anyone knows a config file for it to setup max number of instances or mem usage that would be helpful. Otherwise, this one may remain a mystery. It hasn't happened again luckily. Aug 27, 2010 at 1:28
0

It's old thread but my answer can help. I used courier-authdaemon instead saslauthd. More info https://github.com/pulecp/ubuntu-postfix-cyrus

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .