さまざまなPHPフレームワークセッションドライバーをPHP 7.0で使用すると、バグが発生します。CodeIgniterデータベースドライバーの使用中にこの問題が最初に発生し、CodeIgniterの問題であると想定しました。しかし、それ以来、複数のセッションドライバーと複数のフレームワークでそれを経験しました。この時点で、セッションドライバーのタイプは無関係であると安全に結論付けました-一見ランダムに見えますが、アプリケーションがクラッシュし、ログが記録されます(Apacheとphpの両方を試しました- fpm + nginx)次のように入力します。
PHPの致命的なエラー:session_start():ストレージモジュールの初期化に失敗しました:ユーザー(パス:[php.iniパスにあるものは何でも])
私が使用しているドライバーは、php.iniで設定された値を使用せず、session.save_handlerをphp.iniのファイル、redisなどに設定したかどうか、および設定したパスに関係なく(Redisサーバーの場合は完全に-ファイルが有効になっている書き込み可能なフォルダ)エラーが発生します。フレームワークの外部のphpファイルでネイティブの「session_start()」が呼び出されない限り、ここでのパスにヒットすることはありません。また、フレームワークの外部で「session_start()」を呼び出すことは正常に機能します...したがって、明らかにPHPはパスにアクセスできます。ある時点で、セッションドライバーがフレームワークのハイブリッドになるかのようです。ドライバーとphp.iniに設定されているものすべて。エラーメッセージには常にsession.save_handlerの「user」が含まれているため、明らかにphp.iniからプルされていません...しかしパスはです。なぜこれが発生するのでしょうか。これは1つです。あなたがそれを経験するまで説明するのが難しいそれらの問題の...そして何百ものセッションでもすべてがうまくいくように見えるので(突然動作を停止するまで)再現するのは難しいです。Apacheを再起動しても問題は修正されません-そこでここでは多くの問題が発生しており、ダウンタイムを回避するためにマシンを再起動するだけです。明らかに、PHP 7マシンはロードバランサーのローテーションから引き出されます...しかし私は今までに物事を理解してもらいたいと思っていました。
自分でコンパイルしたPHP 7.0 RC5、RC6、RC8、およびUbuntu 15.10 Wily(7.0.0-2 + deb.sury)の最新のOndřejSurýPPAで問題が発生しました。 org〜wily + 1)。CodeIgniter&Symfonyで問題が発生し、フレームワークで使用されているドライバーのタイプ(ファイル、データベース、redis)またはphp.iniで設定されているsession.save_handlerに関係なく問題が発生しました(繰り返しになりますが、ここでは関係ありませんが、言及する必要があると思いました)私は組み合わせを試し、物を捨て続けていますが、この問題は毎回発生します(Webサイトへのトラフィックによっては12時間以上かかることもあります) 。
あなたが提供できるどんな助けにも感謝します!私は提案を受け入れており、この時点で何でも試してみることをいとわない。
このエラーは、セッションハンドラーのopen()
関数がブール値のTRUEを返さない場合に発生します。これは、明らかに何らかの障害を意味します。
データベースへの接続の失敗、ファイルのオープンの失敗、存在しないディレクトリなどである可能性があります。これは、セッションハンドラが実際に使用するものによって異なります。
このエラーを回避するには、関数_openがtrueを返す必要があります。
データベースまたはファイルのいずれを使用する場合でも、nullまたは空にすることはできません。
データベースを使用してセッションデータを格納する場合、データベースを空白のままにするか、ブール値を返しません。これがこのエラーの主な理由です。
class session_handler
{
public function __construct()
{
session_set_save_handler(
array($this, "_open"),
array($this, "_close"),
array($this, "_read"),
array($this, "_write"),
array($this, "_destroy"),
array($this, "_gc")
);
}
public function _open($savePath, $sessionId)
{
return true;
}
public function _close() { }
public function _read($id) { }
public function _write($id, $data) { }
public function _destroy($id) { }
public function _gc($max) { }
}
PHP 7。バグかどうかはわかりません。
これは通常、セッションが使用するドライバー(ファイル、データベース)に接続できないことが原因です。
config.php
ファイルを見て問題を解決しました
$config['sess_driver'] = 'database';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 7200;
$config['sess_save_path'] = 'ci_sessions';
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = FALSE;
つまり、データベースを使用したので、何らかの理由で接続できないということです。 (ファイルの場合、おそらくキャッシュされたファイルを書き込む権限がありません)
次にログをオンにしました
$config['log_threshold'] = 4;
ここで4 = All Messages
..次にページを更新すると、application/logs
にlog-#.php
というファイルがあります。#
は日付です。
INFO - 2017-08-30 10:05:41 --> Database Driver Class Initialized
ERROR - 2017-08-30 10:05:41 --> Severity: Warning --> mysqli::real_connect(): (HY000/1045): Access denied for user 'user'@'localhost' (using password: YES) /var/system/database/drivers/mysqli/mysqli_driver.php 202
ERROR - 2017-08-30 10:05:41 --> Unable to connect to the database
ERROR - 2017-08-30 10:05:41 --> Severity: Warning --> mysqli::real_connect(): (HY000/1045): Access denied for user 'user'@'localhost' (using password: YES) var/system/database/drivers/mysqli/mysqli_driver.php 202
ERROR - 2017-08-30 10:05:41 --> Severity: Error --> session_start(): Failed to initialize storage module: user (path: ci_sessions) /var/system/libraries/Session/Session.php 140
したがって、ユーザーがデータベースにアクセスでき、それが機能することを確認するだけです。
私の場合、PHP ver 5.6
とCI ver 3.4
(Codeigniter)サーバーを使用しています:BIGROCK
ライブサーバーでこれらの問題が見つかりました。
それから久しぶり。データベースを削除して再作成しようとしました。
それから私だけがpermissionデータベースにアクセスするユーザーを与えていないことを知りました。
したがって、データベースとユーザーの作成が終了したら、データベースにアクセスするためのアクセス許可(previlleges)をユーザーに付与する必要があります。
あなたの場合に役立つかどうか教えてください。ありがとう。
これは、session_save_pathが無効な場合にのみ発生します。セッションデータをデータベースに保存する場合は、CIがデータを保存するようにセッションテーブルを作成する必要があります。そうしないと、このエラーが発生します。誰かを助けてくれることを願っています
システムを移行して、非常に必要な更新を行うことにしました。 Codeigniter3とphp7.2を使用してこの問題に遭遇しました。問題を見つけた後、私はそれがどれほどばかげているかを理解し、どうしてもっと早くそれを理解しなかったのか疑問に思いました。 ????
とにかくここに少なくとも私にとっての解決策があります。
明らかに、memcacheDがインストールされていることを確認してください。
Sudo apt-get update
Sudo apt-get install php7.2-memcached
それでよければ、他のすべてのチェックに進むことができます。
Codeigniterの設定ファイル「/application/config/config.php」には、セッションオプションを指定するセクションがあります。
$config['sess_driver'] = 'memcached';
$config['sess_cookie_name'] = 'some_session_name';
$config['sess_expiration'] = 7200;
$config['sess_save_path'] = NULL;
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = FALSE;
私にとって変更が必要な行は次の行でした:
$config['sess_save_path'] = NULL;
CI3のマニュアルに記載されているように、これを有効なパスに設定してください。正しい設定は次のようになります。
$config['sess_driver'] = 'memcached';
$config['sess_save_path'] = 'localhost:11211';
Memcachedサーバーの場所を反映するように「localhost」を変更してください。
詳細については、 Codeignier Session Manual を参照してください。
こちらもご覧ください: php memcacheD Sessions support
ページ上のコメントが削除された場合、私はここに投稿しています:
セッション制御に「memcache」ではなく「memcacheD」拡張を使用する場合(2つの異なる拡張があります)、php.iniの変更に注意を払う必要があります。
GoogleのほとんどのWebリソースは、memcacheDよりも古いバージョンであるため、memcacheに基づいています。彼らは次のように言うでしょう
session.save_handler = memcache session.save_path = "tcp:// localhost:11211"
ただし、memcacheDに関しては無効です
そのようにphp.iniを変更する必要があります
session.save_handler = memcached session.save_path = "localhost:11211"
ほら、プロトコル識別子はありません
テストのために、これを実行して、php自体にmemcacheDへのアクセスに問題がないことをユーザーに確認しました。
session_start();
header('Content-Type: text/plain');
session_start();
if(!isset($_SESSION['visit']))
{
echo "This is the first time you're visiting this server\n";
$_SESSION['visit'] = 0;
}
else
echo "Your number of visits: ".$_SESSION['visit'] . "\n";
$_SESSION['visit']++;
echo "Server IP: ".$_SERVER['SERVER_ADDR'] . "\n";
echo "Client IP: ".$_SERVER['REMOTE_ADDR'] . "\n";
print_r($_COOKIE);
$servers = explode(",", ini_get("session.save_path"));
$c = count($servers);
for ($i = 0; $i < $c; ++$i) {
$servers[$i] = explode(":", $servers[$i]);
}
$mem = new memcached();
$mem->addServer('127.0.0.1', '11211', '1');
$mem->set('011', 'Hello There');
print_r($mem->get('011'));
print_r($mem->getAllKeys());
これにより、memcacheDが正常に機能していることがわかりました。
また、php.iniには、注意すべきいくつかのオプションがあります。 [session]またはsession.save_pathを検索するだけです。 CI3は、php.iniファイルのこのオプションを使用しないと述べていますが、フレームワークの外部で一貫性を保つためにmemcacheDを使用する場合は、設定する価値があります。
これは、php.iniファイルの1327行目あたりから始まります。
[Session]
; Handler used to store/retrieve data.
; http://php.net/session.save-handler
session.save_handler = memcached
; Argument passed to save_handler. In the case of files, this is the path
; where data files are stored. Note: Windows users have to change this
; variable in order to use PHP's session functions.
;
; The path can be defined as:
;
; session.save_path = "N;/path"
;
; where N is an integer. Instead of storing all the session files in
; /path, what this will do is use subdirectories N-levels deep, and
; store the session data in those directories. This is useful if
; your OS has problems with many files in one directory and is
; a more efficient layout for servers that handle many sessions.
;
; NOTE 1: PHP will not create this directory structure automatically.
; You can use the script in the ext/session dir for that purpose.
; NOTE 2: See the section on garbage collection below if you choose to
; use subdirectories for session storage
;
; The file storage module creates files using mode 600 by default.
; You can change that by using
;
; session.save_path = "N;MODE;/path"
;
; where MODE is the octal representation of the mode. Note that this
; does not overwrite the process's umask.
; http://php.net/session.save-path
;session.save_path = "/var/lib/php/sessions"
session.save_path = "locahost:11211"
設定を確認するもう1つの場所は、mecacheDサーバー構成ファイルです。システムによって、その場所は異なる場合があります。私にとっては、/ etc /ディレクトリの下にありました。
/etc/memcached.conf
私が得ていたエラーを参照するための画像:
[〜#〜]編集[〜#〜]
ソケット、つまりunix:///some/place/memcached.sockを使用してMemcachedサーバーに接続している場合、これを機能させる方法については正確に文書化されていません。設定で次のことを行うだけです。
$config['sess_save_path'] = "/some/place/memcached.sock:11211";
/ your-Codeigniter-project/system/cacheの権限とその内容を0777に変更しただけで、機能しました。権限がないため、実際にはセッションファイルを作成できません。次のコマンドを使用しますSudo chmod 0777 /your-Codeigniter-project/system/cache
Sudo chmod 0777 /your-Codeigniter-project/system/cache/*
注:上記の「your-Codeigniter-project」をプロジェクトパスに置き換えてください。
同様の問題が発生しました。_session_set_save_handler
_を使用して独自のカスタムハンドラーを設定し、memcachedに移動しましたが、次のエラーが発生し続けました。
Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/7.0/session) in Unknown on line 0
「write」関数は(startと同様に)ブール値を返す必要があることがわかりましたが、公式のPHPドキュメントで戻り値について言及していないsession_set_save_handlerの唯一の関数です。したがって、デフォルトのセッションハンドラーに戻っているように見えますが、デフォルトのセッションハンドラーにerrorを指定しているだけです。
エラーもドキュメントページも私たちを解決策に導くことは決してなかったでしょう...
私は問題を理解したと思います。この質問を締めくくります。基本的に、フレームワークセッションドライバー/構成で問題が発生した場合(SQL接続の超過、Redisでのメモリ不足の問題など)、php.iniで設定されたsess.save_pathを使用しようとしたときに元に戻るようです。フレームワークセッションドライバー。したがって、フレームワークドライバーがphp.iniのデフォルトのsess.save_pathと互換性がない限り、このエラーが発生します。私にとっては、php.iniのsess.save_handlerにも戻す方が理にかなっています...しかし、これが問題である場合は、明らかに、解決する必要のあるアプリ構成に大きな問題があります。
このエラー自体がセッションを壊しているのではありません...それはフレームワークセッションドライバーの根本的な問題でした。私は馬鹿げていると感じます...しかし、ログは基本的に私を野生のガチョウの追跡に送りました。問題は他の場所にあったため、nginxまたはApacheを再起動しても問題は解決しませんでした。利用可能なPHP 7 RedisライブラリとSQLの問題は私のせいでしたが、まだ解決すべき問題があると思います。いくつかの組み合わせを試し、同じ結果を得た後、問題が発生しました。 PHP 7でRedisセッションを使用すると、まだ奇妙なエラーが発生しますが、前述のように、PHP 7Redisライブラリはあまり成熟していません。
この問題を解決するには、コードイグナイターを最新バージョンにアップグレードする必要がありました。
実行中:
CentoOS: 7.6.1810
Mysql: 8.0.15
PHP: PHP 7.3.4
セッションをデータベースからファイルやMemcachedに移動するなど、さまざまなことを試しました。何も機能しませんでした。それを修正した唯一のことは、CI 3.0から3.1に移行し、ブームが想定どおりに機能することでした。
それが誰かを助けることを願っています。
php.iniを変更します:
session.save_path = "N;/path" **to** session.save_path = "/tmp"
php7-fpmを再起動します