Тотальная неудачница и убийца жёстких дисков.
#post-id: 6128-04-15
#original-date: 6.05.2017 Sat
#original-time: 4:15 AM
#original-day: 6128
#original-host: WinXP Home SP3 (Build 2600)
Сегодня писала скриптик на Руби, который при обращении к определённому URL на сайте отправляет на почту уведомление. Что-то типа «Выйди в Жаббер» на время отпусков.
Неожиданно столкнулась с проблемой: письмо через Яндекс уходило несколько минут. Сначала думала, что тормозит скрипт или ещё что, но потом написала версию скрипта с простой отправкой и запустила напрямую. Тормоза были явные.
Билась полдня, но причину найти не могла. Дома-то всё отлично, а на сервере тот же код тормозит. Более того, вот тут у меня тормоза, а вот тут через sSMTP (уведомления через крон) всё прекрасно уходит через тот же Яндекс, хоть и через другую учётку.
И тут память вдруг вернулась ко мне. Вроде бы у меня уже была такая проблема как раз с sSMTP, я даже в логи добавила вывод «date» для отладки, но так и не убрала. Сначала загоревала, что не оставила заметок по решению проблемы, но очень быстро вспомнила, что дело было с IPv6, через который случались тормоза, тогда как через IPv4 всё было норм. И правда, дома у меня только IPv4, а на сервере и то, и то.
Глянула в скрипт, который вызывает sSMTP, а там «sendmail» вызывается с ключиком «-4». Круто!
А как быть в Руби? В Руби ключа нет. Сначала думала писать костыль, который сам будет разрешать имя хоста SMTP сервера, выбирая IPv4 варианты. Но вот только что зашла на проблему во второй раз и нашла костыль поинтереснее.
You can configure Ubuntu to prefer IPv4 over IPv6. This way you will be able to send emails and access IPv6-only sites. Edit /etc/gai.conf and uncomment the following line:
precedence ::ffff:0:0/96 100
http://stackoverflow.com/questions/16040158/rails-mailer-netopentimeout-execution-expired-exception-on-production-serve/29939735#29939735
Действительно, в указанном конфиге даже комментарий был, поясняющий, что нужно раскомментировать, чтобы задать приоритет IPv4 перед IPv6 без отключения самого IPv6. Даже перезагрузка не потребовалась.
Хотя, решение довольно сомнительное, но пока так.
#original-date: 6.05.2017 Sat
#original-time: 4:15 AM
#original-day: 6128
#original-host: WinXP Home SP3 (Build 2600)
Сегодня писала скриптик на Руби, который при обращении к определённому URL на сайте отправляет на почту уведомление. Что-то типа «Выйди в Жаббер» на время отпусков.
Неожиданно столкнулась с проблемой: письмо через Яндекс уходило несколько минут. Сначала думала, что тормозит скрипт или ещё что, но потом написала версию скрипта с простой отправкой и запустила напрямую. Тормоза были явные.
Билась полдня, но причину найти не могла. Дома-то всё отлично, а на сервере тот же код тормозит. Более того, вот тут у меня тормоза, а вот тут через sSMTP (уведомления через крон) всё прекрасно уходит через тот же Яндекс, хоть и через другую учётку.
И тут память вдруг вернулась ко мне. Вроде бы у меня уже была такая проблема как раз с sSMTP, я даже в логи добавила вывод «date» для отладки, но так и не убрала. Сначала загоревала, что не оставила заметок по решению проблемы, но очень быстро вспомнила, что дело было с IPv6, через который случались тормоза, тогда как через IPv4 всё было норм. И правда, дома у меня только IPv4, а на сервере и то, и то.
Глянула в скрипт, который вызывает sSMTP, а там «sendmail» вызывается с ключиком «-4». Круто!
А как быть в Руби? В Руби ключа нет. Сначала думала писать костыль, который сам будет разрешать имя хоста SMTP сервера, выбирая IPv4 варианты. Но вот только что зашла на проблему во второй раз и нашла костыль поинтереснее.
You can configure Ubuntu to prefer IPv4 over IPv6. This way you will be able to send emails and access IPv6-only sites. Edit /etc/gai.conf and uncomment the following line:
precedence ::ffff:0:0/96 100
http://stackoverflow.com/questions/16040158/rails-mailer-netopentimeout-execution-expired-exception-on-production-serve/29939735#29939735
Действительно, в указанном конфиге даже комментарий был, поясняющий, что нужно раскомментировать, чтобы задать приоритет IPv4 перед IPv6 без отключения самого IPv6. Даже перезагрузка не потребовалась.
Хотя, решение довольно сомнительное, но пока так.