Koozali.org: home of the SME Server
Legacy Forums => Experienced User Forum => Topic started by: Scott on October 22, 2003, 02:51:54 PM
-
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.
-
You could try service smtpfront-qmail status (i think thats the process name)
See what that turns out
-
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
-
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?
-
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
-
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
-
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
-
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
-
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