IDs back from qmail-inject ?
Is there any way to get ANY kind of identifying information back from qmail-inject that can be used to later match the message up with log entries? Preferably the same kind of '952161799 qp 10208' kind of code that SMTP or QMTP gives me. Both stdout and stderr seem to produce nothing at all on success. It is important to me to account for everything, so I can know exactly what was delivered and what wasn't. And qmail-inject seems to be much the fastest way I can get things into the queue, so it would be very nice if I could also know whatever became of it. - Flemming
Re: sqwebmail with local accounts
At 09:02 PM 6/7/2000, John Stile wrote: >How do I use the web interface for accessing my real domain's user >accounts? >Virtual domains have no problems accessing mail, but this is so cool I >want to do it for my real accounts too. >Do I create a virtual domain, and add links to the home dir's of each >real unix account? >I tried to find it my self, and failed. Just point me to the right doc. The easiest seems to be to make all domains virtual. I.e. set up a virtual domain in qmailadmin with the same name as your "real" domain, and add the existing users to it, again in qmailadmin. And move their Maildirs to /home/vpopmail/domains/yourrealdomain.com/ And compile your vpopmail with the --enable-default-domain=yourrealdomain.com option, so that everything should work the same as before for those users. - Flemming
Duplicates
Many subscribers have been reporting duplicate messages in the last few days from a couple of qmail servers I manage that send out a daily newsletter with a few hundred thousand subscribers. Yet the logs only show one message delivered to any of those people. But usually several deferrals. I figure my timeoutremote was set too low (60), so that it got delivered even though qmail-remote thought it timed out. So I now put it up to 600. Does that make sense, or could there be other reasons for duplicates that don't show in the logs? The servers are generally rather busy, with 2-500 remote processes and a system load of 4-6, and I think the ISP was having some bandwidth problems in the last few days. - Flemming
Re: QMail Performance Question & Miscellaneous Issues
At 02:40 AM 5/10/2000, Neil Schemenauer wrote: >You should find the bottleneck before you jump to any >conclusions. What version of the Linux kernel are you using? 2.2.12 compiled with higher process limit (4090), higher file and inode limits (16000/48000), smp support, and drivers for SCSI and network card compiled in. >Do >you have any strange looking error messages in your log files? Nothing that looks unusual. A ton of "in.identd started" messages. No unusual error messages. >What does "vmstat 1" show? I didn't know that one. I'll check when the servers are busy the next time. Generally top shows relatively low memory use and no swap space used. >Perhaps you should install sar(sp?) >and profile your disk IO. I don't think sar or sarcheck runs on Linux at this point, as far as I can quickly figure out. But something like that would be very useful. At 07:09 AM 5/10/2000, Ricardo D. Albano wrote: >Are you using syslogd ? No. Or, rather, it is there, but I'm not using it for qmail, so it is not doing much. Back when I was using sendmail and syslogd, that was indeed a big bottleneck, ending up consuming a majority of server resources. At 10:09 AM 5/10/2000, [EMAIL PROTECTED] wrote: >It's not clear to me that these are valid comparisons. Is the 12mill per day >mean 12M individual messages individually queued? Are is it a much smaller >number of messages with a larger number of recipients? I'd like to know that too. What I'm doing is individual messages individually queued, so if somebody can get 12M that way, I'm certainly paying attention. I'd be perfectly happy doing 2M per machine without crashing anything. >While it's hard to tell without looking, my guess is that your inbound >submission rate is killing the spindle that your disk lives on. Sort of looks like it. I suppose there is no meaningful way of separating the stuff I put in from what needs to go out, as it is obviously the same queue. And, still, I don't get it. I can't seem to feed much more than 60,000 messages per hour into the queue. That's between two machines standing next to each other, on a 100Mbps switched network. SMTP or QMTP seems to make no difference. That's no faster than the machine can go and deliver the messages remotely, when it is in a good mood, and nothing is coming in at the time. I would be able to create 60,000 mail message files in a couple of minutes. Should I be thinking along the lines of putting the files directly into the queue myself? I'd really be much more comfortable leaving that kind of stuff to qmail-qmtp and qmail-queue. >In other words, expect to reach your concurrencyremote. Not getting their >when everything appears right, is a sign of some other underlying problem. Now, after saying all of this, I did get a hint yesterday that my outgoing bottleneck might possibly relate to bandwidth problems. I was mailing from 3 machines at the same time, each with around 100,000 messages in the queue and concurrencyremote set at 200. And for the first time I saw one of them actually sneak up to 200, with ~3Mbps outgoing traffic, without even working very hard. However, while the other two were idling around 20-30. And a little later another of the machines went up towards 200, while the first one dropped down to 20-30. Seemed kind of bizarre, but might indicate some kind of "smart" network switch that's trying to apportion out bandwidth according to some algorhitm. I'm looking into that. - Flemming
RE: QMail Performance Question & Miscellaneous Issues
At 09:39 AM 5/9/2000, Matthew B. Henniges wrote: >On a dual celeron 466 with 512Mb ram. and 3 10k scsi drives (one for >/var/qmail/queue, one for /var/log, one for /usr/home) >concurrency remote at 500 >concurrency local at 50 >FreeBSD 3.4-S >localhost dnscache > >It will push 12 Million on a good day. (4% local delivery). > >This is qmail 1.03 + big-todo + big-concurrency + qmailqueue I'm green with envy. Now, I administer around 6 qmail servers. Typically a dual-600PIII with 1G of RAM, with /var on a 10K SCSI, and everything else on other disks. I also use qmail 1.03 + big-todo + big-concurrency. Remote concurrency set for 200. Queue set for a split of 293. Linux RH6.1 or 2. Outgoing mail is handled on different servers than the incoming. The machines are co-located on several different networks with plenty of bandwidth. The machines are mostly sending out daily newsletters which are being fed in from another machine by smtp or qmtp (seems to make no difference in performance which I use), and I've experimented with various numbers of incoming smtp processes. If I'm sending more in more than a couple of smtp connections at the same time (e.g. 10 or 20), concurrent remote processes drop to a crawl of 2-10, the machine's load gets really high, 6-20, and the queue gets filled up quickly. If nothing is coming in, the remote processes usually are 20-80, and only on a very rare occasion would get close to my 200 concurrencyremote. So .. eh... would it likely be my disk I/O that slows it down (how do I test that?), or should I be switching to FreeBSD, or am I doing something stupid? What is localhost dnscache about? A local name server, to limit outgoing DNS lookups? - Flemming
qmail needs more time to finish. Sleeping 1 second...
In all my qmail installations it often takes forever to shutdown or restart qmail. I'm getting the message: "qmail needs more time to finish. Sleeping 1 second..." which keeps repeating for sometimes 1/2 or a whole hour. Longer when the mail queue is large. Like, right now it has been about 1.5 hours on one machine which has about 250,000 messages waiting in the queue. I'm not quite sure what program is giving the message. I'm on RedHat6.2, I'm using ucspi-tcp and daemon tools. My qmail is from qmail-1.03-102memphis.src.rpm. I restart qmail with: /etc/rc.d/init.d/qmail.init restart Am I doing something wrong, or this how it is supposed to be? And, if so, is there a faster way of shutting down qmail? This same thing will happen if I need to reboot the server. It might be delayed for 1 hour or so, waiting for qmail to shut down. Nothing is being sent while qmail "needs more time". The remote processes die out pretty quickly. Help! - Flemming
