Topic: SMTP not logging

[Scott]

Hi

About two days ago I noticed that nothing was getting logged to the smtpfront-qmail log.  Its just stopped working...

Is there a service I can check to see if it was been disabled? How can I do this and restart if necessary?

I tried a logrotate, which rotated most of the other logs but smtp still has data from a few days ago.

Any help is appreciated.

[Byte]

You could try service smtpfront-qmail status (i think thats the process name)

See what that turns out

[Michael Soulier]

Scott wrote:
>
> About two days ago I noticed that nothing was getting logged
> to the smtpfront-qmail log.  Its just stopped working...
>
> Is there a service I can check to see if it was been
> disabled? How can I do this and restart if necessary?
>
> I tried a logrotate, which rotated most of the other logs but
> smtp still has data from a few days ago.

smtpfront-qmail, and anything else running under supervise, uses multilog for it's logging, and log rotation. It sounds like multilog is not running. Try the following

svstat /service/smtpfront-qmail
svstat /service/smtpfront-qmail/log

If the second one is down, try this.

cd /service/smtpfront-qmail
svc -d . ./log
svc -u . ./log

And repeat the svstat commands above.

Mike

[Scott]

svstat /service/smtpfront-qmail/log

shows

/service/smtpfront-qmail/log: supervise not running

when I run

svc -d . ./log
svc -u . ./log

i get this both times:

svc: warning: unable to control ./log: supervise not running

-----------
What now? and why would the logging get shut down?

[Jens Kruuse]

Why it shut down is probably a mystery, but you are not the only person who has experienced this. See http://www.e-smith.org/bboard//read.php?f=3&i=37808&t=35121&v=f

Cheers,
Jens

[Charlie Brady]

Scott wrote:

> i get this both times:
>
> svc: warning: unable to control ./log: supervise not running

I would guess that is a permissions problem.

> -----------
> What now? and why would the logging get shut down?

I don't know. Unless you have done modifications to your system which might cause the problem, then it's fair to say that your system is malfunctioning and you should provide a detailed report to smebugs@mitel.com, so that they can find and fix the problem.

Charlie

[Michael Doerner]

Hi,

I recently ran into the same problem and have to blame myself for causing this after I installed a contribution ("dsbl" - to filter incoming mails against the Distributed Server Boycott List) the wrong way!

It had to be a permission problem - exactly as Charlie guessed and I found the following on the "bad" server:

ls -l /var/service/smtpfront-qmail/
total 28
-rw-r--r--    1 root     root            0 Oct 25 18:01 down
drwxr-xr-x    2 root     root         4096 Oct 25 17:46 env
drwxr-xr-t    3 root     root         4096 Oct 25 18:01 log
-r-xr-xr-x    1 root     root           36 Mar 19  2003 rblsmtpd.conf
-r-xr-xr-x    1 root     root         1265 Jul  7 14:50 run
-rwxr-xr-x    1 root     root         1272 Feb 11  2003 run.orig
-r-xr-xr-x    1 root     root           91 Mar 19  2003 smtpfront-qmail
drwx------    2 root     root         4096 Oct 27 06:10 supervise

(Note the missing owner's write permissions on some files).

This is as it looks on a "good" SME 5.6 server (dsbl was also installed earlier):

ls -l /var/service/smtpfront-qmail/
total 28
-rw-r--r--    1 root     root            0 Feb 11  2003 down
drwxr-xr-x    2 root     root         4096 Oct 25 11:33 env
drwxr-xr-t    3 root     root         4096 Sep 20 07:54 log
-rw-r--r--    1 root     root           36 Mar 19  2003 rblsmtpd.conf
-rwxr-xr-x    1 root     root         1272 Feb 11  2003 run
-rwxr-xr-x    1 root     root         1272 Feb 11  2003 run.orig
-rwxr-xr-x    1 root     root           91 Mar 19  2003 smtpfront-qmail
drwx------    2 root     root         4096 Oct 27 06:07 supervise

Why was this my fault? How could this happen?

The dsbl install comes as a small archive (.tar file). After untar it's install script copies the new file versions for run, smtpfront-qmail, etc. into /var/service/smtpfront-qmail (and backs up the original files).

I had created my "Contribs Installation CD" for various contribs on a Windows-PC and just copied the untarred directory for the dsbl install rather than doing the untar on the target system again.
I must have lost the files' write permissions on that way when creating the CD under Windows.... I won't do that again!

Regards,
Michael Doerner

[Charlie Brady]

Michael Doerner wrote:

> Why was this my fault? How could this happen?
>
> The dsbl install comes as a small archive (.tar file). After
> untar it's install script copies the new file versions for
> run, smtpfront-qmail, etc. into /var/service/smtpfront-qmail
> (and backs up the original files).
>
> I had created my "Contribs Installation CD" for various
> contribs on a Windows-PC and just copied the untarred
> directory for the dsbl install rather than doing the untar on
> the target system again.

If Darrell had just directed people to use my RPM, and edit the config file if necessary, rather than repackaging files from my RPM as a tarball, you wouldn't have had the problem, Michael. So you can share the blame

Darrell, I'd appreciate it if you would remove the tarball from your contrib directory, and put a copy of my RPM there in its place. Feel free to modify the rpm to add your log management stuff, of course.

Could you also please add a reference to the GPL status of the code to your HOWTO, and also license the HOWTO to be redistributed.

Charlie

[Michael Doerner]

Thanks for the reply Charlie.

I would prefer to use an rpm and I had not realised that your's is actually doing exactly (?) the same job.
I still have problems to find the documentation in an rpm (which dependencies, which SME version is supported, etc.) but this is probably my lack of knowledge in that area.
I will try the rpm on a 6.0b3 test system.
Thanks,
Michael