stream_select(): unable to select [4]: Interrupted system call (max_fd=7) in SMTP.php on 1116

[c-prompt]

Received two of the same errors in my error queue this evening and, for the life of me, I can't figure out how to troubleshoot. The relevant errors and stack trace from sending the email are:

WARNING: stream_select(): unable to select [4]: Interrupted system call (max_fd=7) in phpMailer/SMTP.php on 1116

Backtrace

phpMailer/PHPMailer.php 1310 calling postSend()

phpMailer/PHPMailer.php 1468 calling smtpSend()

phpMailer/PHPMailer.php 1712 calling smtpConnect()

phpMailer/PHPMailer.php 1867 calling connect()

phpMailer/SMTP.php 372 calling get_lines()

phpMailer/SMTP.php 1116 calling stream_select()

Sending emails has worked ample times before so I don't know what was special about this particular email. I've reviewed #604 and am wondering if it's related. Can anyone suggest how to troubleshoot or what may cause such an error? PHP v.7.0.25, PHPMailer 6.0.1, Debian 9. Thanks.

[Synchro]

I've run into this as well - see these PRs in reactphp and symfony. From what I've seen, it's caused by having a process signal occur while PHPMailer is waiting for stream_select to return. For this to happen, you'd need to be making use of pcntl calls, probably running your script in a daemon-like process - does that sound like what you're doing?

[c-prompt]

Thanks Synchro for the quick reply.

I just did a check in my codebase to confirm there isn't any use of pcntl_signal. The first of the two identical errors was generated via a non-daemon process (i.e., immediately send out a confirmation email when a user signs up). The second error appears to have generated a few minutes later when a cron saw an unsent email and went to resend it. (Whether or not the original email was sent is unclear from my log but the sent flag, at minimum, wasn't changed from false to true, thus prompting the cron to try to resend.)

I'm not sure what would have killed off the process either time but I do see public $Timeout = 300 on line 140 of SMTP.php and am wondering if this might be a contributing factor (as my server times out at 90 seconds for a process). Could it be that PHPMailer should first check what PHP.ini (or the main app's) default is set to before assigning its own (i.e., if PHP.ini's timeout is lower, use that; otherwise, use 300)? The email was eventually successfully resent so I doubt it had anything to do with the message itself.

[Synchro]

PHP's CLI SAPI has no time or memory limit by default - those settings usually only apply to CGI SAPIs. Those timeout values are from the SMTP spec, and if that's longer than script timeouts, that's really the environment's problem.

This problem can occur if any process receives a signal when PHPMailer is waiting on stream_select - and that's much more likely with daemon or cron scripts that tend to run for longer. It doesn't necessarily have to kill the process, any kind of signal may do it I think. Looking at the patches for the other instances I pointed at, it looks like we should check the return value and then it should be safe to suppress the warning.

[c-prompt]

Good points about the timeouts and specs. Difficult to tell from my daemon.log but I bet you're right that there was something environment-related that killed it (maybe a MaxRequestWorkers hit, although Apache2Buddy seems to show normal across the board). Your solution sounds good. Thanks again Synchro.