専用サーバーのローカルネットワーク経由で他のユーザーのサーバーからアクセスされる

ErogameScapeで借用している専用サーバーの1つには、ネットワークポートが2つあります。
1つはグローバルIPアドレスが設定されており、もう1つはローカルIPアドレスが設定されています。
ローカルIPアドレスが設定されているのは、サーバーの監視用です。

毎日PostgreSQLのログを確認しているのですが、以下のようなログが記録されていました。

no pg_hba.conf entry for host "172.22.182.49", user "postgres", database "postgres", no encryption

あれ?ローカルIPアドレスだ。


ErogameScapeの専用サーバーはインターネット側からPostgreSQLにアクセスできるようにポートを開けているため、不正アクセスを試みるIPアドレスからの接続がログに記録されることはよくあります。
しかし、ローカルネットワークからのアクセスは初めて見ました。

誤って接続を試みてしまったのか、意図的に行ったのかは不明ですが、nftablesでブロックしました。

必要なサービスだけを起動し、必要な接続元からのアクセスだけを許可するという原則を守っていれば問題はないのですが、設定を確認したところ、自宅サーバーで運用していたころの設定である「192.168.0.0/24」からの接続許可が残っていました。
ローカルネットワークについての設定も気をつけなければならないと感じました。

PostgreSQLで実行中のトランザクションを強制的に解放する

FANZA同人の男性向け作品一覧の大幅割引作品の検索サイトは、以下のようなSQLでデータを流し込んでいます。
PREPARE fanza_doujin_sales_plan (
    text
  , text
  , integer
  , text
  , integer
  , integer
  , text
  , text
  , integer
  , timestamp with time zone
  , date
  , integer
) AS
INSERT INTO fanza_doujin_sales (
    cid
  , title
  , maker_id
  , maker_name
  , price
  , discount_rate
  , img
  , genre
  , number_of_sales
  , campaign_due_date
  , delivery_start_date
  , number_of_pages
) VALUES ( $1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12 )
ON CONFLICT (cid, campaign_due_date)
DO UPDATE SET price = $5, discount_rate = $6
RETURNING cid, title, (xmax = 0) AS inserted;
;
EXECUTE fanza_doujin_sales_plan(
    'd_243614'
  , '使用済みの姪っ子を俺の女に染めるまで'
  , 75096
  , 'あまいちご'
  , 192
  , 75
  , 'https://doujin-assets.dmm.co.jp/digital/comic/d_243614/d_243614pl.jpg'
  , 'コミック'
  , 85465
  , '2023/10/16'
  , '2022/09/30'
  , 24
);
ある日、BEGINを実行した後に上記SQLを流し込んでいる最中にターミナルのセッションが切れてしまいました。
そこで新たにターミナルを立ち上げて上記SQLを流し込もうとしたところトランザクションがロールバックされていないため、テーブルにロックが入ってSQLが実行待ちになってしまいました。
あー、ロックを強制的に外さないと駄目かなあ…、そもそもロックの確認方法を忘れている…といろいろ調べているうちに自然にロックが解除され(セッションが切れてから一定時間立つとロールバックされるのかな…)実行待ち状態は解除されました。

ロックの確認とロックしているプロセスの解放方法の確認に時間がかかったのでメモしておきます。

ロックの確認方法
SELECT
    l.relation::regclass,
    l.locktype,
    l.mode,
    l.granted,
    a.pid,
    a.query
FROM
    pg_locks l
JOIN
    pg_stat_activity a
ON
    l.pid = a.pid
WHERE
    l.relation = 'fanza_doujin_sales'::regclass;
ap2=# SELECT
    l.relation::regclass,
    l.locktype,
    l.mode,
    l.granted,
    a.pid,
    a.query
FROM
    pg_locks l
JOIN
    pg_stat_activity a
ON
    l.pid = a.pid
WHERE
    l.relation = 'fanza_doujin_sales'::regclass;
      relation      | locktype |       mode       | granted |   pid   |                                    query
--------------------+----------+------------------+---------+---------+-----------------------------------------------------------------------------
 fanza_doujin_sales | relation | RowExclusiveLock | t       | 3190875 | EXECUTE fanza_doujin_sales_plan(                                           +
                    |          |                  |         |         |     'd_243614'                                                             +
                    |          |                  |         |         |   , '使用済みの姪っ子を俺の女に染めるまで'                                 +
                    |          |                  |         |         |   , 75096                                                                  +
                    |          |                  |         |         |   , 'あまいちご'                                                           +
                    |          |                  |         |         |   , 192                                                                    +
                    |          |                  |         |         |   , 75                                                                     +
                    |          |                  |         |         |   , 'https://doujin-assets.dmm.co.jp/digital/comic/d_243614/d_243614pl.jpg'+
                    |          |                  |         |         |   , 'コミック'                                                             +
                    |          |                  |         |         |   , 85465                                                                  +
                    |          |                  |         |         |   , '2023/10/16'                                                           +
                    |          |                  |         |         |   , '2022/09/30'                                                           +
                    |          |                  |         |         |   , 24                                                                     +
                    |          |                  |         |         | );
(1 row)
プロセスの強制終了
ap2=# select pg_terminate_backend(3190875) ;
 pg_terminate_backend
----------------------
 t
(1 row)

ap2=# SELECT
    l.relation::regclass,
    l.locktype,
    l.mode,
    l.granted,
    a.pid,
    a.query
FROM
    pg_locks l
JOIN
    pg_stat_activity a
ON
    l.pid = a.pid
WHERE
    l.relation = 'fanza_doujin_sales'::regclass;
 relation | locktype | mode | granted | pid | query
----------+----------+------+---------+-----+-------
(0 rows)
pg_cancel_backendだとプロセスを殺すことができませんでした。
ap2=# select pg_cancel_backend(3191875) ;
 pg_cancel_backend
-------------------
 t
(1 row)

ap2=# SELECT
    l.relation::regclass,
    l.locktype,
    l.mode,
    l.granted,
    a.pid,
    a.query
FROM
    pg_locks l
JOIN
    pg_stat_activity a
ON
    l.pid = a.pid
WHERE
    l.relation = 'fanza_doujin_sales'::regclass;
      relation      | locktype |       mode       | granted |   pid   |                                    query
--------------------+----------+------------------+---------+---------+-----------------------------------------------------------------------------
 fanza_doujin_sales | relation | RowExclusiveLock | t       | 3191875 | EXECUTE fanza_doujin_sales_plan(                                           +
                    |          |                  |         |         |     'd_243614'                                                             +
                    |          |                  |         |         |   , '使用済みの姪っ子を俺の女に染めるまで'                                 +
                    |          |                  |         |         |   , 75096                                                                  +
                    |          |                  |         |         |   , 'あまいちご'                                                           +
                    |          |                  |         |         |   , 192                                                                    +
                    |          |                  |         |         |   , 75                                                                     +
                    |          |                  |         |         |   , 'https://doujin-assets.dmm.co.jp/digital/comic/d_243614/d_243614pl.jpg'+
                    |          |                  |         |         |   , 'コミック'                                                             +
                    |          |                  |         |         |   , 85465                                                                  +
                    |          |                  |         |         |   , '2023/10/16'                                                           +
                    |          |                  |         |         |   , '2022/09/30'                                                           +
                    |          |                  |         |         |   , 24                                                                     +
                    |          |                  |         |         | );
(1 row)

[感想]テキストマイニングで探るエロゲー批評の昔と今

C102に参加された皆様お疲れさまでした。
参加してみてコロナ前の活気が戻っているんじゃないかなあ…と思いました。コミケに行くと、「ああ、自分はこのままでいいんだな」、って思えます。

コミケで本を2冊買ったのですが、そのうちの1冊が「テキストマイニングで探るエロゲー批評の昔と今」です。本書のサンプルと購入できるところは以下のとおりです。
ErogameScapeを作った理由の1つに、このような本が作りたい!というモチベーションがあったのですが、すでにエロゲーをまったくやっていない…というかErogameScapeを作ってから3年後にはエロゲーをやらなくなっているので、2003年までのことしか分からない自分には夢物語でして、ErogameScapeのデータを使って統計本を出して頂けるのは感謝でしかないです。

さて、「テキストマイニングで探るエロゲー批評の昔と今」は2部構成になっています。1部はレビューに関する集計で、メインは各年ごとに、その年に書かれたレビュー数順にゲームが一覧で見られることでしょう。
つばめさんも「ぜひこのランキングを眺めながら同好の士と酒のあてにでもしてください」と書かれていますが、これを見ながらあーだーこーだー話すのは楽しんじゃないでしょうか。
統計って結果を見てどう解釈をするかをあーだーこーだー話すのが楽しいんです、たぶん。自分はそう思います。
ちなみにAIRって、現在、1046件の一言感想が登録されているのですが、2001年には11件、2002年には48件、2003年には122件、2004年には163件の登録になってます。これだけだとまだ3割程度なので、2005年以降現在までで残りの7割の一言感想が登録されたわけで、すごいぞAIR、って思います。

2部はレビューのテキストにでてくる語句をMeCabを使って形態素解析にかけて、どのような言葉が年度ごとに使われているかを分析しています。
MeCabってエロ単語が登録されていないので使えなかった、というのが20年くらい前の自分の認識だったのですが、ちゃんと出来てる!という感想を持ちました。
主成分分析について説明がほとんどないので、思い出すのに時間がかかりましたが、なんとか思い出して、例えば「萌え」という言葉が絶滅危惧種であることが表から分かってすごいなって思います。

本書について、たまのすさんが書いた感想を見つけましたのでURLをはります。
【レビュー?】テキストマイニングで探る エロゲー批評と昔の今【というよりは茶々】

ErogameScapeのデータはどなたでも見られるようになっておりますので、データを使った何かを作成したい!等ございましたら、お気軽に相談ください。
相談いただかなくても大抵エロゲーマーのためのSQLでなんとかなると思いますが…相談頂いた方が早いこともあります、たぶん。

[感想]セガハード戦記

セガハード戦記
奥成洋輔
白夜書房
2023-07-03

自分は、東京に出た時、本屋さんによって、今、どんな本が売られているのかを見るのを楽しみます。
いつも通り本屋さんをブラブラしていたら上記の本が売っていました。
目次を見ましたら、Beepに言及しておりました。
Beep、懐かしい…
自分はかつてメガドライバー※1のはしくれだったのですが、メガドライバーだったら、おそらくBeepメガドライブの読者レースを毎月楽しみに見ていたはず、だと思います。
高得点のゲームに注目するのはもちろんですが、最下位にソード・オブ・ソダンがあるのに安心するみたいな、なんかそんな感じだったと思います。
BeepはBeepメガドライブの前身の雑誌でして、本書はBeepに10ページも割いて説明がされていて、自分が当時知らなかったBeepの様子が書かれていて、なんと今、noteでBeep21として記事が連載されているそうで、マジか!と思いました。
ということで、いつもは「いつかは買って読みたい本リスト」に追加して買わないのですが、今回はそのままレジへ向かって帰途でセガハード戦記を読むことになりました。

批評空間はその前身としてエロゲー評価統計情報というサイトがありました。
2000年は、レビューサイトがいっぱいありまして、エロゲを買うのにレビューサイトを全部回らないと情報が集まらない!※2という状態でした。
「自分でレビューサイトを巡回してつけられている評価を100点満点に換算して集計し掲載する」というサイトを作ったりまして、それがエロゲー評価統計情報でした。Excelにちまちまとデータを蓄積して計算していました。
当時のデータを見つけたので画像をはっておきます。レビューサイト名が懐かしい…
エロゲー評価統計情報

Beepメガドライブの愛読者だった私は、エロゲーにもBeepメガドライブのような読者レースがあればいいのに…と思っていました。そんなわけで他の要因もあったのですが、CinemaScapeのデザインを真似てErogameScapeを作りました。
Beepメガドライブがなければ、ErogameScapeがなかったかもしれない…は言い過ぎかもしれないですが、少なくともErogameScapeの年刊/月刊エロゲー統計表はBeepメガドライブの読者レースみたいのを作りたかったから存在してます。

さて、話を本に戻しまして、この本はSG-1000からドリームキャストまでを扱っています。自分はメガドライブとセガサターンしか実機に触れていないのですが、メガドライブとセガサターンだけで本の半分を占めるので十分楽しめました。
またあれは今でいうと同人誌なのだろうか…高校の文芸部の雑誌にセガサターンとプレイステーションの戦略だったかな…についてを書いていたこともあって、セガサターンとプレイステーションの戦いの様子を読んで、あーそんな感じだったなあ…と感慨深かったです。

メガドライブとサターンで何をやったかなあ…と思い出すと…そんなになくて…1日1回シルフィードをクリアする、1日1回ガンスターヒーローズをクリアする、学校帰りに友達の家※3によってぷよぷよで対戦しまくる、アドバンスド大戦略がいつまでたっても終わらない、ゴールデンアックスを弟と2人でよくやってた、バーチャファイター2はバーチャスティックプロを買ってやってた。ヴァンパイアセイヴァーとサムライスピリッツ 天草降臨もやってた。ルナ ザ・シルバースター、ランドストーカー、ファンタシースター 千年紀の終りに、ルナ エターナルブルーはやったけど内容を覚えてない…そんな感じです。

そんな自分でも本書は楽しめましたので、自分よりどっぷりセガにはまっていた方々は面白く楽しく懐かしく読めると思います。

※1 メガドライバーをぐぐったら、そんな言葉がなかったような感じなのですが…メガドライブを嗜んでいる人のことを当時はメガドライバーと言っていた、はず…

※2 どちらかというと、当時はエロゲを買うためにレビューサイトを回るのではなくて、プレイしたエロゲのレビューを読んでにやにやするためにレビューサイトを回っていたと思います。いや、本当に当時はそれが楽しくてたまらなかったです。AIRの考察とか、もう忘れちゃったけど、いろいろ読んで回ったなあ…

※3 この友達の家にPC9801があり、そこで見たかわいい女の子のCGに心を奪われた結果、エロゲーに傾倒していくことになり、コンシュマーゲームからは足が遠のいていきました。

WARNING: Segmentation Faults in these executables

logwatchの出力に以下の記録がありました。
 --------------------- Kernel Begin ------------------------

 WARNING:  Segmentation Faults in these executables
    pgpool :  1 Time(s)

 1 Time(s): Code: 8b 44 24 38 4c 8b 3c 24 8d 50 ff 49 8b 84 24 80 00 00 00 4c 89 ff 48 8d 70 01 e8 5f f6 ff ff 48 89 c7 48 89 04 24 49 8b 47 70 <48> 8b 00 48 85 c0 0f 84 c5 01 00 00 49 8b 57 78 31 f6 ff d0 48 89

 ---------------------- Kernel End -------------------------
そこでmessagesを確認しました。

/var/log/messagesの出力
 # cat messages-20230602 | grep 21:35
Jun  1 21:35:32 sakura kernel: Code: 8b 44 24 38 4c 8b 3c 24 8d 50 ff 49 8b 84 24 80 00 00 00 4c 89 ff 48 8d 70 01 e8 5f f6 ff ff 48 89 c7 48 89 04 24 49 8b 47 70 <48> 8b 00 48 85 c0 0f 84 c5 01 00 00 49 8b 57 78 31 f6 ff d0 48 89
Jun  1 21:35:32 sakura systemd[1]: Started Process Core Dump (PID 3000525/UID 0).
Jun  1 21:35:33 sakura systemd-coredump[3000526]: Resource limits disable core dumping for process 2998804 (pgpool).
Jun  1 21:35:33 sakura systemd-coredump[3000526]: Process 2998804 (pgpool) of user 26 dumped core.
Jun  1 21:35:33 sakura systemd[1]: systemd-coredump@7-3000525-0.service: Succeeded.
コアダンプを確認します。
# coredumpctl info -1
           PID: 2998804 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Thu 2023-06-01 21:35:32 JST (10h ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(46500) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 2998804 (pgpool) of user 26 dumped core.
「-1」のオプションは直近のコアダンプを確認するというものです。
マニュアルの記述は以下の通りです。
Show information of a single core dump only, instead of listing all known core dumps.
そういえば最近ちょくちょく同じメッセージがでていたので、すべてのコアダンプを確認します。
# coredumpctl info
           PID: 608872 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Wed 2023-05-24 07:37:23 JST (1 weeks 2 days ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(59504) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 608872 (pgpool) of user 26 dumped core.

           PID: 1636000 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Sun 2023-05-28 01:30:35 JST (5 days ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(37008) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 1636000 (pgpool) of user 26 dumped core.

           PID: 1827919 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Sun 2023-05-28 18:42:12 JST (4 days ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(51772) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 1827919 (pgpool) of user 26 dumped core.

           PID: 1950651 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Mon 2023-05-29 03:30:50 JST (4 days ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(43044) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 1950651 (pgpool) of user 26 dumped core.

           PID: 2998804 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Thu 2023-06-01 21:35:32 JST (10h ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(46500) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 2998804 (pgpool) of user 26 dumped core.

前に同じ事象が発生したときは、php-fpmのrestartで回復したので、とりあえずphp-fpmをrestartしました。
# systemctl restart php-fpm.service
コアダンプはgdbで見られるそうなので、見ようとしたところコアダンプがありませんでした…

# coredumpctl gdb -1
           PID: 2998804 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Thu 2023-06-01 21:35:32 JST (10h ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(46500) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 2998804 (pgpool) of user 26 dumped core.

Coredump entry has no core attached (neither internally in the journal nor externally on disk).
ulimitコマンドで確認すると、core file sizeが0でしたので…、unlimitedに変更しました。
# ulimit -a
core file size          (blocks, -c) 0
# ulimit -c unlimited
# ulimit -a
core file size          (blocks, -c) unlimited
また再起動後も設定を有効にするため、以下のように設定しました。
# emacs /etc/security/limits.d/90-core.conf
90-core.confに以下の内容を追加
* soft core unlimited
* hard core unlimited
すべてのユーザー(*)に対してソフトおよびハードの core file size を無制限に設定します。
特定のユーザーだけに適用したい場合、* の代わりにユーザー名を使用します。

次にコアダンプをグローバルに有効にします。
# emacs /etc/sysctl.conf
/etc/sysctl.confに以下の内容を追加
kernel.core_pattern = /coredumpsへのパス/core.%e.%p
fs.suid_dumpable = 2
この設定は、コアダンプファイルのファイル名を設定し、SUIDプログラムでもコアダンプが生成されるようにしています。
設定を反映します。
# sudo sysctl -p
コアダンプを保存するディレクトリが、すべてのユーザーに対して書き込み可能にします。
sudo mkdir -p /coredumpsへのパス
sudo chmod 1777 /coredumpsへのパス
コアダンプが生成されているかどうかをテストするために、クラッシュする簡単なプログラムを作成して実行します。
crash.c
#include <stdlib.h>

int main() {
    abort();
}
コンパイルして実行し、指定したディレクトリにコアダンプファイルが生成されることを確認します。
$ gcc -o crash crash.c
$ ./crash
$ ls -l /var/tmp/core/
total 160
-rw------- 1 ap2 ap2 253952 Jun 15 08:09 core.crash.2340294
2023/06/19 追記
まだコアダンプが生成されませんでした。
#  coredumpctl gdb -1
           PID: 1964404 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Wed 2023-06-14 00:43:50 JST (5 days ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(36308) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 35ca3e38a1bd486194253de42de9c7c7
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 1964404 (pgpool) of user 26 dumped core.

Coredump entry has no core attached (neither internally in the journal nor externally on disk).
pgpoolのプロセスのmax core file sizeを確認したところ、SOFTが0になっていました。
# ps ax | grep pgpool | more
3257315 ?        Ss     0:17 /usr/bin/pgpool -f /etc/pgpool-II/pgpool.conf -n
(以下略)

# prlimit 3257315
RESOURCE   DESCRIPTION                             SOFT      HARD UNITS
AS         address space limit                unlimited unlimited bytes
CORE       max core file size                 unlimited unlimited bytes
(以下略)
pgpoolのソフトリミットをunlimitedに変更します。
# prlimit --pid 3257315 --core=unlimited:unlimited
また、pgpoolのサービスユニットファイルを変更して、LimitCOREをinfinityにしておきます。
まずサービスユニットファイルの場所を確認します。
# systemctl status pgpool.service
● pgpool.service - Pgpool-II
   Loaded: loaded (/usr/lib/systemd/system/pgpool.service; enabled; vendor preset: disabled)
以下の通り設定を追加します。
[Unit]
Description=Pgpool-II
After=syslog.target network.target

[Service]

User=postgres
Group=postgres

EnvironmentFile=-/etc/sysconfig/pgpool

LimitCORE=infinity
ExecStart=/usr/bin/pgpool -f /etc/pgpool-II/pgpool.conf $OPTS
ExecStop=/usr/bin/pgpool -f /etc/pgpool-II/pgpool.conf $STOP_OPTS stop
ExecReload=/usr/bin/pgpool -f /etc/pgpool-II/pgpool.conf reload

[Install]
WantedBy=multi-user.target

2023/07/01追記
事象が再現しましたので、コアダンプを確認しようとしたところ、以下のように出力されました。
# coredumpctl info -1
No match found.
なにか設定にしくじっていると思います…
coredumpctlはsystemdで動く…という表現でいいのかな…のですが、先日の設定のどこかでsystemdと競合する何かを設定してしまっている気がします。
コアダンプファイルを出力するように設定した/var/tmp/core/ディレクトリに、コアダンプファイルが生成されていましたので、とりあえず解析をすることにしました。
# ls -l /var/tmp/core/
-rw------- 1 postgres postgres 154488832 Jun 30 16:59 core.pgpool.3071815
解析方法は初心者のためのコアファイルの解析方法についてを読んで実施しました。
# gdb /usr/bin/pgpool /var/tmp/core/core.pgpool.3071815
GNU gdb (GDB) Red Hat Enterprise Linux 8.2-19.el8
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/pgpool...Reading symbols from /usr/lib/debug/usr/bin/pgpool-4.1.16-1pgdg.rhel8.x86_64.debug...done.
done.

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing
[New LWP 3071815]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `pgpool: ap3 ap2 127.0.0.1(34752) SELECT         '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005589153a0ffc in psql_yylex (yylval_param=yylval_param@entry=0x0, yyscanner=<optimized out>)
    at utils/psqlscan.l:712
712                                                     value = cur_state->callbacks->get_variable(varname,
(gdb) backtrace
#0  0x00005589153a0ffc in psql_yylex (yylval_param=yylval_param@entry=0x0, yyscanner=<optimized out>)
    at utils/psqlscan.l:712
#1  0x00005589153a1a67 in psql_scan (state=state@entry=0x5589164a15d8, query_buf=query_buf@entry=0x7ffd2f6f0250,
    prompt=prompt@entry=0x7ffd2f6f024c) at utils/psqlscan.l:1149
#2  0x0000558915368f0e in multi_statement_query (
    queries=0x558916486de8 "SELECT \r\n\t'\r\n<!-- jQuery library  -->\r\n<script type=\"text/javascript\" src=\"https://code.jquery.com/jquery-1.11.1.min.js\"></script>\r\n<!-- WEB Fonts  -->\r\n<link href=\\'http://fonts.googleapis.com/css?fa"...) at protocol/pool_proto_modules.c:4131
#3  SimpleQuery (frontend=frontend@entry=0x5589164474f8, backend=backend@entry=0x7fb6f19bb9d0, len=107421,
    contents=contents@entry=0x558916486de8 "SELECT \r\n\t'\r\n<!-- jQuery library  -->\r\n<script type=\"text/javascript\" src=\"https://code.jquery.com/jquery-1.11.1.min.js\"></script>\r\n<!-- WEB Fonts  -->\r\n<link href=\\'http://fonts.googleapis.com/css?fa"...) at protocol/pool_proto_modules.c:266
#4  0x000055891536ef30 in ProcessFrontendResponse (frontend=frontend@entry=0x5589164474f8,
    backend=backend@entry=0x7fb6f19bb9d0) at protocol/pool_proto_modules.c:2597
#5  0x0000558915360d6e in read_packets_and_process (frontend=<optimized out>, backend=<optimized out>,
    reset_request=<optimized out>, state=<optimized out>, num_fields=<optimized out>, cont=<optimized out>)
    at protocol/pool_process_query.c:4986
#6  0x00005589153615e3 in pool_process_query (frontend=<optimized out>, backend=<optimized out>,
    reset_request=<optimized out>) at protocol/pool_process_query.c:291
#7  0x000055891535b0f8 in do_child (fds=fds@entry=0x558916445de0) at protocol/child.c:431
#8  0x0000558915332467 in fork_a_child (fds=0x558916445de0, id=57) at main/pgpool_main.c:703
#9  0x0000558915332cd9 in reaper () at main/pgpool_main.c:2855
#10 0x000055891533aa64 in PgpoolMain (discard_status=<optimized out>, clear_memcache_oidmaps=<optimized out>)
    at main/pgpool_main.c:491
#11 0x0000558915330715 in main (argc=<optimized out>, argv=0x7ffd2f700318) at main/main.c:356
(gdb) list
707
708                                             varname = psqlscan_extract_substring(cur_state,
709                                                                                                                      yytext + 1,
710                                                                                                                      yyleng - 1);
711                                             if (cur_state->callbacks->get_variable)
712                                                     value = cur_state->callbacks->get_variable(varname,
713                                                                                                                           PQUOTE_PLAIN,
714                                                                                                                           cur_state->cb_passthrough);
715                                             else
716                                                     value = NULL;
(gdb) info locals
varname = 0x5589164a1668 "first"
value = 
cur_state = 
output_buf = 
yyless_macro_arg = 
yyless_macro_arg = 
yyless_macro_arg = 
yyless_macro_arg = 
yyless_macro_arg = 
yyless_macro_arg = 
yy_current_state = 
yy_cp = 
yy_bp = 0x5589164a7780 ":first"
yy_act = 
yyg = 
backtraceで表示されているSQLを検索して実行したところ、Segmentation faultしました。 このSQLはユーザーさんが作成されたもので、現在のPostgreSQLではそもそも動かないSQLであることを確認したので無効化しました。 なぜSegmentation faultするかの原因を探りたかったのですが、元のSQLが複雑すぎることと、現在のシングルクォーテーションのエスケープ方法ではないエスケープ方法を使っていたので諦めました。
記事検索