ma-to
Forum Replies Created
-
AuthorPosts
-
cloudy さん 返信有難うございます。
CGI Perl や fastcgi ですね。
頑張って設定してみます。kusanagi9 の利用が初めてで、随分と変更されている点が多いようですね。
kusanagi8 の時に何度か mod_perl を使っていたので、使えるものと思っていました。有難うございます。
当方でも同じ症状が出ました。
原因はWordPressのアップデートによるHHVMとの相性の問題でしょうね。general-template.phpを差し替えればHHVMでも動作しますが、後々問題が出ないとも限らないので、既存のgeneral-template.phpをそのまま使いたい場合はphp7で利用することをお勧めします。
将来的にWordPressのアップデートで直る可能性もありますからね。- This reply was modified 5 years ago by ma-to.
2019/02/21のアップデートで改善されています。
2019/02/21のアップデートで改善されましたね。
自己責任でお願いします。
# yum remove kusanagi*
このような感じでしょうね。
kusanagiと付く物は削除されます。自分の意図するバージョンをインストールしようとしても、依存関係でインストール出来ない場合も
あることをご理解ください。今回の場合はPHPですが、Apache等の場合は依存関係で古いバージョンに戻ればい場合もありま
す。
何度も申し上げますが、自己責任でお願いします。nginxで動作していた環境は
”
「KUSANAGI」 ワンポイントTips Apache利用でアップデートしたら再起動できなくなったときの対処法
https://column.prime-strategy.co.jp/archives/column_1834
”
の対処で起動することが出来ました。しかし、先に投稿させていただいた、古いkusanagiから最新版に一気にアップデートした環境では
SSL関連の不具合も対処していますが、全く起動せず。strace httpd -t
で起動内等を確認すると、
正常に起動するものは
——-
.
.
.
rt_sigaction(SIGRTMIN, {0x7f6f4e719790, [], SA_RESTORER|SA_SIGINFO, 0x7f6f4e7225d0}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7f6f4e719820, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f6f4e7225d0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
brk(NULL) = 0x13e2000
brk(0x1403000) = 0x1403000
brk(NULL) = 0x1403000
getrandom(“\333W\251\37\337\t\201\257”, 8, 0) = 8
getrandom(“\252\2062K\354_\302\t”, 8, 0) = 8
getrandom(“]S \237\332\313\322\315”, 8, 0) = 8
getrandom(“\23\20\303>-\rW\223”, 8, 0) = 8
getrandom(“\336\354\0206\331\267\274\253”, 8, 0) = 8
getrandom(“\306\217\33\246\302\235i\312”, 8, 0) = 8
getrandom(“\367@\27\244\211’\237\304”, 8, 0) = 8
getrandom(“\321*\315\260\233\272%\261”, 8, 0) = 8
getrandom(“\205anb\177X\6\320”, 8, 0) = 8
getrandom(“\345\305\242\304\224\251)\353”, 8, 0) = 8
getrandom(“\241$\364\357\277\362\327A”, 8, 0) = 8
.
.
.——-
となりますが、起動しないApacheの場合は、
——-
.
.
.
rt_sigaction(SIGRTMIN, {0x7f406c4ac790, [], SA_RESTORER|SA_SIGINFO, 0x7f406c4b55d0}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7f406c4ac820, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f406c4b55d0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM64_INFINITY}) = 0
brk(NULL) = 0x8d8000
brk(0x8f9000) = 0x8f9000
brk(NULL) = 0x8f9000
getrandom(0x7fffbfb52910, 8, 0) = -1 ENOSYS (Function not implemented)
open(“/etc/localtime”, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=292, …}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=292, …}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f406d3eb000
read(3, “TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3\0\0\0\3\0\0\0\0″…, 4096) = 292
lseek(3, -176, SEEK_CUR) = 116
read(3, “TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0″…, 4096) = 176
close(3) = 0
munmap(0x7f406d3eb000, 4096) = 0
write(2, “[Fri Jan 25 15:40:32.430517 2019″…, 137[Fri Jan 25 15:40:32.430517 2019] [:crit] [pid 7914] (38)Function not implemented: AH00141: Could not initialize random number generator
) = 137
exit_group(1) = ?
+++ exited with 1 +++
——-getrandomの部分に不具合があるようで、途中で止まっているようです。
今、nginxで動いていたkusanagiをTEST的にhttpdに切り替えてみました。
結論から言うとapacheの起動が出来ません。
この環境は都度アップデートしてきた環境なので、上記の2台とは異なります。でも、apacheに切り替えると起動しないとということは、kusanagi-httpd-2.4.37-1.noarchに問題があるような気がします。
追加情報
httpd -t
とか
httpd -k
とかでも情報が出てこないということは、confの不具合と言うよりは、apache本体が壊れているような
気がします。apacheの起動ログにほとんど情報がありませんね。
他の環境でも試しました。
kusanagi-8.2.1-1 から kusanagi-8.4.2-1 へのアップデートでも全く同じ症状が出ていますね。
kusanagi-httpdの不具合ということは無いですかね??
複数台あるkusanagiで今回含め2台のアップデートで同じ症状が出ているので、アップデートによる不具合
と考えていますが、何が原因かまで突き止められませんでした。なにか糸口は無いですかね???
kusanagi-httpd に同梱されているhtpasswdに問題がありそうな感じですが、原因を突き止めることができす。
同時期にopenssl-1.0.2pやopenssl-1.1.1にアップデートされているので、もしかするとこちらが怪しいかもhtpasswdでオプション無しで実行するとmd5の暗号化らしいのですが、他の暗号化でも確認してみました。
■ SHA1
htpasswd -c -s ./htpasswd test
問題なく生成される■ md5
htpasswd -c -m ./htpasswd test
htpasswdのファイルは生成されるが、空っぽでエラーも出る■ CRYPT
htpasswd -c -d ./htpasswd test
htpasswdのファイルは生成されるが、空っぽでエラーも出る■ bcrypt
htpasswd -c -B ./htpasswd test
htpasswdのファイルは生成されるが、空っぽでエラーも出る結果的にSHA1以外はエラー
ただし、古いkusanagiから最新版にアップデートした環境では全く問題なく生成されます。
アップデートを行っていない
kusanagi-httpd-2.4.34-3 と kusanagi-httpd-2.4.35-1 でこの症状が出ることを確認しました。複数のKUSANAGIが有るので、同じ様に試しました。
kusanagi-httpd-2.4.33-2.noarch OK
kusanagi-httpd-2.4.34-3.noarch NG 今回発覚したKUSANAGIにインストールされているApache
kusanagi-httpd-2.4.35-1.noarch NGおそらく、2018年9月4日と2018年10月16日にバージョンアップされていますが、そこで使われているApacheに問題が有るのでしょうね。
改善をお願いいたします。
- This reply was modified 6 years, 1 month ago by ma-to.
先程リリースされた
kusanagi-httpd
kusanagi-nginx
kusanagi-php7のアップデートで、改善されていますね。
おそらく、7/7のアップデートの不具合だったのかもしれませんね。違うホスティングサービスですね。
異なるホスティング会社のKUSANAGIを利用していますが、全て同じ症状ですね。
おそらく、KUSANAGI全般に発生している事象だと思います。皆が気づかないのは、Nginx+HHVMの組み合わせで利用しているので、障害が
出ていないものと思われます。mamemoyashi 様の投稿と同様の症状で、
kusanagi provision kusanagi_html
にて作成しても
kusanagi provision –lamp kusanagi_html
にて作成し、手動でwordpressを設定しても同様の症状が発生します。既存で利用している環境でも現在症状が発生しています。
もちろん新規で作成しても発生します。その他の症状としては、固定ページに「すべて(1)」になっているにも拘らず一覧に表示されません。
-
AuthorPosts