# SpamAssassin Segfaults Every Other Day



## AzaShog (Sep 17, 2014)

Hello,

I have a problem with mail/spamassassin segfaulting every other day. There is absolutely no error in the normal logs other than:


```
Sep 16 13:16:22 mta kernel: pid 1136 (perl), uid 0: exited on signal 11 (core dumped)
```

The only debugging mode sa-spamd has is very verbose stderr output which I don't know how to manage via rc scripts. I tried running sa-spamd manually in tmux redirecting stderr to a file, but it ran like that for a week without problems. Only when I run it via its rc script does it segfault every other day.

Any suggestions where and how to start troubleshooting this? I guess running sa-spamd in debug mode under rc is the way to go, but I don't know how to change the rc file for that...


----------



## DutchDaemon (Sep 17, 2014)

According to `/usr/local/bin/spamd --help` you can add -D, which is probably best done by defining 
	
	



```
spamd_flags="-D"
```
 in /etc/rc.conf (or adding the flag to an existing value -- note that it conflicts with any -d).


----------



## AzaShog (Sep 17, 2014)

DutchDaemon said:
			
		

> According to `/usr/local/bin/spamd --help` you can add -D



Thanks for your input. Yes, I know about that flag, that's the "verbose stderr output" I mentioned in my OP. I don't know how to use the rc subsystem to modify the rc script to log the stderr in a file somewhere. Because the rc script just defines the command and command params:


```
command=/usr/local/bin/${name}
command_args="-d -r ${pidfile}"
required_dirs="/usr/local/share/spamassassin"

...

run_rc_command "$1"
```


----------



## DutchDaemon (Sep 17, 2014)

Long shot. Try:


```
command_args="-D -r ${pidfile} > /var/log/${pidfile}.log 2>&1"
```

in the rc.d script.


----------



## AzaShog (Sep 17, 2014)

Okay, this partially works. It starts the daemon, it does debug output to the specified file but it drops out of RC control, the system thinks it is not running. Close enough, for now I guess, except that I don't like this abnormal state of it because I'm trying to debug why is sa-spamd failing under RC (or daemonized?) and not if run standalone.

Thanks, we'll see what happens in a few days.


----------



## AzaShog (Sep 23, 2014)

Well, it segfaulted again. These are the last few lines. Doesn't look helpful at all... Any ideas?


```
Tue Sep 23 14:50:32 2014 [1138] dbg: prefork: child closed connection
Tue Sep 23 14:50:32 2014 [1138] info: prefork: child states: BI
Tue Sep 23 14:50:33 2014 [1138] dbg: prefork: select returned err Interrupted system call, probably signalled
Tue Sep 23 14:50:33 2014 [1138] dbg: prefork: child 1139: just exited
Tue Sep 23 14:50:33 2014 [1138] dbg: prefork: child 1139: entering state 4
Tue Sep 23 14:50:33 2014 [1138] dbg: prefork: new lowest idle kid: 1140
Tue Sep 23 14:50:33 2014 [1138] info: spamd: handled cleanup of child pid [1139] due to SIGCHLD: exit 0
Tue Sep 23 14:50:33 2014 [1138] info: spamd: server successfully spawned child process, pid 11653
Tue Sep 23 14:50:33 2014 [1138] dbg: prefork: child 11653: entering state 0
Tue Sep 23 14:50:33 2014 [1138] dbg: prefork: new lowest idle kid: 1140
Tue Sep 23 14:50:33 2014 [11653] dbg: plugin: Mail::SpamAssassin::Plugin::Bayes=HASH(0x805b79408) implements 'spamd_child_init', priority 0
Tue Sep 23 14:50:33 2014 [11653] dbg: prefork: sysread(9) not ready, wait max 300.0 secs
Tue Sep 23 14:50:43 2014 [11653] dbg: prefork: parent closed, exiting
Tue Sep 23 14:50:43 2014 [1140] dbg: prefork: parent closed, exiting
```

And the only other helpful log is from syslog:


```
Sep 23 14:50:43 xxx kernel: pid 1138 (perl), uid 0: exited on signal 11 (core dumped)
```


----------



## Dyrcona (Dec 17, 2014)

I was having the same problem. I found that setting

```
spamd_flags=""
```
in /etc/rc.conf made the segfaults stop.

Spamd is being started with -c by default, and that option tells it to create user configuration files.

Since removing that option from spamd_flags makes the segfaulting stop, I assume the problem is related to the user that runs spamd not being able to read/create/update the users' prefs file.


----------

