【Dovecot 2.0.9】IMAPユーザーの増加に必要なチューニング（コネクションがタイムアウトしてしまう問題への対処、Inotify instance limitの設定）

使用しているdovecotのバージョンは以下の通り。

# dovecot --version

2.0.9

CentOS 6マシンで動作させている。

■DovecotへのIMAP接続でタイムアウトする問題への対処

ThunderbirdをIMAPサーバー（dovecot）のクライアントとして使用していたところ、

Thunderbird側で当IMAPサーバーとのコネクションがタイムアウトする問題が生じた。

これについて、dovecotのログ（/var/log/maillog）を見てみると問題の生じた時刻に次の問題が発生していることがわかった。

dovecot: master: Warning: service(imap-login): process_limit reached, client connections are being dropped

ようするに、dovecot側でのチューニングが甘かったということだ。

この問題に対処するために、次のファイルの項目を編集し、dovecotを再起動した。

# vi /etc/dovecot/conf.d/10-master.conf

service imap-login {

  inet_listener imap {

    #port = 143

  }

  inet_listener imaps {

    #port = 993

    #ssl = yes

  }

  # Number of connections to handle before starting a new process. Typically

  # the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0

  # is faster. <doc/wiki/LoginProcess.txt>

  #service_count = 1

  service_count = 0

  # Number of processes to always keep waiting for more connections.

  #process_min_avail = 0

  # If you set service_count=0, you probably need to grow this.

  #vsz_limit = 64M

  vsz_limit = 256M

}

（説明）

◯ service_count は、ログインを司るサービスにおいて、「performance mode」と、「secure mode」とを切り替えるための値を設定する。

今回は、デフォルトの設定値「1」で、process_limit reached が警告されIMAP接続ができなくなる問題が発生したわけである。

そこで、次のようにパフォーマンスモードに切り替えた。

「0」を設定することによって、パフォーマンスモードとなる。

これにより全てのコネクションが単一インスタンスで処理されるようになる。

（次に挙げる、セキュアモードに比べるとセキュリティーは強くない。）

一方、「1」に設定すれば、セキュアモードとなる。

クライアントからのコネクションは、一つ一つ別々のインスタンスで処理される。

クライアントが切断するまでインスタンスは残り続けるため、上限が存在する。

これを超過すると、process_limit に到達したとの旨が警告され、新しい接続が拒絶される。

今回はこの問題が発生し、クライアントからの接続がタイムアウトしたのだった。

◯ vsz_limit は、万が一メモリリークが発生した場合に備えてプロセスが使用できる上限を設定するものである。これを超過するプロセスはカーネルによってkillされる。

パフォーマンスモード に切り替える場合は、これにより上限を設定しておいたほう良い。

設定値がわからないので、とりあえずデフォルトの64MBの4倍の量とした。

利用環境により設定値を変える必要があるだろう。

そして、dovecotを再起動した。

# service dovecot restart

Stopping Dovecot Imap:                                     [  OK  ]

Starting Dovecot Imap:                                     [  OK  ]

■Inotify instance limitを超過したとの警告への対処

上記のクライアントからの接続不能問題とは関係なさそうだが、

さらに、/var/log/maillogに、他にも次のような警告を見つけた。

dovecot: imap([email protected]): Warning: Inotify instance limit for user 5000 (UID vmail) exceeded, disabling. Increase /proc/sys/fs/inotify/max_user_instances

警告は、/proc/sys/fs/inotify/max_user_instances　の値を増やせと伝えている。

まず値を調べた。

# cat  /proc/sys/fs/inotify/max_user_instances

128

Inotify とはファイルやディレクトリの変更を監視する仕組みである。

何か変更があればカーネルから通知をもらえる。詳細はわからないが、dovecotはこの仕組みを利用しているのだろう。

上記警告は、vmailユーザーに関するInotifyのためのリソースが設定限度を超過したとのことである。

たとえば、vmailユーザーのプロセスにより上流からdovecotはメールを受け取っているとすると、vmailユーザーのプロセスのディスクへの書き込み変更がdovecotに通知される必要があるだろう。

こういう仕組みが機能しない状態になれば何か困ることがあるに違いない。

さて、どのくらい増加させればよいかよくわからない。

設定手順は次のファイルを編集（行の追加）して、読み込ませる。

# vi /etc/sysctl.conf

fs.inotify.max_user_instances = 512

# sysctl -p

そして、dovecotを再起動した。

# service dovecot restart

Stopping Dovecot Imap:                                     [  OK  ]

Starting Dovecot Imap:                                     [  OK  ]

設定値を変更した後、ログの警告が消えるかどうか調べ、値を調整するとよいと思う。

また今度、対処することにしよう。

■

ところで、次のコマンドでは上記以外の警告は見つけられなかった。

# grep Warning /var/log/maillog* | grep -v max_user_instances | grep -v  process_limit | less

＜参考＞

・Dovecot: “Warning: service(imap-login): process_limit reached, client connections are being dropped”

< https://serverfault.com/questions/629612/dovecot-warning-serviceimap-login-process-limit-reached-client-connection > 2021年5月26日

・service(imap-login): process_limit (100) reached (bug?)

< https://talk.plesk.com/threads/service-imap-login-process_limit-100-reached-bug.337563/ > 2021年5月26日

・Dovecot performance tuning

< https://wiki.dovecot.org/PerformanceTuning > 2021年5月26日

・Problem: Dovecot Warns about “Inotify instance limit for user 120 (UID dovemail) exceeded”

< https://help.univention.com/t/problem-dovecot-warns-about-inotify-instance-limit-for-user-120-uid-dovemail-exceeded/13572 > 2021年5月26日

・Warning: Inotify instance limit for user 2000 (UID vmail) exceeded, di

< https://forum.iredmail.org/topic9653-iredmail-support-warning-inotify-instance-limit-for-user-2000-uid-vmail-exceeded-di.html > 2021年5月26日

・Unable to access mail: Warning: Inotify instance limit for user exceeded

< https://support.plesk.com/hc/en-us/articles/115002673113-Unable-to-access-mail-Warning-Inotify-instance-limit-for-user-exceeded > 2021年5月26日

【Linux Ubuntu 18.04.5】ファイル名に含まれている特定の文字列を別の名前に一挙に置換しファイル名変更する方法

次のようなファイル一覧がある。

ファイル名に含まれている「kk」という文字列を、「mm」に置き換えたい。

# ls

RUN_kk.sh           environment_kk_InitialSettings

ReSTART_kk.sh       environment_kk_InitialSettingsSaved

environment_kk_Create  environment_kk_Script

次のようなワンライナーのコマンドを発行することによって、一挙に意図したようにファイル名を変更できた。

（後で挙げるように、renameコマンドを用いると同じことができることがわかった。）

# for f in `ls` ; do mv $f `echo $f | sed -e "s/kk/mm/"` ; done

「`」は、「シフトキー＋＠」で得られる文字で、バックティック、バッククォートと呼ばれる。

（説明）

◯ for f in `ls`

lsコマンドで取得できるファイル一覧に対して繰り返し処理を宣言する。

これにより１ファイルごとにループ処理が行われる。

一回のループ処理につき異なるファイル名が変数fに格納され、do以下の処理がなされる。

do以下において、$fで変数に格納された文字列を取得できる。

◯ mv $f `echo $f | sed -e "s/kk/mm/"`

一見複雑であるが、これは次のような形になっている。

mv $f `変更後のファイル名`

 `echo $f | sed -e "s/kk/mm/"`　で、$fに載ってくるオリジナルファイル名に対して、

ターゲットの文字列（kk）を検索して、新しい文字列（mm）に置き換えたものを出力している。

つまり、mv RUN_kk.sh RUN_mm.sh　のようなコマンドが実行されることになる。

一連の処理がなされた後、次のようにファイル名が一挙に書き換わった。

# ls

RUN_mm.sh           environment_mm_InitialSettings

ReSTART_mm.sh       environment_mm_InitialSettingsSaved

environment_mm_Create  environment_mm_Script

■renameコマンドを使う方法

カレントディレクトリにおいて、ファイルやディレクトリそれぞれの名前に含まれているkkをmmに変更する。

# rename "s/kk/mm/" *

forループ回さなくて良いので簡単だった。

＜参考＞

・【Linuxコマンド】sedで文字列を置換する方法

< https://www.sejuku.net/blog/54595 > 2021年5月25日

・【sed / awk / grep】文字列の置換・抽出・検索と正規表現

< https://qiita.com/shuntaro_tamura/items/e4e942e7186934fae5e7 > 2021年5月25日

【Thunderbird 78.9.0】IMAPサーバーからのメールをキャッシュしないように設定する手順（また、キャッシュ削除手順について）

Linuxデスクトップ環境でThunderbird 78.9.0を、IMAPサーバー（Dovcot）のクライアントとしてセットアップした。

これでIMAPサーバーに保存されているメールがThunderbirdで操作できるようになった。

ところが、ThunderbirdはデフォルトでIMAPサーバーからメールをキャッシュするようになっている。

IMAPクライアント（=Thunderbird）側のディスクを圧迫することが懸念される。

メールデータはオンラインサーバー側にあるのだから、クライアント側ではそれらのデータを保存したくない。

そこでThunderbird側のIMAPアカウントについてデータキャッシュを無効にした。

以下ではキャッシュを無効にする設定方法について説明している。

（ただし、IMAPメールサーバーとThunderbirdクライアント側は高速な回線で接続されている必要がある。私の場合では80Mbps程度で、快適だった。）

キャッシュを無効にすると、Thunderbirdでメール検索を行うとIMAPサーバー側で検索作業が成されるはずである。

検索時に、IMAPサーバー側のCPU使用率が跳ね上がるのを確認できた。

そのため、IMAPサーバー側のサーバーソフトウェアとホストのパフォーマンスについても要件があるだろうと思う。

私の場合、IMAPサーバーは dovecotで、しかもメールボックスへの保存のために dovecot-ldaを用いている。

メールサーバーPostfixを使っている場合、virtualプロセスでメールボックスで保存されるところを、dovecot-ldaを用いている。

dovecot-ldaでメールがメールボックスに保存されると、dovecotサーバー側でキャッシュファイルが更新されるらしい。

このことがIMAPサーバーであるdovecotの検索時のパフォーマンスを高めているのかもしれないが未検証である。

【Dovecot 2.0.9】【Postfix 2.6.6】Postfixのvirtualプロセスの代わりにdovecot-ldaを用いてメールボックスに保存する設定【Linux CentOS 6.7】

ところで、以下で説明する「Thunderbirdではキャッシュしないようにする設定」は、IMAPアカウントを新規登録する際に行った方が良い。

使いはじめると自動的にキャッシュが貯まってしまうからだ。

そして、キャッシュ無効設定の以前にキャッシュされていたメールデータは、自動では消去されないようであるからだ。

推奨方法ではないが、最後にこれらのキャッシュを削除する手順も記載した。

◆設定方法◆

Thunderbird側で、IMAPサーバーのメールをキャッシュしないように設定した。

右上ハンバーガーボタン「≡」から、「アカウント設定」を選択し設定画面を開いた。

設定するアカウントについて、「同期とディスク領域」をクリックし、メッセージの同期設定を開いた。

そして、「このコンピューターのこのアカウントのすべてのフォルダーを保存する(0)」のチックを外した。

すると、「同期設定の変更確認」ウインドウが開くので、「保存」をクリックした。

設定画面を閉じた。

以上でキャッシュを貯め込まない設定が完了した。

◆　既存キャッシュを削除する手順（必要な場合だけ）　◆

上記でキャッシュを無効にした後、既存のキャッシュデータを削除することもできる。

（注意）

この設定は、IMAPサーバーのクライアントとしてThunderbirdを使用している場合に有効である。

POP3などのクライアントとしてThunderbirdを使用している場合は、この設定を行ってはいけない。（データ喪失してしまう！）

また、IMAPサーバーのクライアントとしてThunderbirdを使用している場合でも、下記操作によってデータ喪失などの問題が生じないかどうかテスト環境で試しておいた方が良い。バージョンや環境の違いによって異なる挙動を示すかもしれないからだ。

以下の手順では、Linux デスクトップ環境 MATE Desktop Environment 1.16.2 において、ファイルマネージャー Caja 1.16.6 を用いている。 

ユーザーホームディレクトリを開き、上部の「表示」メニューを開き、「隠しファイルを表示する」を選択した。

そうすると、「.thunderbird」という隠しフォルダが一覧の中に現れるので開いた。

すると、xxxxxxxdefault のような形式のフォルダが表示されるので、

内部に「ImapMail」というフォルダが存在するフォルダの方を開いた。

Thunderbirdが動作中であれば終了した。

（必ず、最初に述べた　「Thunderbird側で、IMAPサーバーのメールをキャッシュしないように設定」を行っておくこと。）

その後に、さきの「ImapMail」を丸ごと削除した。 

再び、Thunderbirdを起動した。

すると、ThunderbirdはIMAPサーバーからメールをリロードしはじめ、メールの量にも依るが間もなく以前のように一覧できるようになった。

＜追伸＞

以前、別の手順で、INBOX.mfsというファイルのみ削除する方法を試したことがある。

すると、添付ファイルが開けなくなる不具合が発生してしまった。

ただ、この不具合は、簡単に修復できた。

Thunderbirdにおいて「受信トレイ」の右クリックメニューでプロパティーをクリックし、

開いたフォルダのプロパティーウインドウの中の、「フォルダーを修復」ボタンを押下するだけで回復した。

＜参考＞

・PDF Attachments are empty

< https://support.mozilla.org/en-US/questions/1189521 > 2021年5月16日