Re: [courier-users] submit timeout
Gordon Messmer writes: On 10/23/2012 03:39 PM, Sam Varshavchik wrote: > > I'll look into it. Checking in on this, too... Did you ever get a chance to look at extending the submit process' timeout? Yes, I have the change. There was one other detail that needed to be done. There is existing code that resets the submit timeout every 1 bytes, so if a message trickles in, the alarm does get reset, but this would not've helped you. I'm just changing it to a 36 hour absolute timer, that's it. pgpIwjtlgCiTJ.pgp Description: PGP signature -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] submit timeout
On 10/23/2012 03:39 PM, Sam Varshavchik wrote: > > I'll look into it. Checking in on this, too... Did you ever get a chance to look at extending the submit process' timeout? Thanks, Sam. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] submit timeout
>>> And, in any case, starting sendmail/submit, then doing nothing for half >>> an hour, that seems rather broken to me. The timeout is not issue, here. >>> Something's wrong with this entire concept. >Gordon Messmer writes: >>A cron job might not have output for a very long time, but cron launches >>sendmail before it runs jobs, and connects the job's output to >>sendmail's input. On 23.10.12 08:31, Sam Varshavchik wrote: >The correct way to handle that is to redirect the message into a >temporary file. When you're ready to send the message, then make the >connection, and send it on the way. the SSMTP is supposed to take the mail body, send it to SMTP server and return error code according to what the server replied. This way the sending program can know if the mail was accepted or not. The downside is the timeout. Maybe SSMTP could do something moreto avoid timeouts, hower this is a case where it's not courier, ssmtp or cron can make the decision which behaviour is the correct one. Therefore I think the request for increasing DATA timeout has its logic. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Enter any 12-digit prime number to continue. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] submit timeout
Gordon Messmer writes: On 10/23/2012 05:31 AM, Sam Varshavchik wrote: > > The correct way to handle that is to redirect the message into a > temporary file. When you're ready to send the message, then make the > connection, and send it on the way. I agree, but I didn't write cron or ssmtp. They're intentionally designed not to write output to disk, and patching those on embedded devices is much more difficult than patching submit to extend the timeout. > The problem here is that there are processes that remove old files in > the temporary directory where the incoming message gets initially saved. It looks like courierd does that for files older than 48 hours. Extending the submit timeout shouldn't cause a problem here. I'll look into it. pgp0FFSbO1A05.pgp Description: PGP signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] submit timeout
On 10/23/2012 05:31 AM, Sam Varshavchik wrote: > > The correct way to handle that is to redirect the message into a > temporary file. When you're ready to send the message, then make the > connection, and send it on the way. I agree, but I didn't write cron or ssmtp. They're intentionally designed not to write output to disk, and patching those on embedded devices is much more difficult than patching submit to extend the timeout. > The problem here is that there are processes that remove old files in > the temporary directory where the incoming message gets initially saved. It looks like courierd does that for files older than 48 hours. Extending the submit timeout shouldn't cause a problem here. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] submit timeout
Gordon Messmer writes: > And, in any case, starting sendmail/submit, then doing nothing for half > an hour, that seems rather broken to me. The timeout is not issue, here. > Something's wrong with this entire concept. A cron job might not have output for a very long time, but cron launches sendmail before it runs jobs, and connects the job's output to sendmail's input. The correct way to handle that is to redirect the message into a temporary file. When you're ready to send the message, then make the connection, and send it on the way. I can continue to patch Courier and make the timeout longer for my own systems, but I wanted to ask since at least for me submit running for a long time is never an issue (particularly as esmtpd has its own timeout, and it can be configured), but SSMTP support is. The problem here is that there are processes that remove old files in the temporary directory where the incoming message gets initially saved. Doing nothing for hours risks the temporary message getting deleted, and causing all sorts of issues. I don't recall, at the moment, what are the expiration times for files in Courier's tmp directory, at which point they are subject to removal, but doing this risks losing all mail. This is not as simple as setting the timeout to be something unreasonably large. pgpIRME6PMD7M.pgp Description: PGP signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] submit timeout
On 10/22/2012 08:11 PM, Sam Varshavchik wrote: > If it's connecting via SMTP, the SMTP timeout is much shorter, and > should kick in much earlier. If it's a local connection, I don't see the > point of SSMTP. What value does it add, exactly, versus sending mail > directly. It's SMTP. Courier's SMTP timeout is, by default, shorter than submit's, but I can configure the SMTP timeout. The submit timeout can't be configured. Especially since there is, already, an SMTP timeout it seems unnecessary for submit to have a timeout of its own. If it has to be there, I'd rather that it be configurable so that I can make sure that the two match. The point of SSMTP is that a small device can have /usr/bin/sendmail symlinked to ssmtp, which is a much smaller application. ssmtp connects to an SMTP server, conducts the SMTP conversation on behalf of applications that are only designed to use /usr/bin/sendmail, and otherwise directly transmits the data that it gets. Since it doesn't do local queuing, it can be used on devices with no writable disk space and limited memory. > And, in any case, starting sendmail/submit, then doing nothing for half > an hour, that seems rather broken to me. The timeout is not issue, here. > Something's wrong with this entire concept. A cron job might not have output for a very long time, but cron launches sendmail before it runs jobs, and connects the job's output to sendmail's input. I can continue to patch Courier and make the timeout longer for my own systems, but I wanted to ask since at least for me submit running for a long time is never an issue (particularly as esmtpd has its own timeout, and it can be configured), but SSMTP support is. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] submit timeout
Gordon Messmer writes: On 10/22/2012 04:26 PM, Sam Varshavchik wrote: > I'm not sure I understand the problem. Why would it take Courier more > than 30 minutes to accept a single message? Sorry. SSMTP doesn't do any local queing. It connects to the destination server and sends output as it is received. Where we have long-running cron jobs, cron will launch ssmtp, and the resulting SMTP session will remain open until the job finishes and output is closed. The submit timeout causes submit to close, while the SMTP session stays open and fails later, unable to write to the pipe to the submit process (IIRC). If it's connecting via SMTP, the SMTP timeout is much shorter, and should kick in much earlier. If it's a local connection, I don't see the point of SSMTP. What value does it add, exactly, versus sending mail directly. And, in any case, starting sendmail/submit, then doing nothing for half an hour, that seems rather broken to me. The timeout is not issue, here. Something's wrong with this entire concept. pgpAvstUFMo3z.pgp Description: PGP signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] submit timeout
On 10/22/2012 04:26 PM, Sam Varshavchik wrote: > I'm not sure I understand the problem. Why would it take Courier more > than 30 minutes to accept a single message? Sorry. SSMTP doesn't do any local queing. It connects to the destination server and sends output as it is received. Where we have long-running cron jobs, cron will launch ssmtp, and the resulting SMTP session will remain open until the job finishes and output is closed. The submit timeout causes submit to close, while the SMTP session stays open and fails later, unable to write to the pipe to the submit process (IIRC). -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] submit timeout
Gordon Messmer writes: Sam, I support a number of embedded devices and systems that use SSMTP rather than a full MTA. Those end up working poorly with Courier due to the timeout in 'submit' which is hard-coded. Would you consider making that much larger, or removing it entirely? I'm not sure I understand the problem. Why would it take Courier more than 30 minutes to accept a single message? pgpkBwkBSaprF.pgp Description: PGP signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
