はじめに

ネットワーク状態を調べる際によく使われるコマンドを３点ピックアップし、役割別に記載してみました。

この記事が役に立つ方

• ネットワーク関連のコマンドは良く分からずコピペで済ませてしまっている方

この記事のメリット

• 代表的なネットワーク状態を調べるコマンドの使い分けが出来るようになる

1.ネットワークが接続されているかを調べるping

指定した宛先にパケットを送信し、返ってくるかを確認するため、応答速度を確認することも確認出来る。

パケットが返ってこないということは、ネットワークが正しく接続されていないと判断出来る。

$ ping 宛先ホスト名 or 宛先IPアドレス

止めない限り永遠に続いてしまうので、Ctrl + cで抜ける。

2.ポート番号の確認を行うlsof

list open files の意味。

どのポートを待ち受けているかの確認などで使用。
多機能で、オプションなしで使うと出力が多すぎるためgrepコマンドと併用して絞り込んで使う例が多い。

lsof オプション 対象

以下のような使い方を良く見かける。

-iオプションでネットワークコネクションを出力。
grepでLISTENを指定することで、外部からのアクセスを待ち受けている状態のものだけを抽出する。

lsof -i | grep LISTEN

多機能すぎるコマンドなのでもう一歩踏み込んだ内容はこちらの記事でご確認下さい。

代表的な使い方が端的にまとまっているので、実際にコマンドを試してみると分かりやすかったです。
lsofコマンド入門 - Qiita
@hypermktさんありがとうございます。

3.DNSで名前解決出来るかを確認するnslookup

DNSサーバーに対して名前解決リクエストを送信する。

$ nslookup ホスト名 or IPアドレス

DNS request timed out.などのエラーが出ていれば、DNSの設定がおかしいかDNSが動作していないと判断出来る。

→より詳細に見たいときはdigコマンドを使用。

おわりに

最後まで読んで頂きありがとうございました

より詳細な情報については、下記書籍が大変分かりやすかったのでご一読下さい

おかげでイマイチ実感が沸かないまま使っていたコマンドの理解が進みました。

参考にさせて頂いたサイト（いつもありがとうございます）

• Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版 | 玉川憲, 片山暁雄, 今井雄太, 大澤文孝 | 工学 | Kindleストア | Amazon
• lsofコマンド入門 - Qiita

背景

暗号化

X.509 証明書と公開鍵の基礎

X.509

X.509とはITU-T（国際通信連合（ITU）の電気通信標準化部門）の規格であり、公開鍵暗号方式に基づいて認証局によって発行される公開鍵証明書の標準形式などを定めています。
2018年現在はX.509v3が広く利用されています。

暗号化、署名および認証のX.509 証明書

暗号化ファイルシステム

openssl

コマンド	機能
ca	CA(認証局)の管理
dgst	メッセージダイジェストの計算
genrsa	RSA暗号化方式の秘密鍵を生成
rsa	RSA暗号方式の鍵の管理
X.509	X.509証明書の管理
c_client	SSL/TLSプロトコルを使用したサーバに接続
s_server	SSL/TLSプロトコルを使用してデータを受け取るサーバとして動作
ciphers	使用可能な暗号スイートを一覧表示
verify	X.509証明書の検証

cryptsetup

コマンド	機能
open --type	マッピングとデバイスを指定して暗号化マッピングを作成
close/remove	暗号化マッピングを削除
resize	暗号化マッピングのサイズ変更
luksFormat	デバイスをLUKSパーティションとして初期化
luksOpen	デバイスとLUKSパーティション名を指定しLUKSパーティションを開く
luksClose	LUKSパーティションを閉じる
luksAddKey	LUKSパーティションにパスフレーズを追加
luksKillSlot/luksDelKey	LUKSパーティションに設定したパスフレーズを削除
luksDump	LUKSパーティションの状態表示
isLuks	デバイスがLUKSパーティションの場合0で偽なら0以外

eCryptfs

コマンド	機能
ecryptfs-setup-private	暗号化ディレクトリのセットアップ
ecryptfs-migrate-home	ユーザホームディレクトリの暗号化
ecryptfs-mount-private	暗号化ディレクトリのマウント
ecryptfs-umount-private	暗号化ディレクトリのアンマウント
ecryptfs-unwarp-passphrase	パスフレーズの複合

ディレクトリ構造

$HOME
　├ Private/ ... 復号されたデータを含むマウントポイント
　├ .ecryptfs/
　│　├ Private.mnt ... 暗号化ディレクトリのマウントポイントが書かれたファイル
　│　├ Private.sig ... 暗号化パスフレーズの署名ファイル
　│　├ wrapped-passphrase ... マウント用の暗号化パスフレーズ
　│　├ auto-mount ... 自動マウント用の空ファイル
　│　└ auto-umount ... 自動アンマウント用の空ファイル
　└ .Private/ ... 暗号化されたデータを含むディレクトリ

DNS と暗号化

DNSSEC関連の主要コマンド

コマンド	機能
dnssec-keygen	DNSSECの要であるZSKとKSKを生成する
dnssec-signzone	ゾーンファイルへの署名を行う
dnssec-settime	鍵ファイルのメタデータである時間の表示・変更を行う
dnssec-dsformkey	鍵ファイルから上位サーバに登録するDSレコードを生成する
openssl	TLSAレコードなどの検証を行う
rndc	BINDの制御・設定ツール
delv	BINDの検証・解析ツール

ホストセキュリティ

アクセス制御

ネットワークセキュリティ

はじめに

ここ数年のbtrfsの開発はバグフィックスや性能向上、コードのクリーンアップに重点が置かれており、あまり積極的に新規機能は追加されない傾向があります。しかしながらこの１年は比較的多くの機能追加が見られました。ここではこの1年(kernel v5.0 ~ v5.5)にbtrfsへ追加された機能や現在メーリングリストに投稿されているパッチの内、特に一般ユーザーの目に付きやすいものをまとめます。

v5.0 ~ v5.5の間にマージされた機能(抜粋)

swapfile (v5.0, patch)

一部制限(シングルデバイスでなければならない等)はあるものの、btrfs上でswapfileの利用ができるようになりました。swapfileを用いたhibernationも可能です。実際に使いたい人は別の記事を参考にしてください。

zstd圧縮レベル (v5.1, patch)

透過圧縮でzstdを利用する場合、その圧縮レベルをマウントオプションにより指定することが可能になりました (例: mount <dev> -o compress=zstd:7 /mnt)。
レベルは1~15まで選べ、数字が大きいほど圧縮率が高くなりますが、その代わり圧縮時間とメモリ使用量が増大します。0 or 何も指定しない場合はデフォルトの圧縮レベル(現在は3)が使用されます。レベルによる圧縮率の差は上のパッチのリンクにあるコミットログを参考にしてください。

diskへのwrite直前の一貫性チェックの追加 (v5.2, patch)

ディスクへwriteをする直前にもデータの一貫性に問題が無いかをチェックするコードが追加されました。これによりディスクへ書き込む前にビットフリップ等の検出を行うことができます。

scrubの予想終了時間の表示 (v5.2, patch)

これはユーザーツール(btrfs-progs)のアップデートですが、btrfs scrub statusの出力が改訂され、予想終了時間が表示されるようになりました。

grubによるbtrfs raid5/6およびzstd圧縮のサポート (grub 2.04 patch, patch)

これはgrubのアップデートですが、raid5/6およびzstd透過圧縮を利用したbtrfsからブートできるようになりました(逆に言うと、grubが古い場合にブートファイルにzstd圧縮を利用するとブートできなくなるので注意が必要です)。

3台/4台構成のRAID１ (v5.5, patch)

btrfsでraid1プロファイルを利用する場合、ファイルシステムを構成するディスクの数に関係なくその中のいずれか2台に同一のデータの書き込みが行われます。今回新たに追加されたプロファイルであるraid1c3/raid1c4を使用すると、同一のデータが3台または4台のデバイスへ書き込まれるようになります。
　
mkfs時に新規プロファイルを選択できるようになったほか(例: mkfs.btrfs -m raid1c3 -d raid6 <dev>)、balanceにより現在利用中のファイルシステムの構成を変更することも可能です (例: btrfs balance start -dconvert=raid1c3,profiles=raid1)。なお新しいプロファイルを利用する場合は古いkernelでマウントができなくなります。
　
これは単に冗長性を増やしたい場合に利用することもできますが、想定する利用の一つとしてはデータraid6, メタデータraid1c3の組み合わせで利用するというものです。btrfsのraid5/6には大きな未解決の問題としてwrite holeが存在する(大雑把に言うと停電とディスク故障が重なるとファイルシステムが壊れる可能性がある¹²)というものがあります。これを完全解決するためにはwrite ahead logを実装するなどの必要があるのですが、当面の対策としてメタデータをraid1(データがraid5の場合)あるいはraid1c3(データがraid6の場合)とすることで、メタデータに関してはwrite holeの問題をなくし、ファイルシステムが壊れることを防ぐことができます (当然ながらraid1c3の方がraid6に比べて容量効率は低下しますが、通常メタデータの量はデータの量に比べてずっと小さいため影響は少ないはずです。またファイルはRAID構成に関係なくバックアップしましょう)。

新規チェックサムアルゴリズム (v5.5 patch, patch)

btrfsでは基本的にすべてのメタデータおよびデータにチェックサムがついています。これまでサポートされているチェックサムはcrc32cのみでしたが、新たに3つのアルゴリズムが追加されました:

• xxhash (64bit): crc32cよりも高速
• sha256 (256bit): 暗号学的ハッシュ関数, FIPS準拠だが最も低速
• blake2b-256 (256bit): 暗号学的ハッシュ関数, sha256よりも高速

使用するチェックサムはmkfs時に選択が可能です (例: mkfs.btrfs --csum blake2 <dev>)。なお追加されたチェックサムアルゴリズムを使用する場合は古いkernelでマウントができなくなります。簡単な各チェックサムアルゴリズムの比較はこちらを参考にしてください。

開発中のもの

現在メーリングリストに投稿されている、特に大きな機能追加のパッチとしては以下のようなものがあります(いつ頃マージされるかは不明です)。

非同期discard (patch)

現在同期的に行われているdiscard(trim)が非同期で行われるようになり、性能が向上します。

透過圧縮をバイパスするread/write (patch)

透過圧縮を利用している場合に、(kernelでの圧縮処理をバイパスして)圧縮したデータを直接読み書きすることが可能になります。現状では透過圧縮されたデータをsend/receiveするときに通常のread/write処理を行うため、一度データの展開/圧縮処理を挟む必要があります。この機能を利用することで圧縮されたデータを直接send/receiveできるようになり、処理効率が上がります。

zoned device (patch)

zoned deviceで直接btrfsファイルシステムを利用することができるようになります。zoned deviceには必ずシーケンシャルwriteを行わなければならないという制約があるため、データの上書きをせずにCoWを行うbtrfsとは相性が良いと言えます(zoned deviceについてはWDのページを参照してください)。

fsdax (archive)

fsdaxのサポートを目指すパッチもいくつか投稿されています。しかしながら解決が必要な問題も数多くあり、完全な実現へはまだ時間がかかりそうです。
(そもそもなぜbtrfs(基本CoWする)でfsdax(ページキャッシュを利用せずにデバイス上のデータを直接読み書きする)を利用する必要があるのかという話はありますが、subvolumeやreflink, send/receiveといったbtrfsの機能が使えるようになれば他のFSにない利点が出てくると思います。)

おわりに

ここに挙げたのは一般ユーザーが興味を惹きやすい機能のみです。実際にはこれらよりも遥かに多くのバグフィックス・性能改善・btrfs checkの機能向上・小さな機能追加・メッセージ修正・クリーンアップ等が行われています。気になる方はwikiのchangelogまたはメーリングリストを参照してください。またbtrfsを利用する場合はなるべく最新のkernel, btrfs-progsを利用するほうが良いでしょう。

---

1. raid5/6ではデータおよびパリティを複数台のディスクに分散して書き込みます。write中に停電やシステムクラッシュが発生すると、書き込みが完了していないディスクがある場合はデータとパリティが一致しなくなります。ディスクがすべて揃っている場合は再起動直後にscrubを行うことで一貫性のチェックが可能です。しかしここでディスク障害が重なるとパリティが一致しているかどうかを検証することができず、更にそのままデータの再構成を行うと誤ったデータの復元(= データ破損)となる恐れがあります。仮にファイルシステムのメタデータに対してこの状況が発生するとファイルシステムが壊れ、マウントができなくなります。この問題の解決策の１つはwite ahead logを用意する(ログ領域に書き込みを行った後に実際のデータの書き込みを行い、クラッシュ等が発生した場合は再起動時にログをリプライする)ことですが、データを2重に書き込むことになるため処理速度が大きく犠牲になります。 ↩

2. (更に補足) btrfsはCopy on Writeをしている = データを直接上書きしないため、どの時点までのデータが書かれたかが分かるのでwrite holeはないのではと思う人がいるかもしれません。実はraid5/6を使用した場合はbtrfsでもread-modify-writeによる上書きが起こります。これはbtrfsがCoWをするサイズが必ずしもraidを構成するストライプのサイズと一致しないためです。なお同じくCoWを行うZFSのRAID-Zではwriteサイズに応じてストライプ長を変化させる = 書き込むディスク数を変化させることでread-modify-writeをなくし、常に新規領域にデータを書き込むことでwrite holeの問題を回避しています。 ↩

業務アプリケーション寄りのプログラマであれば一度は書いたであろう営業日判定のプログラム。
今回はBashで書いてみた。わりと汎用的に使えると思うので共有する。

動機

休日は実行しなくても良い夜間バッチがあった（休日に実行しても影響は無い）。
土日は実行しないようにcronでスケジュールしていたが、リソースを節約したいので、できれば祝日も実行させたくない。

日本の祝日情報をどこから貰うか

Google Calendar API を利用しようと思ったが、調べてみると、内閣府ホームページで祝日情報を公開しているようなので、それを使う。

取得方法

curl -sL https://www8.cao.go.jp/chosei/shukujitsu/syukujitsu.csv | iconv -f cp932

URLの中に shukujitsu（ヘボン式）とsyukujitsu（訓令式）が混在しているが気にしないことにする。
将来URLが変わるかもしれないので、Lオプションでリダイレクトを有効にしておく。
iconvで指定する文字コードは sjis より cp932 の方が無難である。

実行結果

国民の祝日・休日月日,国民の祝日・休日名称
1955/1/1,元日
1955/1/15,成人の日
1955/3/21,春分の日
1955/4/29,天皇誕生日
     :
2020/7/24,スポーツの日
2020/8/10,山の日
2020/9/21,敬老の日
2020/9/22,秋分の日
2020/11/3,文化の日
2020/11/23,勤労感謝の日

日付の桁数も揃っていないが気にしないことにする。（2020/1/1は2020/01/01にならないのかという意味）
毎年2月になると官報に翌年の暦要項が掲載されるので、2021年のデータは2020年2月頃に追加されるのだろうか？
なお、このCSVファイルは、そのままExcelのWORKDAY関数に使えるので覚えておくと良い。

ちなみに・・・「スポーツの日」とは「体育の日」の名称が変わったものだが、2020年だけはオリンピック開会式の7月24日に移動するらしい。

シェルスクリプト

祝日情報を、内閣府のサーバに毎回問い合わせるのも忍びないので、ローカルにキャッシュする。
確実に祝日と言える場合のみ、終了ステータスに 0 をセットする。

check_holiday.sh

#!/bin/bash
###############################################################
#   本邦休日判定スクリプト
#   @author  MindWood
#   @param   チェック日付を yyyymmdd で指定。省略すると今日を仮定
#   @return  0       ... 確実に祝日
#            1       ... おそらく平日
#            上記以外 ... エラー
#   @usage   check_holiday.sh || ”平日に必ず実行させるジョブ”
###############################################################

# 引数チェック
if   [ $# -eq 0 ]; then
    CHECK_DATE=$(date +%s)
elif [ $# -eq 1 ]; then
    CHECK_DATE=$(date +%s --date $1) || exit 254
else
    echo 'Invalid argument'
    exit 255
fi

CACHE_PATH=/tmp                          # 内閣府提供の祝日ファイルをキャッシュするディレクトリ
HOLIDAY_FILE=$CACHE_PATH/holiday.csv     # 祝日登録ファイル名
LIMIT=$(date +%s --date '3 months ago')  # ３ヶ月以上前は古い祝日登録ファイルとする

# 祝日登録ファイルが無い、もしくは祝日登録ファイルの更新日が古くなった場合、再取得する
if [ ! -f $HOLIDAY_FILE ] || [ $LIMIT -gt $(date +%s -r $HOLIDAY_FILE) ]; then
    curl -sL https://www8.cao.go.jp/chosei/shukujitsu/syukujitsu.csv | iconv -f cp932 > $HOLIDAY_FILE || exit 250
fi

# 祝日として登録されていれば 0 を返却して終了
grep ^$(date -d @$CHECK_DATE +%Y/%-m/%-d) $HOLIDAY_FILE > /dev/null 2>&1 && exit 0

# 土日なら 0 を返却して終了
DAYOFWEEK=$(date -d @$CHECK_DATE +%u)
[ $DAYOFWEEK -eq 6 ] || [ $DAYOFWEEK -eq 7 ] && exit 0

# 年末年始（12月31日～1月3日）なら 0 を返却して終了
MMDD=$(date -d @$CHECK_DATE +%m%d)
[ $MMDD -eq 1231 ] || [ $MMDD -le 0103 ] && exit 0

# 上記いずれでもなければ平日として終了
exit 1

年末年始を休みとするかは会社によって異なるので適宜修正して欲しい。
2019年12月26日から2020年1月16日までの平日を表示させた結果が次の通りだ。

for (( DATE=20191226; $DATE < 20200116; DATE=$(date -d "$DATE 1 day" +%Y%m%d) )); do
    ./check_holiday.sh $DATE || echo "$DATE は恐らく平日です"
done
20191226 は恐らく平日です
20191227 は恐らく平日です
20191230 は恐らく平日です
20200106 は恐らく平日です
20200107 は恐らく平日です
20200108 は恐らく平日です
20200109 は恐らく平日です
20200110 は恐らく平日です
20200114 は恐らく平日です
20200115 は恐らく平日です

平日なのに祝日と誤判定することは無いが、祝日なのに平日と誤判定することは有り得るため「恐らく」と書いている。
例えば、内閣府のサーバに接続できなければエラー終了となって || の後ろが実行されてしまうが、平日に必ず実行させるジョブがある場合は、こういう作りの方が都合が良い。

cron定義例

業務開始前に実行させるジョブが次のように定義されていたとする。

crontab

00 7 * * * python3 /usr/local/bin/app.py

この場合、次のように追記するだけで、休日は実行しないようにできる。

crontab

00 7 * * * /usr/local/bin/check_holiday.sh || python3 /usr/local/bin/app.py

さいごに

日本の行政機関が提供する Web API に祝日情報も加えていただきたいと思う。

業務アプリケーション寄りのプログラマであれば一度は書いたであろう営業日判定のプログラム。
今回はBashで書いてみた。わりと汎用的に使えると思うので共有する。

開発動機

休日は実行しなくても良い夜間バッチがあった（休日に実行しても影響は無い）。
土日は実行しないようにcronでスケジュールしていたが、リソースを節約したいので、できることなら祝日も実行させたくなかった。

日本の祝日情報をどこから貰うか

Google Calendar API を利用しようと思ったが、調べてみると、内閣府ホームページで祝日情報CSVファイルを公開しているようなので、それを使うことにする。

取得方法

curl -sL https://www8.cao.go.jp/chosei/shukujitsu/syukujitsu.csv | iconv -f cp932

URLの中に shukujitsu（ヘボン式）とsyukujitsu（訓令式）が混在しているが気にしないことにする。
将来URLが移転するかもしれないので、Lオプションでリダイレクトを有効にしておく。
iconvで指定する文字コードは sjis よりも cp932 の方が無難である。

実行結果

国民の祝日・休日月日,国民の祝日・休日名称
1955/1/1,元日
1955/1/15,成人の日
1955/3/21,春分の日
1955/4/29,天皇誕生日
     :
2020/7/24,スポーツの日
2020/8/10,山の日
2020/9/21,敬老の日
2020/9/22,秋分の日
2020/11/3,文化の日
2020/11/23,勤労感謝の日

日付の桁数も揃っていないが気にしないことにする。（2020/1/1は2020/01/01にならないのかという意味）
1955年から2020年までのすべての祝日・振替休日が登録されている。毎年2月になると官報に翌年の暦要項が掲載されるので、2021年のデータは2020年2月頃に追加されるのだろうか？

なお、このCSVファイルは、そのままExcelのWORKDAY関数に使えるので覚えておくと良い。

ちなみに・・・「スポーツの日」とは「体育の日」の名称が変わったものだが、2020年だけはオリンピック開会式の7月24日に移動するらしい。本年は令和対応で来年はオリンピックと特例が続く。

シェルスクリプト

祝日情報を、内閣府のサーバに毎回問い合わせるのも忍びないので、ローカルにキャッシュする。キャッシュが古くなれば自動更新。

確実に祝日と言える場合のみ、終了ステータスに 0 がセットされる。

check_holiday.sh

#!/bin/bash
###############################################################
#   本邦休日判定スクリプト
#   @author  MindWood
#   @param   チェック日付を yyyymmdd で指定。省略すると今日を仮定
#   @return  0       ... 確実に祝日
#            1       ... おそらく平日
#            上記以外 ... エラー
#   @usage   check_holiday.sh || ”平日に必ず実行させるジョブ”
###############################################################

# 引数チェック
if   [ $# -eq 0 ]; then
    CHECK_DATE=$(date +%s)
elif [ $# -eq 1 ]; then
    CHECK_DATE=$(date +%s --date $1) || exit 254
else
    echo 'Invalid argument'
    exit 255
fi

CACHE_PATH=/tmp                          # 内閣府提供の祝日ファイルをキャッシュするディレクトリ
HOLIDAY_FILE=$CACHE_PATH/holiday.csv     # 祝日登録ファイル名
LIMIT=$(date +%s --date '3 months ago')  # ３ヶ月以上前は古い祝日登録ファイルとする

# 祝日登録ファイルが無い、もしくは祝日登録ファイルの更新日が古くなった場合、再取得する
if [ ! -f $HOLIDAY_FILE ] || [ $LIMIT -gt $(date +%s -r $HOLIDAY_FILE) ]; then
    curl -sL https://www8.cao.go.jp/chosei/shukujitsu/syukujitsu.csv | iconv -f cp932 > $HOLIDAY_FILE || exit 250
fi

# 祝日として登録されていれば 0 を返却して終了
grep ^$(date -d @$CHECK_DATE +%Y/%-m/%-d) $HOLIDAY_FILE > /dev/null 2>&1 && exit 0

# 土日なら 0 を返却して終了
DAYOFWEEK=$(date -d @$CHECK_DATE +%u)
[ $DAYOFWEEK -eq 6 ] || [ $DAYOFWEEK -eq 7 ] && exit 0

# 年末年始（12月31日～1月3日）なら 0 を返却して終了
MMDD=$(date -d @$CHECK_DATE +%m%d)
[ $MMDD -eq 1231 ] || [ $MMDD -le 0103 ] && exit 0

# 上記いずれでもなければ平日として終了
exit 1

年末年始を休みとするかは会社によって異なるので、適宜ソースコードを修正して欲しい。
2019年12月26日から2020年1月16日までの平日を表示させた結果を示す。

for (( DATE=20191226; $DATE < 20200116; DATE=$(date -d "$DATE 1 day" +%Y%m%d) )); do
    ./check_holiday.sh $DATE || echo "$DATE は恐らく平日です"
done
20191226 は恐らく平日です
20191227 は恐らく平日です
20191230 は恐らく平日です
20200106 は恐らく平日です
20200107 は恐らく平日です
20200108 は恐らく平日です
20200109 は恐らく平日です
20200110 は恐らく平日です
20200114 は恐らく平日です
20200115 は恐らく平日です

平日なのに祝日と誤判定することは無いが、祝日なのに平日と誤判定することは有り得るため、「恐らく」と自信なげに書いている。
例えば、内閣府のサーバに接続できなければエラー終了となって || の後ろが実行されてしまうが、平日に必ず実行させるジョブがある場合は、むしろ安全で都合が良い。

cron定義例

業務開始前に実行させるジョブが、次のように定義されていたとすると、

crontab

00 7 * * * python3 /usr/local/bin/app.py

次のように追記するだけで、休日は実行しないようにできる。

crontab

00 7 * * * /usr/local/bin/check_holiday.sh || python3 /usr/local/bin/app.py

さいごに

日本の行政機関が提供する Web API に、祝日情報も加えていただきたいと思う。

問題点

ec2イスタンス上で使用できるフォント一覧を確認する際に
ghostscriptで確認しようとしたらこんなエラーが出てgsの起動に失敗した

$ gs
GPL Ghostscript 8.70 (2009-07-31)
Copyright (C) 2009 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GPL Ghostscript 8.70: Cannot open X display `(null)'.
**** Unable to open the initial device, quitting.

対処

-sDEVICE=png256 のオプション追記で実行できた

$ gs -sDEVICE=png256
GPL Ghostscript 8.70 (2009-07-31)
Copyright (C) 2009 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS> (*) { == } 256 string /Font resourceforall
(Adobe-Japan1-UniJISPro-UTF8-V)
(Utopia-Regular)
...

参考

仮想マシンのCentOS7にLaTeXとGhostScriptとImageMagickをインストール

はじめに

　お仕事でcrontabを一時的に修正することがあり、
crontabを直接開いて編集するとミスが出そうで嫌だなと思って安全なやり方を探しました。

使用ツール

• Linux環境(今回はCentOS6を使用）
• teraterm

手順

1. crontabの設定をファイルに出力
2. 1で出力したファイルを編集
3. 2で編集したファイルを使用してcrontabを登録
4. 不要なファイルを削除

やってみよう

1. crontabの設定をファイルに出力

現在設定されているcrontabの内容を、バックアップと編集用に2つのファイルに出力しましょう。

$ crontab -l > /tmp/crontab.org
$ crontab -l > /tmp/crontab.edit

crontab.orgがバックアップ用、crontab.editが編集用です。

2. 1で書き出したファイルを編集

編集用のcrontab.editを編集します。

crontab.edit

$ vi /tmp/crontab.edit

編集し終わったら、現在のcrontabと編集したcrontab.editを比較して、
編集内容が間違っていないか確認しておきましょう。

$ crontab -l | diff /tmp/crontab.edit -

自分が編集した部分がdiffに出ます。

3. 2で編集したファイルを使用してcrontabを登録

編集したcrontab.editを使用して、crontabを登録します。

$ crontab /tmp/crontab.edit

きちんと登録できたか、確認しましょう。

$ crontab -l

編集したとおりになっていますね。

4. 不要なファイルを削除

特に設定を元に戻す必要がなければ、1で出力したファイルを削除してしまいましょう。

$ rm /tmp/crontab.org /tmp/crontab.edit

元に戻したければ、
バックアップ用にとっておいたcrontab.orgの内容をcrontabに登録しなおしてから削除します。

$ crontab /tmp/crontab.org
$ rm /tmp/crontab.org /tmp/crontab.edit

直に設定をいじるのは怖いので、
一度ファイルを出力して、そちらを反映するやり方はほかでも応用できそうですね。

参考サイト

crontabを安全に編集する手順

Fedra 31でCGroup V2 (Unified Cgroup Hierarchy)がデフォルトになり、UbuntuならびにDebianでもCGroup V2をデフォルトにしようとしている。CGroup V2で起動されたLinuxホスト上でLXCを使うと

• RedHatで動かない
• Debianで動かない

などの報告が寄せられているが、その対策を紹介する。

Failed to setup limits for the "devices" controller

ERROR    cgfsng - cgroups/cgfsng.c:cg_legacy_set_data:2415 - Failed to setup limits for the "devices" controller. The controller seems to be unused by "cgfsng" cgroup driver or not enabled on the cgroup hierarchy
ERROR    start - start.c:lxc_spawn:1910 - Failed to setup legacy device cgroup controller limits

のようなメッセージがログファイルに残ってLXCコンテナがスタートしない場合、設定ファイルでCGroup V1のデバイスコントローラーを使う設定がされていて、そのようなコントローラーが使えずにエラーが起きている。

/var/lib/lxc/コンテナ名/configの末尾

lxc.cgroup.devices.allow =
lxc.cgroup.devices.deny =

を追加するとCGroup V1のデバイスコントローラーを用いなくなるため、コンテナが起動するようになる。近い将来にlxc.cgroup2.devicesという設定項目が使えるようになるはずである。

Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted

Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
[!!!!!!] Failed to mount API filesystems.
Exiting PID 1...

というエラーが出た場合、コンテナ内のsystemdがCGroupファイルシステムのマウントに失敗しているため

/var/lib/lxc/コンテナ名/configの末尾

lxc.mount.auto = proc:mixed sys:mixed cgroup:rw:force

を追加するとよい。cgroup:rw:force がポイントである。これはLXCのバージョンが3.04あたりだとこの設定をしても駄目で、3.21あたりだとこれで動くようになる。Ubuntu/Debian の場合新しいバージョンのLXCが https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/daily から入手できる。

ホストLinuxから見てコンテナのCGroupが変な位置に置かれる

CGroupのルートに勝手に階層を作るな という話があるが、コンテナのCGroupが/sys/fs/cgroup直下に作られることがある。それが嫌なら

/var/lib/lxc/コンテナ名/configの末尾

lxc.cgroup.relative = 1

とする。

psコマンドでスレッドID, スレッド数を確認するコマンドメモ
スレッド毎のメモリ、CPUも確認したい。
JVMのスレッドダンプ取ったりする時に使った記憶。

コマンド

$ ps auxww -L
USER       PID   LWP %CPU NLWP %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
shodai     774   774 21.0    1  0.0  17380  1960 tty1     R    00:05   0:00 ps auxww -L

LWP

light weight process ID(軽量プロセスID) or スレッドID

NLWP

プロセス内のlwpの数。