Java Update でスクリプトエラーが出る

◆環境
Windows 10 1903
Java SE8 Update 211 → Update 221 への自動更新通知


更新通知が出たので、更新を試みると次のようなエラーが発生。

f:id:savakan:20190720103923p:plain

スクリプトエラー

!このページのスクリプトでエラーが発生しました。

ライン: 1
文字: 1
エラー: ')'がありません。
コード: 0
URL:

このページのスクリプトを実行し続けますか?

はい(Y)  いいえ(N)


対応としては、Oracleのサイトからインストーラを入手して、インストール。

インストール中に、古いバージョンを削除するか尋ねられるので、予め古いバージョンを消す必要は無い。

ThinkPad SL300 のHDDをSSDに換装

4月に部屋を片付けていたら、古いノートPCが出てきた。

ThinkPad SL300 ってノートPCで、ITmedia に2008年の記事があった。
www.itmedia.co.jp

Windows Vistaだったが、暫く前に使わなくなり、遊びでUbuntuを入れたものの、そのまま片付けられていた。

f:id:savakan:20190427142650j:plain

過去の注文メールで確認すると、CPUはCore 2、メモリ2GB、HDD160GBだった。

2009年2月に買ったもので、86000円ぐらい。

f:id:savakan:20190427142704j:plain


特に故障もせずしまい込んでいたので、これはまだ使えると思い、HDDをSSDへ換装することにした。

まずは楽天SSDを発注。安定のSanDisk





やっぱりSSDは重さも軽い。 f:id:savakan:20190427142726j:plain

Thinkpadは、部品の交換が容易な構造なのが良い。

さっそくHDDを抜こうと黒いラベルを引っ張るが、相当硬い。

とにかく抜けない(´・ω・`)

諦めかけていた、その時!!!

やっぱり抜けない(´・ω・`)

滑らない軍手を持ち出して、何とか抜いた。

f:id:savakan:20190427151224j:plain f:id:savakan:20190427151255j:plain

HDDを外してSSDへ交換し、差し込んで電源を投入。

BIOSで認識したので、あとは適当なOSをインストールして再利用することにする。

yum update を途中で終了してしまい、エラーになった後の対処

【環境】
CentOS Linux release 7.6.1810 (Core)


発端は、、、
yum update している途中で、うっかりターミナルを閉じてしまった(´・ω・`)


再びログインして、 yum update するとエラーが発生した。

# yum update
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.yz.yamagata-u.ac.jp
 * epel: ftp.yz.yamagata-u.ac.jp
 * extras: ftp.yz.yamagata-u.ac.jp
 * updates: ftp.yz.yamagata-u.ac.jp
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ glibc.x86_64 0:2.17-260.el7_6.4 を 更新
--> 依存性の処理をしています: glibc = 2.17-260.el7_6.4 のパッケージ: glibc-common-2.17-260.el7_6.4.x86_64
---> パッケージ glibc.x86_64 0:2.17-260.el7_6.5 を アップデート
--> トランザクションの確認を実行しています。
---> パッケージ glibc.i686 0:2.17-260.el7_6.4 を インストール
--> 依存性の処理をしています: libfreebl3.so(NSSRAWHASH_3.12.3) のパッケージ: glibc-2.17-260.el7_6.4.i686
--> 依存性の処理をしています: libfreebl3.so のパッケージ: glibc-2.17-260.el7_6.4.i686
---> パッケージ glibc.x86_64 0:2.17-260.el7_6.4 を 更新
--> トランザクションの確認を実行しています。
---> パッケージ nss-softokn-freebl.i686 0:3.36.0-5.el7_5 を インストール
--> 依存性解決を終了しました。
エラー:  Multilib version problems found. This often means that the root
        cause is something else and multilib version checking is just
        pointing out that there is a problem. Eg.:

          1. You have an upgrade for glibc which is missing some
             dependency that another package requires. Yum is trying to
             solve this by installing an older version of glibc of the
             different architecture. If you exclude the bad architecture
             yum will tell you what the root cause is (which package
             requires what). You can try redoing the upgrade with
             --exclude glibc.otherarch ... this should give you an error
             message showing the root cause of the problem.

          2. You have multiple architectures of glibc installed, but
             yum can only see an upgrade for one of those architectures.
             If you don't want/need both architectures anymore then you
             can remove the one with the missing update and everything
             will work.

          3. You have duplicate versions of glibc installed already.
             You can use "yum check" to get yum show these errors.

        ...you can also use --setopt=protected_multilib=false to remove
        this checking, however this is almost never the correct thing to
        do as something else is very likely to go wrong (often causing
        much more problems).

        Protected multilib versions: glibc-2.17-260.el7_6.5.x86_64 != glibc-2.17-260.el7_6.4.i686

/var/log/yum.log を確認しても、更新がインストールされたログは記録されていない。

パッケージを確認してみると、

# rpm -qa | grep glibc-common
glibc-common-2.17-260.el7_6.4.x86_64
glibc-common-2.17-260.el7_6.5.x86_64

のように、glibc-common が2つ入った(?)状態になっている。

よりによって glibc とは・・・。


重複したパッケージの整理を試みる。
(package-cleanup コマンドは、yum-utils パッケージに入っている)

# package-cleanup --cleandupes
読み込んだプラグイン:fastestmirror
Not removing glibc-common-2.17-260.el7_6.4.x86_64 because it is required by 1 installed package
No duplicates to remove
Warning: Some duplicates were not removed because they are required by installed packages.
You can try --cleandupes with --removenewestdupes, or review them with --dupes and remove manually.

オプションが足りないらしいので、追加してもう一度。
新しいバージョンのほうだけ削除されそうに見えるので、y を押して続行。

# package-cleanup --cleandupes --removenewestdupes
読み込んだプラグイン:fastestmirror
読み込んだプラグイン:fastestmirror
--> トランザクションの確認を実行しています。
---> パッケージ glibc-common.x86_64 0:2.17-260.el7_6.5 を 削除
--> 依存性解決を終了しました。

依存性を解決しました

=========================================================================================================
 Package                  アーキテクチャー        バージョン              リポジトリー        容量
=========================================================================================================
削除中:
 glibc-common             x86_64                  2.17-260.el7_6.5        installed           115 M

トランザクションの要約
=========================================================================================================
削除  1 パッケージ

インストール容量: 115 M
上記の処理を行います。よろしいでしょうか? [y/N]y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
警告: RPMDB は yum 以外で変更されました。
  削除中                  : glibc-common-2.17-260.el7_6.5.x86_64          
                                                                          
                                                             1/1
  検証中                  : glibc-common-2.17-260.el7_6.5.x86_64          
                                                                          
                                                             1/1

削除しました:
  glibc-common.x86_64 0:2.17-260.el7_6.5

完了しました!

パッケージの確認

# rpm -qa | grep glibc-common
glibc-common-2.17-260.el7_6.4.x86_64

1つになっていて良さげ。

yum update で再び更新すると問題なくアップデートされた。

yum.log を見てみると、

# tail /var/log/yum.log
・・・
 511 08:58:42 Erased: glibc-common-2.17-260.el7_6.5.x86_64
May 11 08:59:52 Updated: glibc-common-2.17-260.el7_6.5.x86_64
May 11 08:59:54 Updated: glibc-2.17-260.el7_6.5.x86_64

という感じで大丈夫そうに見える。

date コマンドで令和から紀元前まで

Windows元号関連で色々と話題なっているなか、Linuxではどうなっているか?

glibc をupdateすると、新元号にも対応するとの事で、前後の結果をメモしておく。

元号に対応前

$ LC_ALL=ja_JP.utf8 date +%EY -d 20190501
平成31

yum updateした後

# grep glibc /var/log/yum.log
Apr 13 08:08:41 Updated: glibc-common-2.17-260.el7_6.4.x86_64
Apr 13 08:08:43 Updated: glibc-2.17-260.el7_6.4.x86_64
Apr 13 08:09:21 Updated: glibc-headers-2.17-260.el7_6.4.x86_64
Apr 13 08:09:21 Updated: glibc-devel-2.17-260.el7_6.4.x86_64
Apr 13 08:09:30 Updated: glibc-2.17-260.el7_6.4.i686

元号に対応後

$ date +%EY -d 20190501
令和元年

おぉ、令和になった!


%EY オプションを使う事があまりないので、他の引数も試してみる。

$ date +%EY -d 00010101
西暦1

うっかり桁数を間違えたら、、、紀元前(´・ω・`)?

$ date +%EY -d 0001101
紀元前1

少し変えてみたら平成に。

$ date +%EY -d 000110
平成12

WordPress で PHPのバージョンに関する警告が出る、そしてデータベース接続確立エラー

WordPress 5.1 に更新したせいか、管理画面のダッシュボードでPHPのバージョンに関する警告が出るようになった。

f:id:savakan:20190316132118p:plain

!PHPの更新が必要です
サイトが安全ではいバージョンのPHPを実行していることを検出しました。

PHPとは何ですか?サイトにどう影響しますか?

PHPはWordPressの構築およびメンテナンスに使用されるプログラミング言語です。
新しいバージョンのPHPはより高速かつ安全であるため、更新することでサイトのパフォーマンスに良い影響を与えます。

PHPの更新についてさらに詳しく

公式としては、現行の動作要件は以下のようになっている。

wordpress.org


古いPHP(5.2.4)でも動作するが、前述のような警告が出た上に、WordPressが最低限の動作要件を引き上げるとなると、困るケースがありそう。

例えば、
 CentOS 6:PHP 5.3+MySQL 5.1
 CentOS 7:PHP 5.4+MariaDB 5.5
など、RHEL系で標準リポジトリを使っている場合。

Remiリポジトリへ切り替えたり、ソースからビルドしたPHPの環境が必要になる。


WordPress の動作要件の遷移については、調べた方がいるのでリンク。

blog.hinaloe.net



なお、PHP 7系となると、PHPの古いMySQL関数(mysql)が廃止されている。

従って、古いMySQL関数を使ったプラグインがあれば、動作しなくなる。

php.net



PHP Compatibility Checker」というプラグインで、各PHPバージョンにおけるプラグインの互換性を検証できるので、事前にチェックしておくと良い。



ソースからビルドしたPHP 7.x へ切り替えた際、環境によってはデータベース接続確立エラーが発生する。

f:id:savakan:20190316132415p:plain

データベース接続確立エラー

これは、wp-config.php ファイルのユーザー名とパスワードが正しくないか、あるいはlocalhostのデータベースサーバーに接続できないかのどちらかを意味します。
ホスティングサービスのデータベースサーバーがダウンしているかもしれません。
 ・ユーザー名とパスワードに間違いはありませんか?
 ・正しいホスト名を入力しましたか?
 ・データベースサーバーは稼働していますか?

こうした用途が何を意味しているのか分からない場合は、ホスティングサービスに連絡するべきでしょう。
助けが必要であれば、いつでもWordPressサポートフォーラムを訪れることができます。

wp-config.php にて、ユーザ名とパスワードを変更していないなら、データベースへの接続方法の指定に問題がある。

WordPressをDEBUGモード有効で動作させると、画面に次のようなメッセージが表示される。

Warning: mysqli_real_connect(): (HY000/2002): No such file or directory 
in /wordpress-path/wp-includes/wp-db.php on line 1612

No such file or directory

該当ファイルを見ると、、、

1611  if ( WP_DEBUG ) {
1612      mysqli_real_connect( $this->dbh, $host, $this->dbuser, $this->dbpassword, null, $port, $socket, $client_flags );
1613  } else {
1614      @mysqli_real_connect( $this->dbh, $host, $this->dbuser, $this->dbpassword, null, $port, $socket, $client_flags );
1615  }


「No such file or directory」というメッセージからは判断するに、ソケットファイルが見つからないものかもしれない。


回避方法として、2つ挙げておく。

回避方法1

接続ホスト名を localhost127.0.0.1 に変更する。

/** MySQL のホスト名 */
define( 'DB_HOST', 'localhost' );
 ↓
/** MySQL のホスト名 */
define( 'DB_HOST', '127.0.0.1' );

レンタルサーバでは、こちらの方法になると思われる。

回避方法2

php.ini の mysqli.default_socket にソケットのパスを設定する。

パスを調べるには、

# ps aux | grep mariadb
mysql     4984  0.0  0.7 1178220 31860 ?       Sl    204  33:13 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock

など。

この場合、/var/lib/mysql/mysql.sock がソケットのパス。

php.ini へ設定を記載する。

mysqli.default_socket =
 ↓
mysqli.default_socket = /var/lib/mysql/mysql.sock

リモートデスクトップの「ローカル セキュリティ機関にアクセスできません」が2月の月例パッチで修正された

先月書いた以下の件の続き。

shobon.hatenablog.com

2月の月例パッチを適用したら、解決しました。

パッチ適用後は、再起動が必要。