On 2018-01-01 17:26, Peter wrote:> On 02/01/18 14:07, Stephan Bosch wrote: >>> I can see 21:21:38 is when the below errors showed up with the above >>> 21:21:38 timestamps: >>> >>> Dec 29 21:21:38 >>> lmtp(recipient at domain.net)<17187><UA2fMEQiR1ojQwAAUXb6+w>: Error: >>> program `/usr/sbin/sendmail' was forcibly terminated with signal 15 >>> Dec 29 21:21:38 >>> lmtp(recipient at domain.net)<17187><UA2fMEQiR1ojQwAAUXb6+w>: Error: >>> sieve: msgid=<470c210f-bd19-f63f-45ed-bfef59322be9 at domain.email>: >>> failed to send vacation response to sender at domain.email: <Failed to >>> execute sendmail> (temporary error) >>> Dec 29 21:21:38 lmtp: Error: postdrop: warning: mail_queue_enter: >>> create file maildrop/868503.17337: Permission denied >>> >>> It still isn't really clear to me why this is going on. >> >> I am wondering what that sendmail process is doing. >> >> As you can see, Dovecot waits for it to finish for 30 seconds >> (override >> with submission_timeout setting). >> >> Can you try invoking sendmail manually from command line? Does it >> work? >> Is it hanging for more than 30s? > > I think the real error here is the postdrop one (sendmail is a wrapper > around postdrop). It's a permission denied error which leads me to > believe it may be an selinux (or similar) issue. I wouldn't be > surprised if sendmail works from the command line but fails when > executed from sieve because selinux has it blocked for sieve. > > If you're running selinux or apparmour or similar, check your logs for > that (audit log for selinux) and look for denials. You cna also try > setting selinux to permissive and trying the operation (setenforce 0). > > > Peter> I am wondering what that sendmail process is doing. > > As you can see, Dovecot waits for it to finish for 30 seconds (override > with submission_timeout setting). > > Can you try invoking sendmail manually from command line? Does it work? > Is it hanging for more than 30s? > > Regards, > > Stephan.Thanks for the responses. Running sendmail from the command line is successful, which strikes me as odd. So it is only failing when sendmail is invoked from sieve, but I don't yet understand why. I haven't made any recent significant changes to the mail environment. I haven't updated from postfix 3.2.4-2 since 12-16-17 when my distribution released the packaged updated, but I didn't notice the issue at that time until around 12-27 when I started getting emails about the reported permission denied error and sendmail timeout.
Stephan Bosch
2018-Jan-03 00:58 UTC
Updated Dovecot 2.3.0 now getting 2 strange log errors
Op 1/3/2018 om 1:37 AM schreef tony:> On 2018-01-01 17:26, Peter wrote: >> On 02/01/18 14:07, Stephan Bosch wrote: >>>> I can see 21:21:38 is when the below errors showed up with the above >>>> 21:21:38 timestamps: >>>> >>>> Dec 29 21:21:38 >>>> lmtp(recipient at domain.net)<17187><UA2fMEQiR1ojQwAAUXb6+w>: Error: >>>> program `/usr/sbin/sendmail' was forcibly terminated with signal 15 >>>> Dec 29 21:21:38 >>>> lmtp(recipient at domain.net)<17187><UA2fMEQiR1ojQwAAUXb6+w>: Error: >>>> sieve: msgid=<470c210f-bd19-f63f-45ed-bfef59322be9 at domain.email>: >>>> failed to send vacation response to sender at domain.email: <Failed to >>>> execute sendmail> (temporary error) >>>> Dec 29 21:21:38 lmtp: Error: postdrop: warning: mail_queue_enter: >>>> create file maildrop/868503.17337: Permission denied >>>> >>>> It still isn't really clear to me why this is going on. >>> >>> I am wondering what that sendmail process is doing. >>> >>> As you can see, Dovecot waits for it to finish for 30 seconds (override >>> with submission_timeout setting). >>> >>> Can you try invoking sendmail manually from command line? Does it work? >>> Is it hanging for more than 30s? >> >> I think the real error here is the postdrop one (sendmail is a wrapper >> around postdrop).? It's a permission denied error which leads me to >> believe it may be an selinux (or similar) issue.? I wouldn't be >> surprised if sendmail works from the command line but fails when >> executed from sieve because selinux has it blocked for sieve. >> >> If you're running selinux or apparmour or similar, check your logs for >> that (audit log for selinux) and look for denials.? You cna also try >> setting selinux to permissive and trying the operation (setenforce 0). >> >> >> Peter > >> I am wondering what that sendmail process is doing. >> >> As you can see, Dovecot waits for it to finish for 30 seconds (override >> with submission_timeout setting). >> >> Can you try invoking sendmail manually from command line? Does it work? >> Is it hanging for more than 30s? >> >> Regards, >> >> Stephan. > > Thanks for the responses. Running sendmail from the command line is > successful, which strikes me as odd. So it is only failing when > sendmail is invoked from sieve, but I don't yet understand why. I > haven't made any recent significant changes to the mail environment. I > haven't updated from postfix 3.2.4-2 since 12-16-17 when my > distribution released the packaged updated, but I didn't notice the > issue at that time until around 12-27 when I started getting emails > about the reported permission denied error and sendmail timeout.Did you consider Peter's suggestion about selinux and the like? Is the sendmail binary even executable from the same uid/gid as Sieve would be using during deliver? Regards, Stephan.
On 2018-01-02 16:37, tony wrote:> On 2018-01-01 17:26, Peter wrote: >> On 02/01/18 14:07, Stephan Bosch wrote: >>>> I can see 21:21:38 is when the below errors showed up with the above >>>> 21:21:38 timestamps: >>>> >>>> Dec 29 21:21:38 >>>> lmtp(recipient at domain.net)<17187><UA2fMEQiR1ojQwAAUXb6+w>: Error: >>>> program `/usr/sbin/sendmail' was forcibly terminated with signal 15 >>>> Dec 29 21:21:38 >>>> lmtp(recipient at domain.net)<17187><UA2fMEQiR1ojQwAAUXb6+w>: Error: >>>> sieve: msgid=<470c210f-bd19-f63f-45ed-bfef59322be9 at domain.email>: >>>> failed to send vacation response to sender at domain.email: <Failed to >>>> execute sendmail> (temporary error) >>>> Dec 29 21:21:38 lmtp: Error: postdrop: warning: mail_queue_enter: >>>> create file maildrop/868503.17337: Permission denied >>>> >>>> It still isn't really clear to me why this is going on. >>> >>> I am wondering what that sendmail process is doing. >>> >>> As you can see, Dovecot waits for it to finish for 30 seconds >>> (override >>> with submission_timeout setting). >>> >>> Can you try invoking sendmail manually from command line? Does it >>> work? >>> Is it hanging for more than 30s? >> >> I think the real error here is the postdrop one (sendmail is a wrapper >> around postdrop). It's a permission denied error which leads me to >> believe it may be an selinux (or similar) issue. I wouldn't be >> surprised if sendmail works from the command line but fails when >> executed from sieve because selinux has it blocked for sieve. >> >> If you're running selinux or apparmour or similar, check your logs for >> that (audit log for selinux) and look for denials. You cna also try >> setting selinux to permissive and trying the operation (setenforce 0). >> >> >> Peter > >> I am wondering what that sendmail process is doing. >> >> As you can see, Dovecot waits for it to finish for 30 seconds >> (override >> with submission_timeout setting). >> >> Can you try invoking sendmail manually from command line? Does it >> work? >> Is it hanging for more than 30s? >> >> Regards, >> >> Stephan. > > Thanks for the responses. Running sendmail from the command line is > successful, which strikes me as odd. So it is only failing when > sendmail is invoked from sieve, but I don't yet understand why. I > haven't made any recent significant changes to the mail environment. I > haven't updated from postfix 3.2.4-2 since 12-16-17 when my > distribution released the packaged updated, but I didn't notice the > issue at that time until around 12-27 when I started getting emails > about the reported permission denied error and sendmail timeout.Apologies for sending too early. I meant to hit save and not sent. I wanted to point out that I am not using SELinux or AppArmor. The hosts just use some iptables rules, but traffic is permitted to and from these hosts, so I don't think that is the issue. There are several places that talk about correcting permissions, but when I verify the permissions on /var/lib/postfix everything is as it should be. postfix set-permissions postfix check The above results in no output reporting any problems. I enabled sieve tracing but did not see anything that stood out apart from the usual reported errors. If I invoke sendmail from the vmail user I am able to send no problem. It doesn't make sense why sieve in general not related to Vacation auto-replies works fine, but auto-replies do not. - TC
On 2018-01-02 17:21, tony wrote:> On 2018-01-02 16:37, tony wrote: >> On 2018-01-01 17:26, Peter wrote: >>> On 02/01/18 14:07, Stephan Bosch wrote: >>>>> I can see 21:21:38 is when the below errors showed up with the >>>>> above >>>>> 21:21:38 timestamps: >>>>> >>>>> Dec 29 21:21:38 >>>>> lmtp(recipient at domain.net)<17187><UA2fMEQiR1ojQwAAUXb6+w>: Error: >>>>> program `/usr/sbin/sendmail' was forcibly terminated with signal 15 >>>>> Dec 29 21:21:38 >>>>> lmtp(recipient at domain.net)<17187><UA2fMEQiR1ojQwAAUXb6+w>: Error: >>>>> sieve: msgid=<470c210f-bd19-f63f-45ed-bfef59322be9 at domain.email>: >>>>> failed to send vacation response to sender at domain.email: <Failed to >>>>> execute sendmail> (temporary error) >>>>> Dec 29 21:21:38 lmtp: Error: postdrop: warning: mail_queue_enter: >>>>> create file maildrop/868503.17337: Permission denied >>>>> >>>>> It still isn't really clear to me why this is going on. >>>> >>>> I am wondering what that sendmail process is doing. >>>> >>>> As you can see, Dovecot waits for it to finish for 30 seconds >>>> (override >>>> with submission_timeout setting). >>>> >>>> Can you try invoking sendmail manually from command line? Does it >>>> work? >>>> Is it hanging for more than 30s? >>> >>> I think the real error here is the postdrop one (sendmail is a >>> wrapper >>> around postdrop). It's a permission denied error which leads me to >>> believe it may be an selinux (or similar) issue. I wouldn't be >>> surprised if sendmail works from the command line but fails when >>> executed from sieve because selinux has it blocked for sieve. >>> >>> If you're running selinux or apparmour or similar, check your logs >>> for >>> that (audit log for selinux) and look for denials. You cna also try >>> setting selinux to permissive and trying the operation (setenforce >>> 0). >>> >>> >>> Peter >> >>> I am wondering what that sendmail process is doing. >>> >>> As you can see, Dovecot waits for it to finish for 30 seconds >>> (override >>> with submission_timeout setting). >>> >>> Can you try invoking sendmail manually from command line? Does it >>> work? >>> Is it hanging for more than 30s? >>> >>> Regards, >>> >>> Stephan. >> >> Thanks for the responses. Running sendmail from the command line is >> successful, which strikes me as odd. So it is only failing when >> sendmail is invoked from sieve, but I don't yet understand why. I >> haven't made any recent significant changes to the mail environment. I >> haven't updated from postfix 3.2.4-2 since 12-16-17 when my >> distribution released the packaged updated, but I didn't notice the >> issue at that time until around 12-27 when I started getting emails >> about the reported permission denied error and sendmail timeout. > > Apologies for sending too early. I meant to hit save and not sent. I > wanted to point out that I am not using SELinux or AppArmor. The hosts > just use some iptables rules, but traffic is permitted to and from > these hosts, so I don't think that is the issue. There are several > places that talk about correcting permissions, but when I verify the > permissions on /var/lib/postfix everything is as it should be. > > postfix set-permissions > postfix check > > The above results in no output reporting any problems. I enabled sieve > tracing but did not see anything that stood out apart from the usual > reported errors. If I invoke sendmail from the vmail user I am able to > send no problem. It doesn't make sense why sieve in general not > related to Vacation auto-replies works fine, but auto-replies do not. > > - > TCI downgraded dovecot to 2.2.33.2 and pigeonhole 0.4.21 and can confirm the reported problem does not exist with "permission denied" and sendmail getting hung up/timing out. - Cheers, TC
Possibly Parallel Threads
- Updated Dovecot 2.3.0 now getting 2 strange log errors
- Updated Dovecot 2.3.0 now getting 2 strange log errors
- Updated Dovecot 2.3.0 now getting 2 strange log errors
- Updated Dovecot 2.3.0 now getting 2 strange log errors
- Updated Dovecot 2.3.0 now getting 2 strange log errors