ノードの再起動後の/dev/ shm権限の変更–オタク日記

共有メモリは、プロセス間で状態を共有する方法です。 共有メモリは、その名前が示すように、プロセス間でデータを「共有」する方法です。 どちらのプロセスも「共有」と同じメモリ領域を定義しており、書き込むだけで情報を交換できます。 これは、プロセス間でネットワークまたはパイプベースのメッセージを送信する代替手段よりも（以前は、現在でも多少高速です）高速です。

メモリをデータを保存する手段と見なす場合、ファイルシステム上のファイルは共有メモリ（つまり共有ファイル）と見なすことができます。 共有メモリを説明することは困難です。 それは1つのプロセスに属していますか？ 両方？ ない？ 複数のプロセスに属するメモリを単純に合計すると、大幅に「過大評価」されます。

名前が示すように、共有（仮想）メモリとは、複数のプロセスで共有され、複数のプログラムで同時に使用できる仮想メモリを指します。 仮想メモリを使用すると、プロセスに個別の（仮想）アドレス空間を設定できますが、メモリを共有するプロセスが必要になる場合があります。 共有メモリ（SHM）は、プロセス間通信（IPC）の別の方法であり、複数のプロセスが1つのメモリチャンクを共有して通信します。

共有メモリは、プロセスが大量のデータを相互に渡すための最速の方法を提供します。 / dev / shmは、従来の共有メモリの概念の実装に他なりません。 これは、プログラム間でデータを渡すための効率的な手段です。 1つのプログラムがメモリ部分を作成し、他のプロセス（許可されている場合）がアクセスできるようにします。 これにより、Linuxでの処理が高速化されます。

問題

サーバーを再起動するたびに、/ dev/shm権限が変更されます。

$ ls -alrt /dev/ | grep shm
drwxr-xr-t. 2 root root 60 jul 6 11:14 shm 

元の許可（1777）：

# ls -ld /dev/shm
drwxrwxrwt. 2 root root 200 Aug 20 03:44 /dev/shm

既存の許可（1754）：

$ ls -alrt /dev/ | grep shm
drwxr-xr-t. 2 root root 60 jul 6 11:14 shm

ソリューション

問題の原因は、既存のinitscriptsパッケージにあります [initscripts-9.49.37-1.0.1.el7_3.1.x86_64]。

回避策

ステップ1：サービスをマスクします（rhel-import-state）：

# systemctl mask rhel-import-state

ステップ2：サービスの状態を確認してください。 以下のようになります。

rhel-import-state.service
  Loaded: masked (/dev/null; bad) <<  Active: active (exited) since Fri 2017-07-21 18:28:05 EDT; 2 weeks 3 days ago
 Main PID: 600 (code=exited, status=0/SUCCESS)
  CGroup: /system.slice/rhel-import-state.service

ステップ3：マシンを再起動し、同じ問題が再発するかどうかを確認します。

ノート：これは回避策のアクションプランです。 永続的な解決策を得るには、initscriptsパッケージのバージョンを9.49.39-1.0.1にアップグレードします。これは、CentOS/RHEL7アップデート4に含まれています。

変更を元に戻す

以下のコマンドを実行してマスクされたサービスのマスクを解除することにより、変更を元に戻すこともできます。

# systemctl unmask rhel-import-state.service
# systemctl status rhel-import-state.service