drupal 7サイトがzend phpを使用するRedhat共有ホスティング環境で実行されています。コンテンツタイプおよび最大300MBのさまざまなファイルタイプを受け入れるWebフォームでのファイルアップロードに問題があります。 php.iniファイルを介してサーバーのphpアップロード制限を変更し、phpinfo()
とdrupalステータスレポートpost post_max_size
およびupload_max_filesize
。サイトがubuntu開発マシンとテストサーバーの両方で期待どおりに機能するため、これはサーバー構成エラーであると考えられます。
30〜80 MBの範囲のファイルをコンテンツタイプまたはWebフォームを介してアップロードしようとすると、エラーが発生します。どちらの場合も、ファイルがアップロードされると、リクエストに異常な時間がかかり、次のエラーで失敗します。
An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /file/ajax/field_training_materials/und/form-_TZM0uXFQeo35YReaxuUjeHprp2tr192kNHTucXffSM
StatusText: n/a
ResponseText:
Error
The website encountered an unexpected error. Please try again later.
ReadyState: undefined
アップロードの試行中に、次のJSエラーを受け取りました:"Blocked Script Execution in 'node/722/edit' because the document's frame is sandboxed and the 'allow-scripts' permission is not set"
および"Blocked form submission to '/node/722/edit' because the form's frame is sandboxed and the 'allow-forms' permission is not set
。これらのエラーをグーグルしても、有用な情報は得られませんでした。
私が言うことができることから、ファイルは58 MBの57にほぼ完全にアップロードされ、コンテンツタイプに添付されずに正しいディレクトリに配置されます。主にオーディオファイルに問題があるようですが、ブレークポイントのパターンをテストするためのさまざまなサイズのさまざまなファイルタイプはありません。
問題を調査したところ、一部の人がSuhosin PHP拡張機能でPHP設定に制限を加えているため、拡張機能に問題があるため、ライブサーバーにSuhosinが実行されています。Suhosinの問題を読んで、max_input_varsの値を増やしてみましたが、エラーが次のように変わりました。
An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (300 MB) that this server supports.
Phpinfo()を実行すると、すべてのphp値の設定が適用されていることがわかりますが、効果がないのではないかと思います。最初のエラー以降、エラーは静かに失敗しており、ログに意味のあるものは何も記録されていません。また、すべてのphp ini_setステートメントが.htaccess、settings.php、php.iniファイル間で一貫していることも確認しました。
ファイルのアップロードを試行したときに、テクニカルサポートと話し合ったところ、次のエラーがスローされました:[Thu Feb 02 07:29:10.729972 2017] [core:error] [pid 475229] [client 178.203.233.17:6690] Script timed out before returning headers: index.php, referer:path to my content edit page
。番犬のログにも意味がありません。
コンテンツタイプとWebフォームでのファイルアップロード試行の唯一の違いは、ajaxエラーのパスが異なり、コンソールに次のJSエラーが表示されることです:Error: Syntax error, unrecognized expression: .error, #overlay-context=form/training-suggestions-
したがって、この時点で私が確信している唯一のことは、サーバー構成エラーである必要があるということです。私の疑いは、どういうわけかphpの値の設定が適用されていますが、おそらくある段階で上書きされることです。これを解決または診断する方法に関するアドバイスがあれば、大歓迎です。
更新:したがって、これをもう一度試すと、mysql dbが消えたという別のajaxエラーが発生しました。
An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /file/ajax/field_training_materials/und/form-66R_kY340Ob1IV3M9bRKvHevXAdePEElDr6cgwVf_DE
StatusText: n/a
ResponseText: Additional uncaught exception thrown while handling exception.OriginalPDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT nt.*
FROM
{node_type} nt
WHERE (disabled = :db_condition_placeholder_0)
ORDER BY nt.type ASC; Array
(
[:db_condition_placeholder_0] => 0
)
in _node_types_build() (line 739 of /home/phislub9/public_html/modules/node/node.module).AdditionalPDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT 1 AS expression
FROM
{variable} variable
WHERE ( (name = :db_condition_placeholder_0) ); Array
(
[:db_condition_placeholder_0] => drupal_css_cache_files
)
in variable_set() (line 1240 of /home/phislub9/public_html/includes/bootstrap.inc).Uncaught exception thrown in session handler.PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT 1 AS expression
FROM
{sessions} sessions
WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ); Array
(
[:db_condition_placeholder_0] => 1A5hUf8pjc2OA0iW8Nlom8qeFgG8rJPPKXwxBKKANBI
[:db_condition_placeholder_1] =>
)
in _drupal_session_write() (line 209 of /home/phislub9/public_html/includes/session.inc).
ReadyState: undefined
pdate:ですから、以下の最初の回答に応えて、私はいくつかのことを行ってきました。これは、mysqlシェルでのSHOW VARIABLES;
の結果ですmax_allowed_packet | 268435456
pdate2:これが出力です
mysql> show global status like 'com_kill';
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 3204869
Current database: *** NONE ***
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Com_kill | 0 |
+---------------+-------+
1 row in set (0.01 sec)
pdate:ホスティングテクニカルサポートで確認しました。Webサイトファイルのディスク使用量は明らかに無制限ですが、サーバーは/ homeフォルダーが94%であると報告しています。これは、以前のサイトのメンテナ/開発者からのサーバーの大きなZipファイルが原因でした。これらのファイルをバックアップして削除しましたが、ファイルのアップロードの問題や、ホームフォルダーのサイズに関するサーバーのレポートには影響しません。私が技術サポートから得た他の唯一のことは、サーバーのphp値をオーバーライドできないか、特定の上限を超えて設定できないことですが、サポートエージェントは私に決定的な答えを与えることができませんでしたそれらの値は。私は何が起こっているのかについてより良い答えを得るためにサポートチケットをフォローアップしました。
したがって、Wim Mostreyの回答は適切であり、通常のホスティング環境での問題を解決するはずでした。この問題は、共有ホスト上のApacheのmodsecurity設定と、共有ホスト上のユーザーごとのPHPのメモリ割り当てとの競合に起因し、許容されるMySQL待機タイムアウト設定よりも長くかかりました。約かかった。 phpスクリプトがファイルをディスクに書き込むのに70秒かかり、Mysqlの待機タイムアウトはわずか30秒でした。警告を発している他のいくつかの問題に対処するまで、何が起こっているのかを明確に確認することはできませんでした。最後に、サーバーのmodsecurityを無効にして Mysql待機タイムアウトモジュール を構成することで問題に対処しました。これが誰かを助けることを願っています。
元の答え
2番目の新しいエラーにこれを試してください。
General error: 2006 MySQL server has gone away
これを修正するには、次の2つの方法があります。
my.ini
my.ini
ファイルを見つけて、 max_allowed_packet を見つけます。デフォルトでは1Mです。それを16Mに設定し、MySQLサーバーを再起動します。問題が解決しない場合は、512Mに設定して、MySQLサーバーを再起動してください。
MySQL Prompt
MySQLプロンプトを入力し、ユーザーrootまたは [〜#〜] super [〜#〜] 特権を持つユーザーとしてログインします。次のコマンドを実行します。
SET GLOBAL max_allowed_packet = 1024 * 1024 * 512;
この方法では、サーバーを再起動する必要はありません。
更新
これはあなたの問題を解決していないようですので、SQLステートメントが強制終了された可能性があります。一部のシステムは、実行時間が長すぎるSQLステートメントを積極的に強制終了します。これがプロアクティブに発生しているかどうかは、実行されたKILLステートメントの数を調べることで簡単に確認できます。
次のMySQLコマンドは何を返しますか?
show global status like 'com_kill';