Scalix Forums

This happend a few days ago too. I had posted the errors here, but have yet to get any help. Well, it happend again last night. Here are the error logs:



I would really like to know what I can do about this. What does thie error even mean? What's a 'segmentation violation'?

Thanks

Hm.

I believe we'll need to know what message causes this.

one way to determine this is to log the whole SMTP conversation up to the point of error. the way to do this is to add the following line to /var/opt/scalix/sys/smtpd.cfg:

DEBUG_LOG=true

and restarting the smtpd process using

omoff -d 0 -w smtpd; omon -w smtpd

That will create a smtpd.log file in /var/opt/scalix/tmp. Be careful, the file will grow rapidly because it will contain your incoming email traffic. you might want to truncate it regularly until the error happens again.

the error is some kind of internal error that might actually point to a bug in the smtp relay. Which version of scalix are you using?

Florian.

I have added the DEBUG_LOG=true line to my smtpd.cfg, and restarted the smtpd service.

If/when this happens again, I will post the offending data here.

I am running Scalix version 9.4.0.52

ok, just check if the logfile is there.

when you truncate, note that you cannot delete it as the smtpd server process will keep it open, so the way to truncate is to use the ">" syntax...... you might want to copy away the old stuff and gzip it first eventually. or use logrotate.

--- f.

A file called smtpd.log has appeared in the /var/opt/scalix/tmp folder. It's about 1.4MB and getting bigger.

I'm afraid I don't know the command(s) to truncate the file. I was planning just opening it up in the text editor, deleting the older data, and saving it again. Will that not work, or is there a faster way?

cd /var/opt/scalix/tmp

>smtpd.log

:-) truncates, but keeps the original file! :-)

-- f.

Until I can get this issue resolved, could I just make a cron job to execute 'omon smtpd' every hour? Or would that create more problems than it solves?

During the day, I can monitor it. But if it's off all night, that could be a lot of emails being kicked back to the senders....

you can run a script that does that.

problem is we really want to know what caused the issue.

if you can write a script that

check-if-it-still-running...
if-not-running-then-save-smtpd.log in-some-place and restart.
if running, stop, truncate file, restart

every hour, that would be super-useful.

-- .f

It's getting worse. The relay stopped a few minutes ago, and now it won't stay 'up'. I can start it, but it just stops again. Here is what was in the smtpd.log at the time:

The crash seems to be happening every time services@billsblue.com is submitting a message. Is this an automated process that's trying to submit messages ?

Is there a reason why it needs to issue the RSET command before sending the MAIL FROM command ?

I've tried this on my 9.4 server and the problem does not occur.

Can you post the uncommented sections from /var/opt/scalix/sys/smtpd.cfg ?

Cheers

Dave

Services@billsblue.com is our primamry email account. It mostly receives messages, and rarely sends them. But sometimes a user will send a message using that account.

I do have a syslog running on another server that will automatically send an email to me is ceratin events occur. The syslog software requires a valid 'from' address, and I have been using services@billsblue.com.

We have several users who use IMAP to monitor the 'services' inbox.

I don't know what the RSET means.

Here is all the uncommented stff from smtpd.cfg:

I *think* I have resolved this. In the syslog software I mentioned, I changed the from address to read 'services@bbpi-pdc.billsblue.com' (I added our internal domain to the address). Within a few minutes, I started receiving emails again, and SMTP relay has been up for 10 minutes now.

I'm not sure why this worked fine for the past few months, and just now decided to completely fail. But at least it (appears) to ahve been solved.

Thanks for your help Dave and Florian