Fetch сервер сообщает об ошибке err internal server error

I am trying to handle 500 internal server errors inside fetch. If an internal error occurs, the server responds with a message. I want to extract that message.

const req = new Request(url, {
      method: node.method,
      mode: 'cors',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(body),
    });
    fetch(req)
      .then((response) => {
        if (response.status === 500) {
          // res.json extracts the body from the response as a promise, chain
          // .then on it and throw an error to be caught in the lower catch.
          response.json()
          .then((json) => {
            const { message, stackTrace } = json;
            throw new ServerException(message, stackTrace); // note 1
          })
          .catch((error) => {
            return Promise.reject(RawException(error)); // note 2
          });
        } else {
          return response.json();
        }
      })
      .then((json) => { // note 3
        dispatch(stopLoading());
        dispatch(recieveResponse(typeOfRequest, json));
      })
      .catch((e) => {
        dispatch(stopLoading());
        dispatch(responseError());
        dispatch(showError(e.message));
      });
  };

My issue is that extracting the body of the response creates a new promise, and I am unable to reject the outer promise from the inner one.

Note 1 triggers the catch method of the inner promise. Inside catch, I have tried throwing another error but it doesn’t seem to work. If I throw new RawException(error) on the second noted line, nothing happens and the then method on the third noted line triggers. If I return a rejected promise as I have in the code provided, then still triggers but json is undefined.

How do I do this?

Describe the bug
I’ve followed the procedure to use swag with a gin application. I’ve also checked the example implementation from the source. But, unfortunately facing the error. I’m attaching 2 screenshots of the problem.

To Reproduce
Steps to reproduce the behavior:

1. go get -u github.com/swaggo/swag/cmd/swag
2. Follow the steps to use it with gin application.
3. After doing swag init, I faced a problem like swag not found on a mac. So I did export PATH=$PATH:$HOME/go/bin which fixed the error and generated required files in ./docs dir.
4. After running the application, I used http://localhost:8888/swagger/index.html as url and getting this error.

Expected behavior
I wanted to display the API docs.

Screenshots

Your swag version
1.6.5

Your go version
1.12.0

Desktop (please complete the following information):

• OS: MacOS Calatila 10.15.3
• Browser: [Safari, Chrome]
• Version: [13.0.5, 80.0.3987.163]

Additional context
I’ve tried several times to find out the issue but seems not yet registered swag swag is not registered.

Достаточно часто владельцы хостингов мучаются из-за постоянного возникновения сообщения об ошибке 500 (Internal Server Error). Она, как это называется, многим попросту отравляет жизнь. Сейчас мы попробуем кратко разобраться в сути самой ситуации и посмотрим, как же можно избавиться от появления ошибки в будущем.

Итак, начнем, пожалуй, с самого значения этого словосочетания. В системе (каталоге) ошибок Windows (и не только) есть ошибка под номером 500, отвечающая компьютерному термину Internal Server Error. Перевод этого словосочетания означает внутреннюю ошибку сервера, связанную со статусом протокола HTTP.

По сути, ошибка означает, что программное обеспечение сервера либо не работает, либо работает, но один или несколько его компонентов дают сбои в виде отказа на клиентские запросы, например, поисковой системы или интернет-браузера.

Причины возникновения ошибки

Говоря об ошибке Internal Server Error в самом широком понимании, стоит учитывать, что возникать она может на множестве сайтов или ресурсов, написанных с помощью совершенно разных CMS. Тут, кстати, нужно разграничить причины ее возникновения.

Очень часто такая ситуация может наблюдаться на сайтах типа WordPress, OpenCart, Joomla и др. Если же структуры управления, подобные WordPress, при построении сайта не используются, возможно, причина кроется в том, что на самом хостинге возникают сбои при подключении неправильных PHP-расширений, или сайт после запроса возвращает некорректные HTTP-заголовки, которые не могут быть распознаны вашим сервером.

Не менее распространенной причиной возникновения ошибки Internal Server Error можно назвать отсутствие корректных прав доступа. Так, например, если на PHP файлы скриптов, которые размещены на хостинге, имеют права доступа 777, очень может быть, что их исполнение попросту блокируется сервером, вследствие чего и выдается сообщение об ошибке.

Также одной из причин может быть достаточно долгая работа скриптов. Дело в том, что PHP-ограничения по времени исполнения действуют не только в отношении хостинга, подобные лимиты могут выставляться и со стороны сервера. Иными словами, это несколько напоминает тайм-аут операции. Когда сервер в течение определенного времени не получает ответа на запрос, он попросту блокирует исполнение скрипта.

В некоторых случаях ошибка Internal Server Error может появляться, когда на хостинге наблюдается превышение лимита используемой памяти. Попросту говоря, скрипт для исполнения требует больше положенного, а ведь такой лимит устанавливается не только на PHP, зачастую действуют ограничения по потреблению ресурсов всеми исполняемыми скриптами.

Наконец, одна из самых распространенных ситуаций возникновения ошибки Internal Server Error – это содержание некорректных директив в файле .htaccess (кстати, при работе с движком WordPress это проявляется наиболее часто). Вот теперь мы вплотную подошли к поиску решения для каждой конкретной ситуации.

Ошибка Internal Server Error: как исправить простейшими способами

Для начала посмотрим, что можно сделать при обнаружении неправильных прав доступа. В данном случае права доступа 777 позволяют редактировать содержимое абсолютно всем, что, несомненно, сказывается на безопасности. В такой ситуации необходимо их изменить, применив к папкам значение 755, к файлам скриптов – 600, а ко всем стальным файлам данных – 644.

При слишком долгой работе исполняемого скрипта можно попробовать увеличить время ожидания, правда, тут есть одна загвоздка. Такое решение может сработать на выделенном сервере или VPS (Virtual Private Server), а в случае виртуального хостинга никакого эффекта не будет.

Что касается завышенного потребления памяти в сравнении с ограничениями, действующими на хостинге, тут можно посоветовать только обратиться в службу поддержки или же попросту сменить самого хостинг-провайдера, у которого ограничения будут не такими жесткими.

Теперь несколько слов о файле .htaccess. Дело в том, что он предполагает использование очень строгого синтаксиса, если при проведении настроек были допущены ошибки или некоторые неточности, избежать появления ошибки Internal Server Error не удастся. Тут нужно поступить следующим образом. Для начала нужно проверить наличие самого файла в корневой директории сайта, после чего, сделав его резервную копию, удалить целиком и полностью. Если после такой процедуры сайт снова станет работоспособным, значит проблема именно в файле .htaccess, который придется проверить на наличие ошибок в синтаксисе.

Проблемы с движком WordPress

С WordPress дело обстоит хуже. Дело в том, что этот движок способен перезаписывать оригинальный файл .htaccess, отвечающий за управление доступом к файлам и папкам хостинга, а ведь оригинальный файл должен создаваться всего один раз, и тем более не в WordPress!

Самым простым способом исправления такой ситуации является отключение темы WordPress и использование вместо нее любой другой. Если ошибка исчезла, дело именно в самой теме, если нет – нужно поэтапно отключать плагины WordPress и проверять, какой из них влияет на работоспособность.

В некоторых случаях может потребоваться обновить WordPress до последней версии и отключить функцию перезаписи файла. Для начала скачиваем на компьютерный терминал оригинальный файл .htaccess, затем входим на сайте в папку по пути /wp-admin/includes/ с последующей загрузкой файла misc.php, который необходимо открыть, скажем, в стандартном «Блокноте» (или любом другом текстовом редакторе) и найти строку функции «function save_mod_rewrite_rules». Теперь в самой функции переходим к строке «return insert_with_markers( $htaccess_file, ‘WordPress’, $rules );» и заменяем ее на «return true;» (естественно, все команды прописываются без кавычек). Остается только сохранить изменения и загрузить новый файл на хостинг с заменой старого файла misc.php.

Недостатком такого метода является только то, что в данном случае отключается обновление WordPress. При подключении плагинов они работать, естественно, не будут.

Заключение

В принципе, это, так сказать, наиболее распространенные причины появления ошибки и методы ее устранения. На самом деле, что причин, что способов борьбы с такими ситуациями может быть очень много, так что, придется анализировать ситуацию в каждом конкретном случае, а только потом выбирать, какую именно методику для исправления ошибки использовать.

Разработчики и люди, профессионально работающие с веб-приложениями, боятся 500 Internal Server Error . Оптимальный способ её устранения зависит от сервера и того, что на нём запущено. В данной статье приводятся советы по диагностике и исправлению ошибки 500 .

Диагностика ошибки 500 Internal Server Error

Важно помнить, что эта ошибка происходит на стороне сервера. Это значит, что HTML-код , выполняемый на стороне клиента, а также JavaScript или любые другие запущенные в браузере объекты, не могут быть источником ошибки 500 Internal Server Error . Само название ( Internal Server Error – ‘внутренняя ошибка сервера’ ) говорит о том, что ошибка происходит на сервере.

Устранение ошибки на популярных платформах

Многие пользователи устанавливают на свой сервер популярные CMS-системы , такие как WordPress , Joomla , Drupal и они не должны вызывать ошибку 500 , если всё настроено правильно. Однако она всё равно всплывает – из-за несовместимости версий, некачественных установок или сбоя прав доступа на сервере.

Вот некоторые распространённые проблемы, которые могут вызывать подобную ошибку в часто используемых CMS :

• Если вы только что обновили движок до новой версии, вероятно, обновление прошло с ошибками и необходимо провести его повторно. Скорее всего, на сайте разработчика есть инструкции, как это правильно сделать.
• Если вы только что активировали новый плагин или новую тему, стоит попробовать отменить эти изменения. Даже профессионально написанные плагины могут конфликтовать с другими и вызывать 500 Internal Server Error nginx
• Если вы обновляли CMS , старые плагины и темы могут быть с ней несовместимы. Единственное, что можно сделать в таком случае — отключать их по очереди, пока ошибка 500 не исчезнет.
• Неправильно заданные права доступа на сервере или ошибки в файле .htaccess . Серверу не удаётся получить доступ к скриптам, файлам и другим ресурсам, поэтому он выдаёт ошибку.

Когда причиной ошибки 500 Internal Server Error являются скрипты и плагины, лучше всего искать ответы на сайтах их разработчиков.

Устранение ошибки на стороне серверных скриптов

Другой причиной ошибки 500 Internal Server Error может стать разработка и тестирование собственных скриптов.

Чтобы справиться с такой ошибкой, попробуйте следующие решения :

• Настройка прав на сервере : часто неверная настройка прав доступа к файлу или папке приводит к тому, что сервер выдаёт ошибку 500 Internal Server Error . Из-за того, что ему не удаётся запустить скрипт. Выясните, какие права должны быть настроены, и выставьте их соответствующим образом.
• Превышено время ожидания : возможно, истекло время ожидания ответа от PHP или другого серверного скрипта. Это происходит из-за того, что недоступен определённый ресурс или коде была допущена ошибка, запускающая бесконечный цикл.
• Превышено время ожидания соединения с сервером: если сервер был занят, перезагружался или потерял соединение, скрипт может выдать ошибку 500 Internal Server Error . Возможно, в следующий раз ошибки не будет. Но если ошибка появляется при тестировании, велика вероятность того, что она встретится и пользователям.
• Ошибки в файле .htaccess: в некоторых случаях ошибку 500 может вызывать код, прописанный в файле .htaccess .
• Ошибки в скрипте: если ошибку выдаёт скрипт, можете запросить у него подробную информацию об ошибке. К примеру, в PHP можно включить вывод ошибок на экран или в лог-файл, добавив директиву display_errors . По умолчанию среда выполнения может скрывать ошибки, но это не очень удобно для отладки программы.

Попросите помощи у системного администратора

В некоторых случаях у разработчиков нет полного контроля над сервером.

Если скрипт запускается на сервере сторонней организации, она может помочь вам в следующем :

• Предоставить документацию о своём сервере и возможных причинах ошибки 500 . В зависимости от используемой операционной системы и настройки оборудования, данная ошибка может возникать по разным причинам.
• Попросите службу поддержки хостинга посмотреть лог-файлы с ошибками — системный администратор сможет определить, был ли сервер во время возникновения ошибки загружен или вовсе « упал ».

Ошибку 500 Internal Server Error довольно легко устранить

500 Internal Server Error — как исправить ? В большинстве случаев причины возникновения ошибки 500 легко исправляются. Проблема заключается в том, что без конкретной информации определение причины возникновения сбоя усложняется. Легче всего справиться с ошибкой, когда разработчик выяснит, что изменилось перед возникновением ошибки.

Не забывайте, что произошедшие изменения могли быть осуществлены и другими людьми — например, администратором сервера. Если же ничего не менялось, вероятно, сам сервер стал причиной возникновения ошибки из-за несовместимости программного обеспечения или проблем с производительностью.

Данная публикация представляет собой перевод статьи « 500 Internal Server Error: What It Is And How To Fix It » , подготовленной дружной командой проекта Интернет-технологии.ру

В статье я опишу, что это за ошибка 500 Internal Server Error и как её исправить. После того, как я столкнулся с ней я понял, что это внутренняя ошибка сервера, которая может появляться по причине целого ряда неполадок на сайте. Появляющееся окно может быть разным по форме и описанию, это зависит от сервера, однако суть остается одной для всех. Если вы столкнулись с ошибкой 500 попробуйте зайти через некоторое время, возможно проблему уже решают. Если проблема остается длительное время, значит необходимо действовать самому.

Скриншот ошибки 500 Internal Server Error

Что это за проблема 500 Internal Server Error в WordPress?

Данная ошибка – это не сбои в CMS, а появляется 500 Internal Server Error обычно в процессе неправильной работы скриптов на сервере. Обычно, текст ошибки ничего конкретного нам не говорит, мы лишь знаем, что неполадки происходят на стороне сервера. Понятно, что эта ошибка может возникать в WordPress из-за шаблона или функции плагина.

Проверка целостности файла .htaccess в WordPress

Чтобы выполнить проверку, необходимо файл .htaccess переименовать, например, в .htaccess_fix. Для этого вы должны будете зайти на ваш сайт с помощью FTP. После этого найдите этот файл в корне сайта, он будет возле директорий wp-admin, wp-content.

Когда вы выполнили переименование, снова попробуйте загрузить сайт, чтобы убедиться, что ошибка исчезла. Теперь убедитесь, что вы сохранили изменения в пункте «Постоянные ссылки», это позволит сгенерировать новый .htaccess файл с корректными правилами перезаписи ссылок.

Файл .htaccess

Увеличиваем память PHP

Ошибка 500 Internal Server Error может возникать по причине переполненной памяти PHP, которая выделяется для пользователя. Для этого следуйте несложным пунктам:

1. Создайте новый тестовый документ с названием php.ini.
2. Напишите в нем код – memory=64MB.
3. Сохраните его.
4. «Залейте» его в папку /wp-admin/, по ФТП.

Проблема, связанная с ошибкой 500 Internal Server Error, кроется в плагинах WordPress

Если методы, описанные выше вам не помогли, вероятно причиной появления ошибки 500 Internal Server Error является один из установленных плагинов. Для того, чтобы в этом убедиться, придется отключить их все. Если проблема решилась таким способом, значит виновен один из плагинов, а какой именно, нужно будет установить, включая их по очереди.

Окно с настройкой плагинов

При входе в админ-панель Joomla появляется ошибка 500 Internal Server Error

Эту ошибку пользователи CMS Joomla могут наблюдать после того, как ввели логин и пароль при входе, но при этом сайт работает для пользователей. К сожалению, ошибка Internal Server Error с кодом 500 не указывает на причины ее появления, поэтому придется искать ее самостоятельно.

Найти причину можно с помощью журнала ошибок, который хранится на сервере. Открыв файл «error.php», который находится в директории «logs», можно обнаружить нарушения в работе модулей, которые здесь сохранились.

Еще одной причиной может быть невозможность делать запись в каталогах «tmp» и «logs». Возможно, нужно будет установить права в настройках для этих каталогов. Проверьте правильность путей к этим каталогам «tmp» и «logs» в файле, который отвечает за их конфигурацию – «configuration.php». Рекомендуется указать верные пути для них вручную.

Если проблема не иссякла, проверьте правильность файла «htaccess» и произведите те же действия для него, что и с подобным файлом для системы управления сайтом WordPress. В этом файле могут быть опечатки либо лишняя информация, которая вызывает ошибку. При работе с файлом «htaccess» можно не удалять сомнительные строки, а закомментировать их и проверять, изменяется ли после этого работа сайта. Также произведите отключение всех плагинов, чтобы убедиться в том, что причина не в них.

Другие причины появления ошибки 500 Internal Server Error

Ошибка 500 может появляться из-за конфликтов в работе с CGI-скриптами. Для этого существует 3 правила, которые могут быть не соблюдены:

• Каждая строка должна заканчиваться в формате UNIX (n), но не Windows (rn). Чтобы выдержать это правило, необходимо загрузку производить по протоколу FTP, с режимом ASCll.
• В процессе работы CGI-скрипта могут появляться HTTP-заголовки с неверными ответами. Нужно пересмотреть содержимое системного файла «error log» на наличие ошибок.
• Цифровое значение для скриптов CGI, файлов и папок должно быть установлено в 0755. Эта запись дает право совершать настройки исключительно владельцу сайта, что является дополнительной мерой безопасности.

Причина ошибки 500 – неверно настроены права доступа

При помощи FTP-клиента (годен для этого FileZilla) нужно проверить права доступа к папкам и файлам на сервере. Сначала необходимо проверить, соответствуют ли настройки корректной работе на сервере. Проверьте настройки для каждого типа отдельно. Они должны соответствовать следующим значениям:

• Значение для скриптов – 600.
• Для файлов – 644.
• Значение для папок – 755.

Настройка прав доступа

Для того, чтобы избежать различных ошибок (500 Internal Server Error) и обеспечить дополнительную безопасность – управлять глобальными настройками должен один человек – администратор. Не давайте кому-либо прав доступа к корневым папкам.

• Проблемы с почтой

  Здравствуйте.

  Ось — Centos 6

  Почтовый сервер (POP3 и IMAP) dovecot-2.0.9-2.el6_1.1 — стоит/включен
  Почтовый сервер (SMTP) postfix-2.6.6-2.2.el6_1 — стоит/включен

  Всё ставилось из панели.

  Почта отправляется, при попытке получения ругается:

  06.02.2012, 21:19:46: FETCH — Соединение с POP3 сервером прошло удачно
  !06.02.2012, 21:19:46: FETCH — Сервер сообщает об ошибке: -ERR [IN-USE] Couldn’t open INBOX: Internal error occurred. Refer to server log for more information. [2012-02-06 14:17:07]

  В логах ничего не нашел. Не сталкивались где копать?

  Панель ISPmanager 4.3 Lite

  Спасибо.

• Снес Centos 6, вернулся на 5.5
  Up.

  Проблема не решена. Перекопал кучу мануалов, но так и не понял в чем дело. Вроде всё стоит, всё работает. А почта не ходит (входящая), SMTP отправляет.
  Раньше всё нормально ставилось на этот сервер.

• Возникла такая же проблема после миграции на другой WPS
  сразу увидел что права на папку cur в проблемном ящике отличались от остальных были 700 поменял на 755
  но проблема не решилась. куда копать

• Вы написали в очень старую тему 2012 года. Попробуйте заново описать проблему — какое у вас окружение, что происходит

• после переноса панели и миграции всех пользователей с одного VPS на другой
  при получении почты Батом

  ругается:
  FETCH — Соединение с POP3 сервером прошло удачно
  FETCH — Сервер сообщает об ошибке: -ERR [IN-USE] Couldn’t open INBOX: Internal error occurred. Refer to server log for more information.

  отправка проходит спокойно.
  на остальных ящиках письма приходят

  Почтовый сервер (POP3 и IMAP) dovecot — стоит/включен
  Почтовый сервер (SMTP) postfix — стоит/включен

  В логах ничего не нашел. Не сталкивались где копать?

  Панель ISPmanager-Pro 4.4.10.26

• В /var/log/maillog что-то пишет при подключении?

• хотя повторил получение почты и вот что в логе

  Sep 11 20:05:37 big postfix/local[1907]: D3D364AA6C5: to=<virtuser_705@big.tugrin.ru>, orig_to=<dir@ostankino32.ru>, relay=local, delay=86230, delays=86230/0.19/0/0.06, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big maildrop[1936]: Home directory owned by wrong user.
  Sep 11 20:05:37 big postfix/local[1905]: EC4694AA6E9: to=<virtuser_718@big.tugrin.ru>, orig_to=<logist@ostankino32.ru>, relay=local, delay=39464, delays=39464/0.21/0/0.04, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big postfix/local[1903]: 15B4B4AA696: to=<virtuser_718@big.tugrin.ru>, orig_to=<logist@ostankino32.ru>, relay=local, delay=101352, delays=101352/0.19/0/0.04, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big maildrop[1939]: Home directory owned by wrong user.
  Sep 11 20:05:37 big maildrop[1940]: Home directory owned by wrong user.
  Sep 11 20:05:37 big postfix/local[1907]: 23B634AA6AE: to=<virtuser_718@big.tugrin.ru>, orig_to=<logist@ostankino32.ru>, relay=local, delay=107988, delays=107988/0.09/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big postfix/local[1908]: 4CF0C4AA6E6: to=<virtuser_705@big.tugrin.ru>, orig_to=<dir@ostankino32.ru>, relay=local, delay=33812, delays=33812/0.2/0/0.1, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big postfix/local[1903]: F1B524AA6FC: to=<virtuser_718@big.tugrin.ru>, orig_to=<logist@ostankino32.ru>, relay=local, delay=38111, delays=38110/0.08/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big maildrop[1941]: Home directory owned by wrong user.
  Sep 11 20:05:37 big maildrop[1942]: Home directory owned by wrong user.
  Sep 11 20:05:37 big maildrop[1943]: Home directory owned by wrong user.
  Sep 11 20:05:37 big postfix/local[1908]: 642F94AA63E: to=<virtuser_718@big.tugrin.ru>, orig_to=<logist@ostankino32.ru>, relay=local, delay=113367, delays=113367/0.06/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big postfix/local[1911]: 5CCC54AA6F7: to=<virtuser_705@big.tugrin.ru>, orig_to=<dir@ostankino32.ru>, relay=local, delay=38718, delays=38718/0.24/0/0.06, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big postfix/local[1903]: 93CB54AA708: to=<virtuser_718@big.tugrin.ru>, orig_to=<logist@ostankino32.ru>, relay=local, delay=32427, delays=32427/0.08/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big maildrop[1944]: Home directory owned by wrong user.
  Sep 11 20:05:37 big maildrop[1945]: Home directory owned by wrong user.
  Sep 11 20:05:37 big postfix/local[1907]: 8421B4AA6F0: to=<virtuser_705@big.tugrin.ru>, orig_to=<dir@ostankino32.ru>, relay=local, delay=38906, delays=38906/0.11/0/0.01, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big postfix/local[1905]: E0C114AA706: to=<virtuser_705@big.tugrin.ru>, orig_to=<dir@ostankino32.ru>, relay=local, delay=33306, delays=33305/0.27/0/0.03, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big maildrop[1947]: Home directory owned by wrong user.
  Sep 11 20:05:37 big maildrop[1946]: Home directory owned by wrong user.
  Sep 11 20:05:37 big postfix/local[1908]: 674294AA69E: to=<virtuser_718@big.tugrin.ru>, orig_to=<logist@ostankino32.ru>, relay=local, delay=104384, delays=104384/0.07/0/0.03, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big postfix/local[1907]: 3C3034AA6A4: to=<virtuser_705@big.tugrin.ru>, orig_to=<dir@ostankino32.ru>, relay=local, delay=96125, delays=96125/0.11/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big maildrop[1948]: Home directory owned by wrong user.
  Sep 11 20:05:37 big postfix/local[1911]: 0DD034AA703: to=<virtuser_705@big.tugrin.ru>, orig_to=<dir@ostankino32.ru>, relay=local, delay=36231, delays=36231/0.12/0/0.03, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big maildrop[1949]: Home directory owned by wrong user.
  Sep 11 20:05:37 big postfix/local[1903]: AB0E64AA6FE: to=<virtuser_705@big.tugrin.ru>, orig_to=<dir@ostankino32.ru>, relay=local, delay=37162, delays=37162/0.12/0/0.04, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big postfix/local[1907]: 625DE4AA670: to=<virtuser_705@big.tugrin.ru>, orig_to=<dir@ostankino32.ru>, relay=local, delay=85120, delays=85120/0.13/0/0.04, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Home directory owned by wrong user. )
  Sep 11 20:05:37 big postfix/smtp[1930]: connect to mail.entelchile.net[164.77.62.8]:25: Connection refused

• Home directory owned by wrong user — думаю, что нужно проверить владельца директории почтового ящика

• сменил на юзера, под которым делались все ящики изначально.(как вписать владельцем virtuser_xxx не могу разобраться)
  поставил на директорию права 777. к ящику конектится, но почту не получает пишет 0 новых, хотя письмо в копии на второй ящик приходит спокойно

• Цитата:

  ---

  Сообщение от Lexxbry
  

  сменил на юзера, под которым делались все ящики изначально.(как вписать владельцем virtuser_xxx не могу разобраться)
  поставил на директорию права 777. к ящику конектится, но почту не получает пишет 0 новых, хотя письмо в копии на второй ящик приходит спокойно

  ---

  отправка писем идет без проблем. письма доходят

• В логе то ошибка ушла?

  Если письма на сервере есть, но не видно через почтовый клиент, то нужно разбираться куда они кладутся и оттуда же или нет их потом dovecot читает.

  Это нужно в конфигах посмотреть соответствующих сервисов.

• не могу разобраться с ситуацией.
  подключаюсь к этому же ящику через веб-морд(роундкьюб) письма отправленные до смены пользователя и прав есть.
  пытаюсь отправить сегодня не доходят.
  как владельцем прописать конкретного virtualuser_xxx???

• и кстати на всех ящиках наблюдается такая проблема:
  при установке ящика в БАТ если указываем протокол POP3 то письма принимают(исключение ящик о котором речь выше) если же ставим IMAP то тишина.
  до миграции работало и так и так.

• короче через ssh поменял у этого ящика владельца на virtuser_xxx письма стали приходить.
  осталась одна проблема почему при IMAP не приходят

• всем спасибо за наводки.
  проблема решена.

• http://s8.postimg.org/syvafoxv9/Scre…t_16_34_17.png

  При входе в RoundCube вот такое вылезает. Что делать?

  ISPManager Business 5.31.1

• Спасибо. Поправил php.ini — проблема решилась.

Достаточно часто владельцы хостингов мучаются из-за постоянного возникновения сообщения об ошибке 500 (Internal Server Error). Она, как это называется, многим попросту отравляет жизнь. Сейчас мы попробуем кратко разобраться в сути самой ситуации и посмотрим, как же можно избавиться от появления ошибки в будущем.

Ошибка Internal Server Error: что это?

Итак, начнем, пожалуй, с самого значения этого словосочетания. В системе (каталоге) ошибок Windows (и не только) есть ошибка под номером 500, отвечающая компьютерному термину Internal Server Error. Перевод этого словосочетания означает внутреннюю ошибку сервера, связанную со статусом протокола HTTP.

По сути, ошибка означает, что программное обеспечение сервера либо не работает, либо работает, но один или несколько его компонентов дают сбои в виде отказа на клиентские запросы, например, поисковой системы или интернет-браузера.

Причины возникновения ошибки

Говоря об ошибке Internal Server Error в самом широком понимании, стоит учитывать, что возникать она может на множестве сайтов или ресурсов, написанных с помощью совершенно разных CMS. Тут, кстати, нужно разграничить причины ее возникновения.

Очень часто такая ситуация может наблюдаться на сайтах типа WordPress, OpenCart, Joomla и др. Если же структуры управления, подобные WordPress, при построении сайта не используются, возможно, причина кроется в том, что на самом хостинге возникают сбои при подключении неправильных PHP-расширений, или сайт после запроса возвращает некорректные HTTP-заголовки, которые не могут быть распознаны вашим сервером.

Не менее распространенной причиной возникновения ошибки Internal Server Error можно назвать отсутствие корректных прав доступа. Так, например, если на PHP файлы скриптов, которые размещены на хостинге, имеют права доступа 777, очень может быть, что их исполнение попросту блокируется сервером, вследствие чего и выдается сообщение об ошибке.

Также одной из причин может быть достаточно долгая работа скриптов. Дело в том, что PHP-ограничения по времени исполнения действуют не только в отношении хостинга, подобные лимиты могут выставляться и со стороны сервера. Иными словами, это несколько напоминает тайм-аут операции. Когда сервер в течение определенного времени не получает ответа на запрос, он попросту блокирует исполнение скрипта.

В некоторых случаях ошибка Internal Server Error может появляться, когда на хостинге наблюдается превышение лимита используемой памяти. Попросту говоря, скрипт для исполнения требует больше положенного, а ведь такой лимит устанавливается не только на PHP, зачастую действуют ограничения по потреблению ресурсов всеми исполняемыми скриптами.

Наконец, одна из самых распространенных ситуаций возникновения ошибки Internal Server Error – это содержание некорректных директив в файле .htaccess (кстати, при работе с движком WordPress это проявляется наиболее часто). Вот теперь мы вплотную подошли к поиску решения для каждой конкретной ситуации.

Ошибка Internal Server Error: как исправить простейшими способами

Для начала посмотрим, что можно сделать при обнаружении неправильных прав доступа. В данном случае права доступа 777 позволяют редактировать содержимое абсолютно всем, что, несомненно, сказывается на безопасности. В такой ситуации необходимо их изменить, применив к папкам значение 755, к файлам скриптов – 600, а ко всем стальным файлам данных – 644.

При слишком долгой работе исполняемого скрипта можно попробовать увеличить время ожидания, правда, тут есть одна загвоздка. Такое решение может сработать на выделенном сервере или VPS (Virtual Private Server), а в случае виртуального хостинга никакого эффекта не будет.

Что касается завышенного потребления памяти в сравнении с ограничениями, действующими на хостинге, тут можно посоветовать только обратиться в службу поддержки или же попросту сменить самого хостинг-провайдера, у которого ограничения будут не такими жесткими.

Теперь несколько слов о файле .htaccess. Дело в том, что он предполагает использование очень строгого синтаксиса, если при проведении настроек были допущены ошибки или некоторые неточности, избежать появления ошибки Internal Server Error не удастся. Тут нужно поступить следующим образом. Для начала нужно проверить наличие самого файла в корневой директории сайта, после чего, сделав его резервную копию, удалить целиком и полностью. Если после такой процедуры сайт снова станет работоспособным, значит проблема именно в файле .htaccess, который придется проверить на наличие ошибок в синтаксисе.

Проблемы с движком WordPress

С WordPress дело обстоит хуже. Дело в том, что этот движок способен перезаписывать оригинальный файл .htaccess, отвечающий за управление доступом к файлам и папкам хостинга, а ведь оригинальный файл должен создаваться всего один раз, и тем более не в WordPress!

Самым простым способом исправления такой ситуации является отключение темы WordPress и использование вместо нее любой другой. Если ошибка исчезла, дело именно в самой теме, если нет – нужно поэтапно отключать плагины WordPress и проверять, какой из них влияет на работоспособность.

В некоторых случаях может потребоваться обновить WordPress до последней версии и отключить функцию перезаписи файла. Для начала скачиваем на компьютерный терминал оригинальный файл .htaccess, затем входим на сайте в папку по пути /wp-admin/includes/ с последующей загрузкой файла misc.php, который необходимо открыть, скажем, в стандартном «Блокноте» (или любом другом текстовом редакторе) и найти строку функции «function save_mod_rewrite_rules». Теперь в самой функции переходим к строке «return insert_with_markers( $htaccess_file, ‘WordPress’, $rules );» и заменяем ее на «return true;» (естественно, все команды прописываются без кавычек). Остается только сохранить изменения и загрузить новый файл на хостинг с заменой старого файла misc.php.

Недостатком такого метода является только то, что в данном случае отключается обновление WordPress. При подключении плагинов они работать, естественно, не будут.

Заключение

В принципе, это, так сказать, наиболее распространенные причины появления ошибки и методы ее устранения. На самом деле, что причин, что способов борьбы с такими ситуациями может быть очень много, так что, придется анализировать ситуацию в каждом конкретном случае, а только потом выбирать, какую именно методику для исправления ошибки использовать.