web-dev-qa-db-ja.com

/etc/security/limits.d/でスタックの深さの制限を変更し、その変更を起動時にサービスに適用する方法

私のシステム

  • Ubuntu 14.04.5(x86_64)サーバーのシリーズ、更新されたまま
  • 私のアプリケーションでは、postgresのスタック深度を増やす必要がありました
  • / etc/security/limits.d/myapplication.confにファイルを作成しました
  • myapplication.confファイルには次の行があります:* - stack 131072
  • 131072KB == 128MBであることに注意してください
  • このmyapplication.confファイルを作成すると、my ulimit -s 戻り値: 131072
  • 次に、/ etc/postgresql/9.3/main/postgresql.confファイルを編集し、次の行を追加しました:max_stack_depth = 126MB


私の問題

起動中に、次のメッセージが表示されます。

 * The PostgreSQL server failed to start. Please check the log output:
2018-01-24 09:27:53 MST LOG:  invalid value for parameter "max_stack_depth": 129024
2018-01-24 09:27:53 MST DETAIL:  "max_stack_depth" must not exceed 7680kB.
2018-01-24 09:27:53 MST HINT:  Increase the platform's stack depth limit via "ulimit -s" or local equivalent.
2018-01-24 09:27:53 MST FATAL:  configuration file "/etc/postgresql/9.3/main/postgresql.conf" contains errors
 * Starting Mount network filesystems                                    [ OK ]
 * Starting PostgreSQL 9.3 database server        * Stopping Mount networ[ OK ]systems
                                                                                             [fail] 

次に、データベースに依存しているため、アプリケーションサービスが失敗します。起動後、postgresサービスを開始すると、問題ありません。

dev@wipn:~$ Sudo service postgresql start
 * Starting PostgreSQL 9.3 database server                                                                                                                                                                                                                                                                             [ OK ] 
dev@wipn:~$ 

私の推測では、/ etc/security/limits.d/myapplication.confの効果は、システムの起動後の段階でのみ適用されると思いますpostgresを開始しようとします。したがって、おそらく明らかな解決策は、postgresを開始したときに変更することです。それは問題なく、それを処理できます。


私の質問

サーバーに最小限の変更を加えるだけで済むように、カーネルのスタック深度を変更する方法は何ですか?

出来るだけきれいなものが欲しいです。アップグレードに耐え、できれば他のディストリビューションにも適用できるようにしたいと思います。私はAnsibleプレイを通じて自分のものを管理しているので、このために1つのクリーンなプレイを作成したいと思います。

それは単に私のサービスの開始順序を変更することが最善の解決策である場合です。他の適切なオプションを知っている人はいますか?


私が試したこと

これが私が試したが成功しなかったもののリストです。

/ etc/security/limits.d/myapplication.conf

  • postgres - stack 131072
  • * - stack 131072 root - stack 131072
6
James T Snell

誰かが私にきれいな解決策を与えることができるまで、これは私が思いついたものであり、それはうんざりです。私はそれを私の質問への答えとして受け入れませんが、ここにあります(ギャグ)。少なくともそれは機能します。


背景

/ etc/security/limits。*への変更はサービスに影響を与えることはなく、シェルから実行されるものに影響を与えるようです。したがって、そのような場合、/ etc/security/limits。*での変更はまったく意味がありません。 (ここで口論を挿入)。 / etc/security/limits.d/myapplication.confを削除しました。


postgresのスタックサイズ制限の変更

これはガベージソリューションです。私はそれが嫌いです。

「/usr/share/postgresql-common/init.d-functions」、具体的にはstart()関数を編集して次のように表示しました:

...
# start all clusters of version $1
# output according to Debian Policy for init scripts
start() {
    ulimit -s 131072    #JTS: To avoid Issue #XYZ 

    # create socket directory
    if [ -d /var/run/postgresql ]; then
        chmod 2775 /var/run/postgresql
    else
    ...

明らかに、私はulimit行を追加しました。このファイルを更新することで永続的に変更されることを期待しているため、このファイルを変更するのは嫌です。少なくとも、それを強制するためのAnsibleルールがあります。


My Ansibleソリューション

この構成変更を強制するために作成したAnsibleタスクは次のとおりです。

- blockinfile:
    dest: /usr/share/postgresql-common/init.d-functions
    block: |
          ulimit -s 131072
    backup: yes
    insertafter: '^start\(\) \{'
    state: present

このAnsibleタスクにより、関数は次のようになります。

...
# start all clusters of version $1
# output according to Debian Policy for init scripts
start() {
# BEGIN ANSIBLE MANAGED BLOCK
ulimit -s 131072
# END ANSIBLE MANAGED BLOCK
    # create socket directory
    if [ -d /var/run/postgresql ]; then
       ...


注:Upstart Services Ignore/ etc/security/limits

/ etc/security/limits。*は、Ubuntu14.04が使用するUpstartによって無視されているようです。私のアプリケーションサービスは実際にupstartを使用しており、次のようなupstartの行を挿入できます。

limit stack <softlimit> <hardlimit>

Ubuntuは14.04以降にsystemdに切り替えたため、この新興のtid-bitは無関係にフェードインします。

14.04では、postgresqlはupstartによって管理されていないため、これは私の質問には関係ありません。

1
James T Snell

だから私は同じ問題を抱えてここに来ました、そしておそらくあなたは私がしたことをもっと受け入れられると思うでしょう:私のPostgreSQLはsystemdサービスとして実行されます。サービスファイルでは、OSの観点からスタックを無制限にしています。

[Service]
...
LimitSTACK=infinity

次に、postgresql.confで、次のように設定します。

max_stack_depth = 100MB

これにより、障害のある再帰クエリを1秒ではなく数分間実行できました。

ご質問から1。5年後のイベントにお役に立てば幸いです。

(Fedora 25上のPostgresql 9.5.10)

0
E. Hermsen