Q&A
発生する条件で他に分かっていることはありませんか？また、POSTデータの内容をもう少し詳細に教えていただけないでしょうか？max_input_varsを設定したということは、入力変数の数が多いということでしょうか？どの程度でしょうか？
###前提・実現したいこと
FuelPHPにてAndroidアプリと連携するRestAPIプログラムを作成しました。
Androidアプリで通信をしていると、送信されたPOST情報が欠落する場合があります。
POSTデータ量は30000程度で、下記のような内容となります。
sheets[1][details][13][sort]=14& sheets[1][details][9][sort]=10& sheets[4][details][6][info]=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX& sheets[0][sheetExid]=& sheets[4][details][1][inputLength]=30& sheets[1][details][41][checkInfo]=XXXXXXXXXXXXXXXXX& sheets[1][details][20][comment]=& sheets[1][details][52][answer]=Good& sheets[0][details][9][checkInfo]=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX& sheets[1][details][56][checkItems][1][checkItem]=N.A.& sheets[3][details][1][sort]=2& sheets[3][details][5][checkItems][0][checkItem]=Good& sheets[3][details][4][checkItems][2][checkItem]=NG& sheets[1][details][17][inputLength]=30& sheets[1][details][1][checkItems][0][checkItem]=Good& sheets[1][details][46][required]=2& sheets[1][details][26][required]=2& sheets[1][details][10][checkType]=RadioText& sheets[1][details][11][checkItems][1][checkItem]=N.A.& sheets[0][details][0][checkInfo]=XXXXXXXXXXXXXXXXXXXXXXXXXXX& sheets[2][details][20][sheetdetailExid]=123456789& sheets[2][details][29][checkItems][1][checkItem]=N.A.& sheets[2][details][7][checkType]=RadioText& sheets[4][details][4][checkType]=Text& sheets[2][details][19][checkTitle]=&
また、欠落箇所はPOSTデータの後ろ側が欠落していると思われます。
（Androidアプリ側でMap変数にPOST送信情報を設定して送信している為、配列の順番通りに取得出来ません）
但し、サーバ側のerror_log等にそれらしいログは出力されません。
（プログラム上で必須項目が欠落しているエラーになる為、問題が発見されました。
尚、該当の必須項目はAndroidアプリから必ず送信しています）
サーバ側でTCPDUMPにてパケットを覗いてみましたが、
そのタイミングではPOSTデータは欠落していませんでした。
ApacheやPHPの設定が怪しいと睨んで、
PHPのバージョンが5.3.3の為、関係はないと思いますが
max_input_varsの設定が無いためかと疑い、
PHP.iniに下記を記載しましたが、相変わらずPOSTデータが欠落してしまいます。
max_input_vars = 90000
その他、タイムアウトやメモリまわりの設定を確認してみたのですが、
それらがエラーとなった場合はWebサーバ上で500エラーとなるため、
それらの設定に問題はなさそうです。
現在の設定は下記となります。
max_execution_time = 30 max_input_time = 60 post_max_size = 256M memory_limit = 512M
本問題が発生して8ヶ月以上経つのですが、原因の特定と不具合修正ができず、質問させて頂きました。
ヒント等ありませんか。
###補足情報(言語/FW/ツール等のバージョンなど)
サーバ環境
linux centOS6.4
Apache2.2.15
PHP5.3.3
FuelPHP(1.7.0)
PHP導入パッケージ
ImageMagick 6.4.9-10
Ghostscript 9.05
ffmpeg
php-mcrypt
Androidアプリは中国にて利用し、サーバは日本国内にあります。
また利用しているデータは中国語となります。
欠落の仕方も、最後の方が欠けるのか、それ以外なのかなど、教えてください。
コメントありがとうございます。
POSTデータは30000程度です。
欠落データは最後の方が欠落します。
回答1件
0
ベストアンサー
PHP 5.3.3ですが、何かパッチを当てているということはないでしょうか？
5.3.3のソースを見てみましたが、少し見た限りでは直接リクエストの入力データの数を
数えるコードは、見当たりませんでした。
そこでパッチですが、
Doc Bug #65778 wrong information about introduction of max_input_vars directive
で言及がありますが、PHP 5.3.3-7+squeeze17には、max_input_varsがあるようです。
また、Suhosinモジュールには、
suhosin.request.max_vars、suhosin.post.max_varsという設定があるようです。
90000を指定するのであれば、
suhosin.request.max_vars = 90000 suhosin.post.max_vars = 90000
のようにすれば良いようです。
設定の説明は、ここにあります。
Suhosinモジュールが適用されているのであれば、
この設定により対処できる可能性があります。
max_input_varsが使用できるバージョンについて
正式なリリースとしては、ドキュメントにもある通り、5.3.9以降で使用できますが、
後述する通り、セキュリティ的な面で5.3.11以降、5.4.1以降の方が望ましいと思います。
正式なリリースとは別に、max_input_varsはセキュリティ的な問題(CVE-2011-4885)の対処のため、
パッチが存在し、rpmなどでは、パッチを含むバージョンがリリースされています。
なお、使用する際は、このパッチによって入り込んだCVE-2012-0830も対処されたバージョンが
望ましいと考えられます。
ちなみに、正式なリリースでCVE-2012-0830が修正されたのは、このコミットによると考えられますが、
これはphp-5.3.11、php-5.4.1でリリースされています。
php-5.3.3のrpmについて調べると、CVE-2011-4885は5.3.3-4、CVE-2012-0830は
5.3.3-7で対応しています。
max_input_varsの判定方法の変化について
max_input_varsの判定方法は、バージョンによって異なります。
- ハッシュの要素数による不完全な方法(php-5.4.0、php-5.3.10以前)
zend_hash_num_elementsを使っており、PostデータにArrayがある場合に、 Arrayのサイズがmax_input_vars+1になった際にエラーメッセージを出し、 max_input_vars+2以上になると無視します。 例) data[100][100][100]のデータは、1000000件になりますが、max_input_varsが1000の場合、 それぞれのサイズは100なので、制限にかからず、全てのデータを読み込んでしまいます。
- 正確な方法(php-5.6以降 、php-5.5以降、php-5.4.1以降、php-5.3.11以降)
Improved max_input_vars directive to check nested variablesというコミットによって修正されました。
実際にパースしながら、データの数を数え、データの数がmax_input_varsを超えると、 エラーメッセージを出して無視します。
投稿2015/11/18 11:37
編集2015/12/02 13:19総合スコア1546
ご回答頂きありがとうございます。
パッチは意識しておりませんでした。
環境を確認してみましたが、Suhosinモジュールは適用されておりませんでした。
そうですか。
PHPはどの様に導入したものですか？
ソースコードからのmakeでしょうか？それともrpmでしょうか。
それと、関係あるかは分かりませんが、
apacheのモジュールはどの様なものを有効にしているでしょうか？
コメントありがとうございます。
PHPはyumでインストールしております。
yum -y install php php-gd php-mbstring php-mysql php-pdo php-xml php-imap php-process php-pecl-apc php-devel
また、apacheのモジュールは下記となります。（長くなり申し訳御座いません）
$ apachectl -M
core_module (static)
mpm_prefork_module (static)
http_module (static)
so_module (static)
auth_basic_module (shared)
auth_digest_module (shared)
authn_file_module (shared)
authn_alias_module (shared)
authn_anon_module (shared)
authn_dbm_module (shared)
authn_default_module (shared)
authz_host_module (shared)
authz_user_module (shared)
authz_owner_module (shared)
authz_groupfile_module (shared)
authz_dbm_module (shared)
authz_default_module (shared)
ldap_module (shared)
authnz_ldap_module (shared)
include_module (shared)
log_config_module (shared)
logio_module (shared)
env_module (shared)
ext_filter_module (shared)
mime_magic_module (shared)
expires_module (shared)
deflate_module (shared)
headers_module (shared)
usertrack_module (shared)
setenvif_module (shared)
mime_module (shared)
dav_module (shared)
status_module (shared)
autoindex_module (shared)
info_module (shared)
dav_fs_module (shared)
vhost_alias_module (shared)
negotiation_module (shared)
dir_module (shared)
actions_module (shared)
speling_module (shared)
userdir_module (shared)
alias_module (shared)
substitute_module (shared)
rewrite_module (shared)
proxy_module (shared)
proxy_balancer_module (shared)
proxy_ftp_module (shared)
proxy_http_module (shared)
proxy_ajp_module (shared)
proxy_connect_module (shared)
cache_module (shared)
suexec_module (shared)
disk_cache_module (shared)
cgi_module (shared)
version_module (shared)
reqtimeout_module (shared)
php5_module (shared)
ありがとうございます。
確認してみますね。
それと、データが欠けたことの確認方法ですが、
$_POSTの時点で確認しているでしょうか？
それともFuelPHPで何かをした際に分かるのでしょうか？
こちらこそ引き続きご返答頂き、ありがとうございます。
POSTデータの欠落確認はFuelPHPにて$_POST変換した
POST情報をログ出力して確認しました。
// POST情報取得
$params = Input::post();
// ログ出力
$param_r = print_r($params, true);
Log::debug('post data:'. $param_r);
試してみましたが、再現はしませんね。
できる限り環境は合わせたのですが。。(長いです。)
$ php oil -v
Fuel: 1.7.0 running in "development" mode
$ php -v
PHP 5.3.3 (cli) (built: Feb 22 2013 02:51:11)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
$ httpd -v
Server version: Apache/2.2.15 (Unix)
Server built: Feb 22 2013 11:19:58
$ cat /etc/redhat-release
CentOS release 6.4 (Final)
$ uname -a
Linux localhost.localdomain 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$apachectl -M
httpd: Could not reliably determine the server's fully qualified domain name, using localhost.localdomain for ServerName
Loaded Modules:
core_module (static)
mpm_prefork_module (static)
http_module (static)
so_module (static)
auth_basic_module (shared)
auth_digest_module (shared)
authn_file_module (shared)
authn_alias_module (shared)
authn_anon_module (shared)
authn_dbm_module (shared)
authn_default_module (shared)
authz_host_module (shared)
authz_user_module (shared)
authz_owner_module (shared)
authz_groupfile_module (shared)
authz_dbm_module (shared)
authz_default_module (shared)
ldap_module (shared)
authnz_ldap_module (shared)
include_module (shared)
log_config_module (shared)
logio_module (shared)
env_module (shared)
ext_filter_module (shared)
mime_magic_module (shared)
expires_module (shared)
deflate_module (shared)
headers_module (shared)
usertrack_module (shared)
setenvif_module (shared)
mime_module (shared)
dav_module (shared)
status_module (shared)
autoindex_module (shared)
info_module (shared)
dav_fs_module (shared)
vhost_alias_module (shared)
negotiation_module (shared)
dir_module (shared)
actions_module (shared)
speling_module (shared)
userdir_module (shared)
alias_module (shared)
substitute_module (shared)
rewrite_module (shared)
proxy_module (shared)
proxy_balancer_module (shared)
proxy_ftp_module (shared)
proxy_http_module (shared)
proxy_ajp_module (shared)
proxy_connect_module (shared)
cache_module (shared)
suexec_module (shared)
disk_cache_module (shared)
cgi_module (shared)
version_module (shared)
reqtimeout_module (shared)
php5_module (shared)
いただいたコードでFuelPHPのデバッグログ出力しました。
フォームのデータは、以下の様に作り、sheets[1]~sheets[100]で[detail][1]~[detail][40]まで試したので、32000件のデータで試しましたが、全てログに出ているようでした。
<input type="hidden" name="sheets[1][details][1][sort]" value="14">
<input type="hidden" name="sheets[1][details][1][checkInfo]" value="XXXXXXXXXXXXXXXXX">
<input type="hidden" name="sheets[1][details][1][comment]" value="">
<input type="hidden" name="sheets[1][details][1][answer]" value="Good">
<input type="hidden" name="sheets[1][details][1][checkItems][1][checkItem]" value="N.A.">
<input type="hidden" name="sheets[1][details][1][inputLength] value="30">
<input type="hidden" name="sheets[1][details][1][required]" value="">
<input type="hidden" name="sheets[1][details][1][checkType]" value="Text">
そちらでも同様のコマンドを発行した結果で、こちらとの差分はありますか？
コメントありがとうございます。
また、環境まであわせて調査頂き、大変感謝しております。
記載頂いた内容でデータ欠落が発生するか、試してみます。
（回答は来週になってしまいます。すみません。）
実は不具合発生しているのが客先環境となっており、何かを試す場合も依頼等が必要な為、返信がおそくなり申し訳ありません。
builtの日付が違う位しか差分ならそうです。
# uname -a
Linux WEB-SERVER 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
# cat /etc/redhat-release
CentOS release 6.4 (Final)
# httpd -v
Server version: Apache/2.2.15 (Unix)
Server built: Aug 13 2013 17:29:28
# php -v
PHP 5.3.3 (cli) (built: Jul 12 2013 20:35:47)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
ありがとうございます。
客先環境とのことで、情報の取得に時間がかかることも、
了解です。
返信していただいたバージョン情報ですが、おっしゃる通り、
あまり差はないようですね。
ちょっと見てみます。
それから、まだ確認していなかったのですが、30000件ほどのデータは、
欠落すると、何件ぐらいになるのですか？
また、tcpdumpの結果と比較すると、送られてきたもののどこが
欠落したかはわかると思うのですが、そうした比較はされたでしょうか？
ちょっと思いつくままに挙げているので、解決に直接結びつくかは
分かりませんが、回答可能であれば、教えてください。
コメント有難う御座います。
欠落後に何件になるのか確認しておりませんでした。確認致します。
tcpdumpの結果と比較するとどこが欠落しているかはわかりました。
その為、Androidアプリ側に問題は無いと切り分けを行いました。
諦めずに助けてくださり本当に感謝致します。
はっきり書かなかったのですが、
tcpdumpと、Log::debugの内容を比較したということでよいでしょうか？
> 欠落箇所はPOSTデータの後ろ側が欠落していると思われます。
という部分で断定していなかったので、比較していないのかと考えていました。
ふと思いついて、
php.iniに、
max_input_vars=90
を指定したところ、途中で途切れる現象が再現しました。
どうも、入れ子になっているトップレベルのArrayの要素数で
制限されるようです。
要素数が91まで主力され、その後が出力されて
いませんでした。
バージョンを新しくしましたが、90にしなければ再現はしなかったので、
おそらく新しくしたことは関係ないかと思います。
$ php -v
PHP 5.3.3 (cli) (built: Jul 15 2013 08:31:34)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
こちらでは、
<?php phpinfo(); ?>
だけのファイルにアクセスすると、
php.iniで設定したmax_input_varsが見えるのですが、
t.Kajさんの環境ではどうでしょうか？
WindowsでPHP 5.6.8の環境でも試しましたが、判定の仕方に差分があるようです。
PHP 5.6.8ではネストしたデータでも、正しく1000件を判定するようですが、
PHP 5.3.3ではトップレベルの要素数で判定されました。
＞ はっきり書かなかったのですが、
＞ tcpdumpと、Log::debugの内容を比較したということでよいでしょうか？
はい。ご記載頂いたtcpdumpと、Log::debugの内容を比較しました。
曖昧な表現をして申し訳御座いません。
phpinfoのアクセス結果にmax_input_varsが見えるか確認してみます。
また、PHP 5.3.3ではトップレベル要素数で判定されているというところまでご調査頂きありがとうございます。
トップレベルの要素数は14個でした。
すみません。
トップレベルというのは早とちりでした。
全ての要素を見ていない様なのですが、はっきりした判定条件は分からない、
というのが正確なところです。
(
[test] => 1
[sheets] => Array
(
[1] => Array
(
[details] => Array
(
[1] => Array
(
[sort] => 14
[checkInfo] => XXXXXXXXXXXXXXXXX
[comment] =>
[answer] => Good
[checkItems] => Array
(
[1] => Array
(
[checkItem] => N.A.
)
)
[inputLength] =>
[required] =>
[checkType] => Text
)
[2] => Array
(
となっているログの、
[sheets] => Array
(
[1] => Array
の[1] => Arrayの部分が、[100] => Arrayまで出力されるはずが、
[91] => Arrayまでしか出力されていませんでした。
トップレベルではなかったです。
比較の内容については、了解です。
こちらの質問が曖昧だったかと思います。気を付けます。
＞ トップレベルというのは早とちりでした。
＞ 全ての要素を見ていない様なのですが、はっきりした判定条件は分からない、
＞ というのが正確なところです
訂正のご連絡ありがとうございます。
PHPの設定について現在客先に問い合わせ中となりますが、POSTされた変数の数を数えたので報告致します。
max_input_vars未設定時:1012個前後
max_input_vars=90000設定時:2060個前後
後出し情報で申し訳ありませんが、実はmax_input_vars=90000を設定する前に
一度max_input_vars=2000で設定したことがあります。
（またmax_input_varsの設定は客先担当者へ依頼しており私は実施していません。その為、90000の設定が正しく行われているか未確認です）
現在依頼中のphp.iniとPHPinfoの設定内容次第ではありますが
「実はmax_input_varsの設定が2000のまま」又は、「Apache再起動していない」等のミスがあった可能性が考えられます。
当方下請けの為、「設定内容間違ってませんか？」と直接確認出来ないため、もどかしい状況です。先方より、回答あり次第、コメント追記致します。
情報共有ありがとうございます。
> 「実はmax_input_varsの設定が2000のまま」又は、「Apache再起動していない」
2060前後となると、その可能性はありますね。
状況についても、了解しました。
もう少し調べると、どうやら
php-5.3.3-4から、max_input_varsが導入されたようです。
t.Kajさんが 今使用されているのは、おそらくphp-5.3.3-23と思いますので、
max_input_varsが使えることには不思議はない様です。
可能であれば、
$ rpm -q php
php-5.3.3-23.el6_4.x86_64
して詳しいバージョンを確認してください。
以下のページにある様に、 セキュリティの問題があった際には5.3.3のソースに対して
パッチ適用して新たなバージョンを提供している様で、
以前私が見たのは5.3.3のソースだったので、
max_input_varsの実装が見つからなかった様です。
https://rpmfind.net/linux/RPM/centos/updates/6.7/x86_64/Packages/php-5.3.3-46.el6_6.x86_64.html
また、判定方法の変更は、変更前がハッシュのサイズ+1、
変更後が実際のデータの数で判定している様です。
質問で書いていただいたようなPostデータの内容からすると、
t.Kajiさんの運用環境での動作が、どうもこの変更後のものに近く思えるので、
その点に疑問が残ります。
その他、詳細を回答に反映しましたので、
必要があれば確認してみてください。
引き続きご調査頂きありがとう御座います。
＞$ rpm -q php
詳しいバージョンは客先に情報提供依頼致します。
先ほど、客先よりPHPINFOの内容を頂戴しmax_input_varsの設定を確認しましたが、設定値の記載が確認できました。
またApacheについても再起動して頂いているとのことで、狙いが外れてしまいました。
了解です。
他の可能性を考えてみますが、
max_input_vars=90000で、問題の現象が発生していて、
データが2060件程度で途切れていることが、
現時点のデータで確認された、と思ってよいでしょうか？
確認できていないことがあれば、
確認していただけますか？
プログラムソース周りを確認したところ下記の記述が見つかりました。
error_reporting(0);
こちらが原因でphp_errror_logにエラーが出力されていないと思われますので、error_reporting(-1);に変更した修正パッチを客先プログラムに提出し、エラーログを出力するよう依頼しております。
また、現在の確認状態としてはeripongさんの仰る通り、
max_input_vars=90000で、問題の現象が発生していてデータが2060件程度で途切れております。
エラーログの件了解しました。
ちょっと細かくて申し訳ありませんが、
現在の確認状態という場合の現在というのは、
max_input_vars=90000をphpinfoで確認した後のことで良いでしょうか？
phpinfoで確認した後、問題の操作を行うとエラーが出て
2060件の変数がログに出たことを確認したということですか？
それとも以前のデータからの判断でしょうか？
それから、apacheの再起動は、ログなどから再起動したことが
確認できていると思ってよいでしょうか？
max_input_varsを90000にしたことで変数の数が変わった様なのに、
それが2060件というところが、ひっかかっています。
変数の数というのは、同じ設定でも何度か実施すると変わるような
ものなのでしょうか？
rpm -q phpの結果を頂戴しましたので報告致します。
php-5.3.3-23.el6_4.x86_64
ブラウザを更新せずeripongさんのコメントを見落としてておりました。申し訳ございません。
また本不具合について適切な状況説明が出来ず、申し訳御座いませんでした。
本件の設定と情報提供状況は下記となります。
今年2月頃から不具合発生～7月頃まで
該当システムのバージョンアップがあった為、調査を放置
8月頃
POSTログ（Fuelログ）を受領しPOST情報が欠落していることが判明
9月頃
POSTログ（Fuelログ）を再度受領
9月末
tcpdumpを受領し、tcpdumpの時点ではPOST情報が欠落していないことを確認
10月初め
max_input_vars = 2000の設定を適用
10月中頃
max_input_vars = 90000の設定に変更
11月初め
POSTログ（Fuelログ）を再度受領
12月初め
PHP INFOの設定を受領
変数の数を数えたのは
max_input_vars未設定時は
9月頃のPOSTログから数えました。
max_input_vars90000設定時は
11月初めのPOSTログから数えました。
その為、PHPINFOは最新の受領情報ですが、
POSTログについては過去（11月）に受領した情報となります。
またApacheの再起動についても、担当者間の口頭レベルでの確認となり、
ログによる再起動確認は行っておりません。
また2060件については、10月初めに一旦設定しているmax_input_vars=2000が効いているかと思っていました。
rpm -q phpの結果について、了解です。
想定通りでした。
これだと、私の回答の「1. ハッシュの要素数による不完全な方法(php-5.4.0、php-5.3.10以前) 」に該当するので、max_input_varsは有効で、
ハッシュの要素数を見ているはずです。
1012個前後、2060個前後のPostデータの変数名を見て、
予想した通りの件数で途切れているかは確認できるでしょうか？
詳細な状況説明、ありがとうございます。
apacheのエラーログに、起動時のログが残っていないでしょうか？
10月中頃にmax_input_vars = 90000の設定に変更した後、
11月初めのPOSTログを取得する前に起動したかどうか、
一応の確認を取れればと思います。
また、今でも再現するということは、
今日、問題の操作をしても発生するということでしょうか？
> また2060件については、10月初めに一旦設定しているmax_input_vars=2000が効いているかと思っていました
これは私もそうかなと思っていたので、90000がなぜ効いていないのか、
疑問に思っています。
＞1012個前後、2060個前後のPostデータの変数名を見て、
予想した通りの件数で途切れているかは確認できるでしょうか？
申し訳ありません。ランダムに並んでしまうため確認することは難しいです。
Apacheのエラーログについては提供依頼してみます。
ただし1月以上前の情報ですのでログローテートの都合で、確認出来ない可能性があります。
また、現象の再現についても100%の条件で発生するものでは無いため、問題の操作を行っても発生するとは限らない状況です。
来週となってしまいますが、客先よりエラーログ受領後、報告致します。
以上、よろしくお願い致します。
ベストアンサーになっていたのですが、
この件はもう対応不要ということではないですよね？
一応、対応を続ける前提で以下のコメントを書きます。
> 申し訳ありません。ランダムに並んでしまうため確認することは難しいです。
並び替えて、Arrayのサイズが2001や1001になっているところがあるか、
という観点で良いですが、それなら可能でしょうか？
Apacheのエラーログについては了解です。
残っていると良いのですが。
現象が100%再現しないということも、了解です。
最後に発生したのがいつか、は分かるでしょうか？
max_input_vars=90000に設定された後は発生していない可能性を
疑っています。
もちろん、来週で問題ありません。
すみません。誤って「ベストアンサー」押してしまいました。
本件まだ完了はしていないです。ご配慮頂き有難うございます。
ご記載頂いた内容について次回ログ頂戴時にあわせて確認致します。
了解です。
ちょっと明日から一週間ほど、実際にこちらの環境で
検証しての回答が難しくなる予定です。
コメントを見たり、何かを調べて回答することは可能と思いますので、
コメントは変わらずつけていただいて問題ありません。
ご配慮頂きありがとうございます。
金曜日になってしまいましたが客先からログ提供がない状況となり申し訳ございません。
了解です。
ご無沙汰しております。
本件について客先よりリクエスト内容欠落が発生するAPIのPOST内容を分割等変更し、本不具合の改善を行うよう指示されました。
その為、エラー原因等が特定できていない状況ではありますが、本件についてのPHP／Apacheまわりの設定により問題改善を行う調査についてもログをご提供いただけなくなってしまいました。
原因がわからないままですが、本件への調査は中止となりました。
長期にわたりご調査ご協力いただき有難うございました。
原因が分かっていない以上、どこまで分割したら良いのか確証は無いと思うので、
可能なら分割は暫定対応として、原因調査は続けた方が良いかと思いますが、
客先指示ということで了解しました。
それと、蛇足かと思いますが、今回収集しようとしたログは、
不具合調査時に必要になることが多いので、
ログ収集依頼の基本セットのようなものを決めて、
不具合調査の際には毎回その基本セットを
収集してもらう様にしても良いかもしれません。
コマンド一つで集められるようにして、
そのコマンドをサーバに配置しておいて、
コマンド実行と結果の収集を依頼できると便利と思います。
見捨てることなくお付き合い下さり感謝致します。
ログ収取セットという考えはありませんでした。
ご教授ありがとうございます。
これからのシステムリリース内容に反映していきたいと思います。
あなたの回答
tips
プレビュー
