Koozali.org: home of the SME Server
Legacy Forums => General Discussion (Legacy) => Topic started by: rkuenzli on April 21, 2005, 12:20:03 AM
-
Hi, I am unsing SME happily since years. Now I am using a fresh installed 6.0.1.
I tried to setup qmail with the server-manager, but suddenly it hangs. In /varlog/qmail I find
"@400000004266d25e10d3abac alert: unable to opendir info/0, sleeping...".
"service qmail stop" gives the result "failed".
Unfortnately I have not idea how to fix this.
Even the smtp proxy was hanging. I couldn't send emails from the LAN to my ISP anymore. This I "fixed" with "/sbin/e-smith/config setprop smtpfront-qmail Proxy disabled"
Is there an event or other command to reset/reinstall the whole qmail thing?
Thanks for any help or hint.
-
Hi, I am unsing SME happily since years. Now I am using a fresh installed 6.0.1.
I tried to setup qmail with the server-manager, but suddenly it hangs. In /varlog/qmail I find
"@400000004266d25e10d3abac alert: unable to opendir info/0, sleeping...".
"service qmail stop" gives the result "failed".
Unfortnately I have not idea how to fix this.
The "service" command only sometimes works on SME (so you should never use it). It is not aware of the configuration database, nor is it aware of "supervise".
To stop qmail, you need to do:
/etc/rc7.d/S*qmail stop
Even the smtp proxy was hanging. I couldn't send emails from the LAN to my ISP anymore. This I "fixed" with "/sbin/e-smith/config setprop smtpfront-qmail Proxy disabled"
This just means that qmail wasn't able to relay messages - but you already knew that. Disabling the proxy enabled direct connections to your ISP's mail server. Those are normally captured, to give your server an opportunity to block viruses, log all transactions, etc.
Is there an event or other command to reset/reinstall the whole qmail thing?
Thanks for any help or hint.
You can restart qmail with "/etc/rc7.d/S*qmail restart". But you should investigate why it couldn't open its queue directory. Either your disk structures are corrupted, or there was some resource starvation - e.g. no available file descriptors.
-
Hi Charlie
Thanks for your help and comments. You are right, it seems that I have accidently deleted some files in the directory /var/qmail/queue when I was playing with my SME a few days ago. Once I discoverd that, I just copied the whole /var/qmail/queue directory from an other SME server I have running et voila - problem solved (okay, that's brute force).
However, if I wouldn't have an other SME running, I would not know how to "reset" the whole qmail. So, the question remains, if there is a script on the SME which reinstalls the whole qmail. Until now, I only made backups of /home/e-smith.
I am surprised to learn that sometimes the "service" thing doesn't work. I like to use it because it's very handy and even here it was not the problem, I had to kill -9 the qmail processes anyway.
Anyway, I really like the SME, it's a rock solid distro! As I wrote elsewhere, if it fails it's the hardware (or in my case a playing user).
Thanks, Roland
-
Once I discoverd that, I just copied the whole /var/qmail/queue directory from an other SME server I have running et voila - problem solved (okay, that's brute force).
You could have had problems with that if the queue wasn't empty.
However, if I wouldn't have an other SME running, I would not know how to "reset" the whole qmail. So, the question remains, if there is a script on the SME which reinstalls the whole qmail.
There isn't such a script. If you think about it, it'd be hard to have a script which was able to replace any portions of any package that a reckless admin might delete.
Here's what you could do though:
rpm -Uhv --force qmail-1.03-08.i386.rpm
I am surprised to learn that sometimes the "service" thing doesn't work.
I've mentioned it here many times. It's a pity no-one seems to be maintaining an FAQ, because that's where it should be mentioned.
I like to use it because it's very handy and even here it was not the problem, I had to kill -9 the qmail processes anyway.
You should only use "kill -9" if nothing else works. Use "kill -TERM" and "kill -QUIT" in preference. But most service daemons in SME will be replaced by a new instance automatically if you kill them, so you shouldn't use kill at all.
The /etc/rc7.d symlinks should always work.
If a daemon is running under supervise, then:
svd -d /service/xxx
will bring it down (that's the equivalent of "./S25xxx stop" in the /etc/rc7.d directory).
Anyway, I really like the SME, it's a rock solid distro! As I wrote elsewhere, if it fails it's the hardware (or in my case a playing user).
Thanks, we're proud of it, and very happy that users find it useful.
-
I've mentioned it here many times. It's a pity no-one seems to be maintaining an FAQ, because that's where it should be mentioned.
I and some others do or how would you call that, Charlie?: http://no.longer.valid/phpwiki/index.php/SME%20Server%20FAQs
That's why i wanted a subscription to your answers at zero rate.
-
I've mentioned it here many times. It's a pity no-one seems to be maintaining an FAQ, because that's where it should be mentioned.
I and some others do or how would you call that, Charlie?: http://no.longer.valid/phpwiki/index.php/SME%20Server%20FAQs
Ah, sorry to misrepresent you, and the work of your team. The FAQ isn't very prominent, is it? There's a "Site info/FAQ" link over on the left, but that's for other information, which is less critical to users. Perhaps we can have the site managers promote the FAQ.
-
Yes, FAQ is not very prominent and in the wrong place. People have to click Documentation, scroll down, find SME Faq, click on it and click again for a category. That's too far away.
Jeff Coleman has suggested months ago that Site Info/FAQ should be reworked but shortly after that this unpleasent disputes between him and RequestedDeletion came up and the issue dropped also behind the Ruffdogs "deal" or whatever it is.
-
I'm adding to this post since I've just been through the same problem.
Unfortunatelly
Here's what you could do though:
rpm -Uhv --force qmail-1.03-08.i386.rpm
does not fix the problem.
The solution I found was to install qmHandle http://mirror.contribs.org/smeserver/contribs/saco/contrib/e-smith-qmHandle/e-smith-qmHandle-1.0.0-7.noarch.rpm and issued the command
qmHandle -D
-
Timely subject. Client complained today of slow response from his site. Checked with sysinfo from remote location. Large chunk of outgoing data could be seen clearly every half hours (duration around an hour) at 15-20kbps for past 24 hours. Nine items in queue ranging from 4-10MB. qmHandle -D fixed it in no time at all. Thanks to the power of searching, and thanks to the Community. chris (Phew.....I think I will have a Guiness now).