FreeBSD 13.1のサポートが終わるので、FreeBSD 13.2にバージョンアップした。コマンドは、下記で行った。
freebsd-update fetch
freebsd-update install
freebsd-update upgrade -r 13.2-RELEASE
freebsd-update install
shutdown -r now
freebsd-update install
pkg-static upgrade -f前のFreeBSD 12.2から13.1へ上げたときと、コマンドは一緒。今回は、すんなりとバージョンアップされた。
FreeBSDで、”pkg upgrade”して、パッケージを最新の状態にしたところ、MariaDBが起動しなくなった。エラーログをみていると、DBのテーブルを修復したあとにDBがシャットダウンされている。DBのファイル破損が原因かと思い、いろいろと調べて対応したが、実はファイルの問題ではなかった。
原因は、MariaDBのバージョンが「MariaDB 10.5」に上がったことによる「my.cnf」ファイルの変更だった。
/usr/local/etc/mysql/conf.d/my.cnfこのconf.dのディレクトリに、my.cnfがあることで、これを読みにいって、その設定で失敗して、サービスが落ちていた。同じところに、client.cnfもserver.cnfもあるが、これを読まずにmy.cnfを先に読みにいって、落ちていた。my.cnfは、１つ上の階層の「/usr/local/etc/mysql/」にもあり、conf.dの下を読み込むように書かれている。
いろいろと行ったのだが、対応の正解は、conf.dの下のmy.cnfを消す（リネームでOK）。server.cnfとclient.cnfの設定を確認して、MariaDB（mysqld_safe）を起動させる。
ちなみに、errファイルに記録されていたログは下記。あとは、ログ自体が出力されていない。ログがそもそも出力されていなければ、my.cnfを疑うべきだった。
2022-02-05 15:36:39 0 [Note] /usr/local/libexec/mariadbd (initiated by: unknown): Normal shutdown
2022-02-05 15:36:39 0 [Note] Event Scheduler: Purging the queue. 0 events
2022-02-05 15:36:39 0 [Note] InnoDB: FTS optimize thread exiting.
2022-02-05 15:36:40 0 [Note] InnoDB: Starting shutdown...
2022-02-05 15:36:40 0 [Note] InnoDB: Dumping buffer pool(s) to /var/db/mysql/ib_buffer_pool
2022-02-05 15:36:40 0 [Note] InnoDB: Restricted to 2016 pages due to innodb_buf_pool_dump_pct=25
2022-02-05 15:36:40 0 [Note] InnoDB: Buffer pool(s) dump completed at 220205 15:36:40
2022-02-05 15:36:40 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2022-02-05 15:36:40 0 [Note] InnoDB: Shutdown completed; log sequence number 1363646560; transaction id 111190553
2022-02-05 15:36:40 0 [Note] /usr/local/libexec/mariadbd: Shutdown completeFreeBSDでLet’s Encryptを使ってWebサーバのSSL証明書を作っている。毎回、手作業で行うのはめんどくさいので、cronで自動的に実行させていた。自動更新させていたが、ある日、証明書の有効期限が切れているとブラウザが警告してきたので、調べたところ・・・pkgのアップデートを少し前にやったときに実行ファイルのバージョン（というかファイル名）が変わっていたようで、そのため、cronは実行されるがエラーになっていた模様。ついでにもともとシンボリックリンクだったはずだが、それも消えていた。
もともと実行していたコマンド
/usr/local/bin/certbot renew
今のコマンド
/usr/local/bin/certbot-2.7 renew
凡ミス。pkgをアップデートするときは、気をつけないといけないな。
Emacsを閉じようとしたら、エラーで終了できず。原因を調べたら、Emacsのmessageバッファに以下のようなエラーが。
kkc-save-init-file: Opening output file: 許可がありません, /home/zen/.emacs.d/kkcrc (No changes need to be saved) kkc-save-init-file: Opening output file: 許可がありません, /home/zen/.emacs.d/kkcrc [2 times] user-error: Minibuffer window is not active kkc-save-init-file: Opening output file: 許可がありません, /home/zen/.emacs.d/kkcrc Mark set [2 times]
書き込みができないので、エラーになっている模様。そのため、ディレクトリのパーミッションを調べると、自分のホームディレクトリなのに、オーナーがrootになっている。これが原因。
drwx------ 3 root root 4096 1月 22 2019 .emacs.d
chown でオーナーを自分に変更。これで書き込みができるようになり、解消された。
sudo chown -R zen .emacs.d
なんで、オーナーがrootになっていたのだろうか。今まで設定変更で、suして、emacsをずっと使っていたのが原因だろうか。
Emacsを閉じようとしたら、エラーで終了できず。原因を調べたら、Emacsのmessageバッファに以下のようなエラーが。
kkc-save-init-file: Opening output file: 許可がありません, /home/zen/.emacs.d/kkcrc (No changes need to be saved) kkc-save-init-file: Opening output file: 許可がありません, /home/zen/.emacs.d/kkcrc [2 times] user-error: Minibuffer window is not active kkc-save-init-file: Opening output file: 許可がありません, /home/zen/.emacs.d/kkcrc Mark set [2 times]
書き込みができないので、エラーになっている模様。そのため、ディレクトリのパーミッションを調べると、自分のホームディレクトリなのに、オーナーがrootになっている。これが原因。
drwx------ 3 root root 4096 1月 22 2019 .emacs.d
chown でオーナーを自分に変更。これで書き込みができるようになり、解消された。
sudo chown -R zen .emacs.d
なんで、オーナーがrootになっていたのだろうか。今まで設定変更で、suして、emacsをずっと使っていたのが原因だろうか。
“.emacs.d/kkcrc” は、かな漢字変換の設定や学習結果が記録されているファイル。変換の結果で学習した内容が追加されていく。
WordPressのcocoonテーマで、下記のエラーが表示される。
/wp-content/themes/cocoon-master/lib/open-graph.php(356)
調べると、curlを使った処理でエラーになっていた。PHPのモジュールでcurlが入っているかみたところ、インストールされていなかった。FreeBSDのパッケージからcurlのモジュールをインストールして、apacheを再起動した。これで、解決した。
pkg install php73-curl
WordPressのアップデート時に、下記のエラーが発生する。
Fatal error: Maximum execution time of 30 seconds exceeded in /usr/xxxxxx/xxxxxx/blog2/wp-content/plugins/ssh-sftp-updater-support/phpseclib/Crypt/Base.php(2554) : eval()'d code on line 563
いろいろと調べたところ、実行時間の問題のようなので、PHPの最大時間を変更する。php.iniを編集し、「max_execution_time」の値を30から60に変更して、apacheを再起動。
;変更前 ;max_execution_time = 30 ;変更後 max_execution_time = 60
実行時間を最大30秒から60秒に増やしたが、それでもギリギリだった。PHP7にしたため、いろいろと重くなっているのかもしれない。
PHPをPHP7.3に上げたところ、Wordpressのアップデートで、下記のエラーが表示された。
Fatal error: Uncaught Error: Call to undefined function hash_algos() in /usr/xxxxxx/xxxxxx/wp-admin/includes/file.php:1166 Stack trace: #0
該当ファイルのエラーになったソースコードをみると下記のようになっていた。
if ( ! function_exists( 'sodium_crypto_sign_verify_detached' ) || ! in_\
array( 'sha384', array_map( 'strtolower', hash_algos() ) ) ) {
「hash_alogs()」でエラーになっているようだ。調べてみたら、php73-hash-7.3.X がインストールされていなかった。FreeBSDでパッケージから、php73-hashをインストールして、apacheを再起動した。
# pkg install php73-hash Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 1 package(s) will be affected (of 0 checked): New packages to be INSTALLED: php73-hash: 7.3.8 Number of packages to be installed: 1 152 KiB to be downloaded. Proceed with this action? [y/N]: y [1/1] Fetching php73-hash-7.3.8.txz: 100% 152 KiB 155.8kB/s 00:01 Checking integrity... done (0 conflicting) [1/1] Installing php73-hash-7.3.8... [1/1] Extracting php73-hash-7.3.8: 100% Message from php73-hash-7.3.8: This file has been added to automatically load the installed extension: /usr/local/etc/php/ext-20-hash.ini
すぐにWordpressのアップデートを試すと、「別の更新が進行中です。」と出てしまうことがある。これは、前のアップデートによるロックが発生しているため。15分経てば、DBのロックが解除されるので、時間が立ってから試す。
PHPをPHP5.6からPHP7.3に上げたところ、Wordpressで以下のエラーが発生した。
Fatal error: Uncaught Error: Call to undefined function xml_parser_create()
PHPのオプションで、xmlに関するモジュールがインストールされていないことが原因だった。FreeBSDでパッケージからインストールしているので、下記のようにpkgコマンドでインストール。その後、Apacheを再起動し、無事にエラーは解消。
pkg install php73-xml-7.3.8