- 投稿日：2020-07-10T23:12:53+09:00
DockerのVolumeについて
EC2(AmazonLinux2)環境にてDockerと戯れているのですが、
気がついたらホストOS上にマウントポイントが増殖していました。。。
そこでVolumeの理解を深める為に色々と試しました。DockerにおけるVOLUMEについて
Dockerリファレンスのdockerfile-VOLUMEの説明より抜粋
VOLUME 命令は指定した名前でマウントポイントを作成し、他のホストやコンテナから外部マウント可能なボリュームにします。
docker runコマンドは、ベース・イメージから指定した場所に、データを保存する場所として新規作成したボリュームを初期化します。これを読んで「コンテナ内にVOLUMEで指定したディレクトリが作成されるんだな」と理解はしましたが、"他のホストやコンテナから外部マウント可能なボリュームにします"という部分は、
コンテナ起動時(run)に-vでホストOS上のディレクトリとの紐付けを可能にするディレクトリを定義するという認識でした。(-vを指定しないと結局のところ永続化はされずデータは破棄される認識)で、色々とVolumeの動作検証をしました。
検証環境
- EC2 (Amazon Linux2)
動作検証
- VOLUME指定の無いイメージ(CentOS)からコンテナ起動してみる(-v, --mount指定なし)
#Volumeは存在しない(コンテナ起動前) [~]docker volume ls DRIVER VOLUME NAME #CentOSイメージからコンテナ起動 [~]docker run --name test_container -dt centos #Volumeは存在しない(コンテナ起動後) docker volume ls DRIVER VOLUME NAME
- VOLUME指定のあるイメージからコンテナ起動してみる(-v, --mount指定なし)
下記dockerfileを使用してCentOSイメージをベースにVolume指定されたイメージを作成して起動してみる#dockerfile(CentOSイメージをベースにVolume=/test_volumeを定義) ARG baseimagetag=latest FROM centos:${baseimagetag} AS baseimage VOLUME /test_volume #dockerイメージ作成 [~]docker build -t centos_mod . #Volumeは存在しない(コンテナ起動前) [~]docker volume ls DRIVER VOLUME NAME #CentOS(改変)イメージからコンテナ起動 [~]docker run --name test_container -dt centos_mod #Volumeが作成される(コンテナ起動後) docker volume ls DRIVER VOLUME NAME local ec1feead17bb87e24d3e2e6db716daf58d12747cbdd0b510fd30f507d7f8308b #VolumeのホストOS上のマウントポイントを確認 #自動的に/var/lib/docker/volumes/配下にマウントポイントが作成されていることがわかる [~]docker inspect ec1feead17bb87e24d3e2e6db716daf58d12747cbdd0b510fd30f507d7f8308b [ { "CreatedAt": "2020-07-10T08:30:00+09:00", "Driver": "local", "Labels": null, "Mountpoint": "/var/lib/docker/volumes/ec1feead17bb87e24d3e2e6db716daf58d12747cbdd0b510fd30f507d7f8308b/_data", "Name": "ec1feead17bb87e24d3e2e6db716daf58d12747cbdd0b510fd30f507d7f8308b", "Options": null, "Scope": "local" } ] #コンテナ停止、削除 [~]docker stop test_container [~]docker rm test_container #Volumeが確認(コンテナ削除後) #ホストOS上のマウントポイントは存在している docker volume ls DRIVER VOLUME NAME local ec1feead17bb87e24d3e2e6db716daf58d12747cbdd0b510fd30f507d7f8308b
- VOLUME指定のあるイメージからコンテナ起動してみる(-v にてVolume名を指定)
#CentOS(改変)イメージからコンテナ起動(ホストOSのマウントポイントを名称(host_mount)で指定 [~]docker run --name test_container -v host_mount:/test_volume -dt centos_mod baf6954e9dbce1dd9ad3ae5c8286e63c01fd39689d79053725ae1800b70ea752 #Volumeが作成される(コンテナ起動後) [~]docker volume ls DRIVER VOLUME NAME local host_mount #VolumeのホストOS上のマウントポイントを確認 #自動的に/var/lib/docker/volumes/配下に-vで指定した名前/_dataでマウントポイントが作成されていることがわかる docker inspect host_mount [ { "CreatedAt": "2020-07-10T22:22:49+09:00", "Driver": "local", "Labels": null, "Mountpoint": "/var/lib/docker/volumes/host_mount/_data", "Name": "host_mount", "Options": null, "Scope": "local" } ]
- VOLUME指定のあるイメージからコンテナ起動してみる(-v にてホストOS上のディレクトリを指定)
#CentOS(改変)イメージからコンテナ起動(ホストOSのマウントポイントをディレクトリ(/test_mount)で指定 [~]docker run --name test_container -v /test_mount:/test_volume -dt centos_mod e5e70d6235dbfe54950e2053f61236c1450d43c0b3aacfa38341e37cfacecaaa #Volumeの確認(コンテナ起動後) #下記コマンドではマウントポイントは表示されない [~]docker volume ls DRIVER VOLUME NAME #コンテナ情報からマウントポイントを確認 [~]docker inspect test_container ##一部抜粋 "Mounts": [ { "Type": "bind", "Source": "/test_mount", "Destination": "/test_volume", "Mode": "", "RW": true, "Propagation": "rprivate" } ],動作検証をして理解したこと
- VOLUMEが定義されたDockerイメージを使用してコンテナ起動すると、 VOLUMEで指定されたディレクトリが永続化領域としてコンテナ内に作成される
- Dockerコンテナ起動時(run)にVOLUMEで指定されたディレクトリに対応するホストOS上のマウントポイント(ディレクトリ)を指定しない場合、ホストOS上のDockerのVolume領域(上記検証では/var/lib/docker/volumes)にマウントポイントが自動で作成される
- 起動時にVOLUMEで指定されたディレクトリに対応するホストOS上のマウントポイント(名称)を指定した場合、無指定時と同様、ホストOS上のDockerのVolume領域にマウントポイントが指定した名称/_dataで作成される
docker volume lsで表示されるマウントポイントはホストOS上のDockerのVolume領域(/var/lib/docker/volumes)に作成されたディレクトリを表示している
※Volume領域以外のディレクトリをマウントポイントに指定した場合は表示されない- ホストOS上に作成されたマウントポイントはコンテナを停止、破棄しても削除されない(永続化領域なんだから当たり前)
※VOLUME指定されたイメージ(MySQLなど)からのコンテナ起動を繰り返していると認識していないディレクトリが山のように発生している可能性も。。)(おまけ)Volume指定されているイメージかを確認する方法
docker inspect <イメージ名>でイメージの情報を表示し、"Volumes": の部分にディレクトリが指定されてるかを確認する例)MySQLコンテナの場合
永続化領域としてコンテナ内に/var/lib/mysqlが定義されている"Volumes": { "/var/lib/mysql": {} },
- 投稿日：2020-07-10T19:19:55+09:00
man systemd 日本語訳
man systemdで表示されるマニュアルの日本語訳。名前
systemd, init - systemd システムとサービスを管理するマネージャー。
概要
/lib/systemd/systemd [OPTIONS...] init [OPTIONS...] {COMMAND}説明
systemd は、 Linux オペレーティングシステム用のシステムとサービスを管理するマネージャーです。
起動時に最初のプロセスとして(PID 1 として)実行すると、ユーザースペースサービスを起動ならびに管理する init システムとして機能します。SysV との互換性のために、 systemd が init として呼び出され、 PID が 1 でない場合、 telinit が実行され、すべてのコマンドライン引数が変更されずに渡されます。
つまり、通常のログインセッションから呼び出された場合、 init と telinit はほぼ同等です。
詳細については、 telinit(8) を参照してください。systemd をシステムインスタンスとして実行すると、 systemd は構成ファイル
system.confおよびsystem.conf.dディレクトリ内のファイルを解釈します。
ユーザーインスタンスとして実行すると、 systemd は構成ファイル user.conf および user.conf.d ディレクトリ内のファイルを解釈します。
詳細については、 systemd-system.conf(5) を参照してください。オプション
次のオプションが理解されます。
--test
起動シーケンスを決定し、ダンプして終了します。
これはデバッグのみに役立つオプションです。--dump-configuration-items
理解されたユニット構成アイテムをダンプします。
これにより、ユニット定義ファイルで認識される構成アイテムの簡潔で完全なリストが出力されます。--dump-bus-properties
公開された bus プロパティをダンプします。
これにより、 dbus に公開されるプロパティの簡潔で完全なリストが出力されます。--unit=
起動時にアクティブにするデフォルトの単位を設定します。
指定しない場合、デフォルトは default.target です。--system, --user
--systemの場合、プロセス ID が 1 でなくても、 systemd がシステムインスタンスを実行するように指示します。
つまり、 systemd は init プロセスとして実行されません。
--userは反対のことを行い、プロセス ID が 1 であってもユーザーインスタンスを実行します。通常、 systemd は開始されたモードを自動的に検出するため、これらのオプションを渡す必要はありません。
これらのオプションはほとんど使用されません。
デバッグ用です。
これは、 systemd が--systemモードで実行されている完全なシステムの起動と管理はサポートされていませんが、 PID は 1 ではありません。
実際には、--systemを明示的に渡すことは--testと組み合わせた場合にのみ役立ちます。--dump-core
クラッシュ時にコアダンプを有効にします。
このスイッチは、ユーザーインスタンスとして実行している場合は効果がありません。
この設定は、ブート時に systemd.dump_core オプションを介してカーネルコマンドラインで有効にすることもできます。
以下を参照してください。--crash-vt = VT
クラッシュ時に特定の仮想コンソール(VT)に切り替えます。
1 から 63 の範囲の正の整数、またはブール値の引数を取ります。
整数が渡された場合、どの VT に切り替えるかを選択します。
yesの場合、 VT カーネルメッセージが書き込まれる場所が選択されます。
noの場合、 VT 切り替えは試行されません。
このスイッチは、ユーザーインスタンスとして実行している場合は効果がありません。
この設定は、ブート時に systemd.crash_chvt オプションを介してカーネルコマンドラインで有効にすることもできます。
以下を参照してください。--crash-shell
クラッシュ時にシェルを実行します。
このスイッチは、ユーザーインスタンスとして実行している場合は効果がありません。
この設定は、ブート時に systemd.crash_shell オプションを介してカーネルコマンドラインで有効にすることもできます。
以下を参照してください。--crash-reboot
クラッシュ時にシステムを自動的に再起動します。
このスイッチは、ユーザーインスタンスとして実行している場合は効果がありません。
この設定は、ブート時に systemd.crash_reboot オプションを介してカーネルコマンドラインで有効にすることもできます。
以下を参照してください。--confirm-spawn
プロセスを生成するときに確認を求めます。
このスイッチは、ユーザーインスタンスとして実行する場合は効果がありません。--show-status=
ブール引数または特別な値
autoを取ります。
on: 起動時とシャットダウン時にコンソールに簡潔なユニットステータス情報が表示されます。off:ステータス情報は表示されません。auto:動作は off に似ていますが、最初のユニットの障害または重大な起動遅延が発生するとすぐに、自動的に on に切り替わります。 このスイッチは、ユーザーインスタンスとして呼び出された場合は無効です。 指定した場合、カーネルコマンドライン設定 systemd.show_status と構成ファイルオプションShowStatus=の両方を上書きします。 systemd-system.conf(5) を参照してください。--log-target=
ログターゲットを設定します。
引数は下記のいずれかである必要があります。
- console
- journal
- kmsg
- journal-or-kmsg
- null
--log-level=
ログレベルを設定します。
引数として、数値のログレベルまたはよく知られている syslog(3) シンボリック名(小文字)を受け入れます。
- emerg
- alert
- crit
- err
- warning
- notice
- info
- debug
--log-color=
重要なログメッセージを強調表示します。
引数はブール値です。
引数を省略するとデフォルトでtrueになります。--log-location=
ログメッセージにコードの場所を含めます。
これは主にデバッグに関連しています。
引数はブール値です。
引数を省略するとデフォルトでtrueになります。--default-standard-output=, --default-standard-error=
すべてのサービスとソケットのデフォルト出力またはエラー出力をそれぞれ設定します。
つまり、StandardOutput=およびStandardError=のデフォルトを制御します(詳細については、 systemd.exec(5) を参照してください)。
引数として以下のいずれかを取ります。
- inherit
- null
- tty
- journal
- journal+console
- syslog
- syslog+console
- kmsg
- kmsg+console
引数を省略すると、
--default-standard-output=はデフォルトでjournalに、--default-standard-error=はinheritに設定されます。--machine-id=
ハードドライブの machine-id セットを上書きします。
ネットワークブートやコンテナに役立ちます。
すべてゼロに設定することはできません。--service-watchdogs=
すべてのサービスウォッチドッグタイムアウトと緊急動作をグローバルに有効 / 無効にします。
この設定は、ブート時にカーネルコマンドラインで systemd.service_watchdogs オプションを介して指定することもできます。
以下を参照してください。
デフォルトはenableです。-h, --help
短いヘルプテキストを表示して終了します。
--version
短いバージョン文字列を出力して終了します。
概要
systemd は、 11 種類の「ユニット」と呼ばれるさまざまなエンティティ間の依存関係システムを提供します。
ユニットは、システムの起動と管理に関連するさまざまなオブジェクトをカプセル化します。
ユニットの大部分はユニット構成ファイルで構成され、その構文と基本的なオプションセットは systemd.unit(5) で説明されていますが、一部は他の構成から自動的にシステムの状態から、または実行時にプログラムで作成されます。
ユニットは、active(ユニットタイプに応じて、 started, bound, plugged in などを意味します。以下を参照)、またはinactive(stopped, unbound, unplugged などを意味します)、およびアクティブ化または非アクティブ化のプロセス、つまり 2 つの状態の間(これらの状態はactivating、deactivationgと呼ばれます)。
特別なfailed状態も利用できます。
これはinactiveと非常に似ており、サービスが何らかの方法で失敗したときに終了します(プロセスが終了時にエラーコードを返すか、クラッシュした、操作がタイムアウトした、または再起動が多すぎる場合)。
この状態になると、後で参照できるように原因がログに記録されます。
さまざまなユニットタイプにいくつかの追加のサブステートがあり、ここで説明する 5 つの一般化されたユニットステートに分類されることに注意してください。次のユニットタイプを使用できます。
デーモンとデーモンを構成するプロセスを開始および制御するサービスユニット。詳細については、 systemd.service(5) を参照してください。
システムのローカル IPC またはネットワークソケットをカプセル化するソケットユニット。ソケットベースのアクティブ化に役立ちます。ソケットユニットの詳細については、 systemd.socket(5) を参照してください。ソケットベースのアクティブ化および他の形式のアクティブ化の詳細については、 daemon(7) を参照してください。
ターゲットユニットは、ユニットをグループ化したり、起動時に既知の同期ポイントを提供したりするのに役立ちます。 systemd.target(5) を参照してください。
デバイスユニットは systemd のカーネルデバイスを公開し、デバイスベースのアクティベーションを実装するために使用できます。詳細については、 systemd.device(5) を参照してください。
マウントユニットは、ファイルシステムのマウントポイントを制御します。詳細については、 systemd.mount(5) を参照してください。
自動マウントユニットは、ファイルシステムのオンデマンドマウントと並列化された起動のための自動マウント機能を提供します。
systemd.automount(5) を参照してください。タイマーユニットは、タイマーに基づいて他のユニットのアクティブ化をトリガーするのに役立ちます。詳細は systemd.timer(5) にあります。
スワップユニットはマウントユニットと非常によく似ており、オペレーティングシステムのメモリスワップパーティションまたはファイルをカプセル化します。それらは systemd.swap(5) で説明されています。
パスユニットは、ファイルシステムオブジェクトが変更または変更されたときに他のサービスをアクティブにするために使用できます。
systemd.path(5) を参照してください。スライスユニットは、システムプロセス(サービスユニットやスコープユニットなど)を管理するユニットを、リソース管理のために階層ツリーでグループ化するために使用できます。 systemd.slice(5) を参照してください。
スコープユニットはサービスユニットに似ていますが、外部プロセスを開始する代わりに管理します。 systemd.scope(5) を参照してください。
ユニットは、構成ファイルとして名前が付けられています。一部のユニットには特別なセマンティクスがあります。詳細なリストは systemd.special(7) にあります。systemd は、正と負の要件の依存関係(つまり
Requires=とConflicts=)や順序の依存関係（After=とBefore=）など、さまざまな種類の依存関係を認識しています。注意: 順序と要件の依存関係は直交しています。
2 つのユニット間に要件の依存関係のみが存在し(例: foo.service には bar.service が必要)、順序の依存関係はなく(例: foo.service の後に bar.service )、両方の開始が要求された場合、それらは並行して開始されます。
要件と順序の依存関係の両方が 2 つのユニット間に配置されるのは一般的なパターンです。
また、依存関係の大部分は systemd によって暗黙的に作成および管理されることに注意してください。
ほとんどの場合、追加の依存関係を手動で宣言する必要はありませんが、これを行うことは可能です。アプリケーションプログラムと(依存関係を介した)ユニットは、ユニットの状態変更を要求できます。
systemd では、これらのリクエストはjobとしてカプセル化され、ジョブキューに保持されます。
ジョブは成功する場合と失敗する場合があります。
ジョブの実行は、スケジュールされたユニットの依存関係に基づいて実行されます。起動時に systemd は、起動時サービスおよびその他の起動時ユニットを依存関係を介して呼び出すことによって起動するジョブであるターゲットユニット default.target を起動します。
通常、ユニット名は、 graphical.target(UI へのフル機能のブートの場合)または multi-user.target(組み込み環境またはサーバー環境で使用するための限定されたコンソールのみのブートの場合)、または同様のエイリアス(シンボリックリンク)です; graphic.target のサブセット)。
ただし、それを他のターゲットユニットのエイリアスとして構成するかどうかは、管理者の裁量に任されています。
これらのターゲットユニットの詳細については、systemd.special(7) を参照してください。systemd は、メモリに読み込まれた最小単位のユニットのみを保持します。
具体的には、メモリに読み込まれたままになっているユニットは、次の条件の少なくとも 1 つに該当するユニットのみです。
アクティブ、アクティブ化、非アクティブ化、または障害が発生した状態(つまり、
inactiveを除くすべてのユニット状態)キューに入れられたジョブがある。
メモリに読み込まれるのは、何らかの少なくとも 1 つの他のユニットの依存関係である。
まだ割り当てられた何らかの形のリソースを持っている(たとえば、非アクティブであるが、終了要求を無視したプロセスがまだ残っているサービスユニット)
D-Bus 呼び出しによってプログラムでメモリに固定されている。
systemd は、ユニットがまだロードされていない場合、操作がユニットに要求されるとすぐに、ユニットをディスクから自動的かつ暗黙的にロードします。
したがって、多くの点で、ユニットがロードされているかどうかはクライアントにはわかりません。
systemctl list-units --allを使用して、現在ロードされているすべてのユニットを一覧表示します。
上記のいずれの条件にも当てはまらないユニットは、直ちにアンロードされます。
ユニットがメモリからアンロードされると、そのアカウンティングデータもフラッシュされることに注意してください。
ただし、ユニットがシャットダウンするたびに消費されたリソースを宣言するジャーナルログレコードが生成されるため、このデータは通常失われません。systemd の生成されたプロセスは、プライベートな systemd 階層でそれらが属するユニットにちなんで名付けられた個々の Linux 制御グループに配置されます。
(コントロールグループの詳細については、 cgroups.txt またはcgroupsを参照してください)。
systemd はこれを使用して、プロセスを効果的に追跡します。
制御グループ情報はカーネル内に保持され、ファイルシステム階層(/sys/fs/cgroup/systemd/の下)、または systemd-cgls(1) や ps(1)。
(ps xawf -eo pid,user,cgroup,args は、すべてのプロセスとそれらが属する systemd ユニットを一覧表示するのに特に役立ちます。)systemd は SysV init システムと高い互換性があります。
SysVinit スクリプトがサポートされており、代替の(制限されていますが)構成ファイル形式として読み取られます。
SysV /dev/initctlインターフェースが提供され、さまざまな SysV クライアントツールの互換実装が利用可能です。
それに加えて、/etc/fstabや utmp データベースなど、さまざまな Unix 機能がサポートされています。systemd には最小限のトランザクションシステムがあります。
ユニットが起動またはシャットダウンするように要求された場合、ユニットとそのすべての依存関係が一時トランザクションに追加されます。
次に、トランザクションに一貫性があるかどうかを確認します(つまり、すべてのユニットの順序に循環がないかどうか)。
ユニットの順序に循環が認められる場合、 systemd は修正を試み、ループを削除できる可能性のある重要でないジョブをトランザクションから削除します。
また、 systemd は、実行中のサービスを停止するトランザクション内の重要でないジョブを抑制しようとします。
最後に、トランザクションのジョブがすでにキューに入れられているジョブと矛盾しているかどうかが確認され、オプションでトランザクションが中止されます。
すべてがうまくいき、トランザクションが一貫していて影響が最小限に抑えられている場合、未解決のすべてのジョブとマージされ、実行キューに追加されます。
これは事実上、要求された操作を実行する前に、 systemd がそれが妥当であることを確認し、可能であれば修正し、実際に機能しない場合にのみ失敗することを意味します。トランザクションは実行時のユニットの状態とは無関係に生成されることに注意してください。
したがって、たとえば、すでに開始されているユニットで開始ジョブが要求された場合、トランザクションは生成され、非アクティブな依存関係が起動します(定義された関係ごとに他のジョブの伝播も発生します)。
これは、キューされたジョブがターゲットユニットの状態と比較して実行状態にあり、両方が満たされると成功と完了のマークが付けられるためです。ただし、このジョブは、定義された関係により他の依存関係も取り込むため、この例では、非アクティブなユニットのいずれかのジョブもキューに入れられます。systemd には、ブートプロセスの一部として実行する必要があるさまざまなタスクのネイティブ実装が含まれています。
たとえば、ホスト名を設定したり、ループバックネットワークデバイスを構成したりします。
また、/sysや/procなどのさまざまな API ファイルシステムをセットアップしてマウントします。systemd の背後にある概念と思想の詳細については、 Original Design Document を参照してください。
systemd が提供する一部のインターフェイスは Interface Stability Promise でカバーされていることに注意してください。
ユニットは、ブート時およびシステムマネージャーのリロード時に動的に生成される場合があります。
たとえば、カーネルコマンドラインで渡された他の構成ファイルまたはパラメーターに基づいています。
詳細については、 systemd.generator(7) を参照してください。コンテナーまたは initrd 環境で systemd を呼び出すシステムは、それぞれ Container Interface または initrd Interface の仕様を実装する必要があります。
ディレクトリ
システムユニットディレクトリ
systemd システムマネージャは、さまざまなディレクトリからユニット構成を読み取ります。
ユニットファイルをインストールするパッケージはpkg-config systemd --variable=systemdsystemunitdirによって返されるディレクトリにそれらを配置します。
チェックされる他のディレクトリは/usr/local/lib/systemd/systemおよび/lib/systemd/systemです。
ユーザー設定が常に優先されます。
pkg-config systemd --variable=systemdsystemconfdirは、システム構成ディレクトリのパスを返します。
パッケージは systemctl(1) ツールのenableおよびdisableコマンドでのみ、これらのディレクトリの内容を変更する必要があります。
ディレクトリの完全なリストは systemd.unit(5) にあります。ユーザーユニットディレクトリ
ユーザーユニットディレクトリにも同様のルールが適用されます。ただし、ここでは、 XDG Base Directory specification に従ってユニットを検索しています。
アプリケーションはpkg-config systemd --variable=systemduserunitdirによって返されるディレクトリにユニットファイルを配置する必要があります。
グローバル設定はpkg-config systemd --variable=systemduserconfdirによって報告されたディレクトリで行われます。
systemctl(1) ツールのenableコマンドとdisableコマンドは、ユニットのグローバル(つまり、すべてのユーザー)とプライベート(1 人のユーザー)の有効化 / 無効化の両方を処理できます。
ディレクトリの完全なリストは systemd.unit(5) にあります。SysV init スクリプトディレクトリ
SysV init スクリプトディレクトリの場所は、ディストリビューションによって異なります。
要求されたサービスのネイティブユニットファイルが見つからない場合、 systemd は同じ名前の.service接尾辞が削除された SysV init スクリプトを探します。SysV ランレベルリンクファームディレクトリ
SysV ランレベルリンクファームディレクトリの場所は、ディストリビューションによって異なります。
systemd は、サービスを有効にするかどうかを判断するときにリンクファームを考慮します。
ネイティブユニット構成ファイルを持つサービスユニットは、 SysV ランレベルリンクファームでアクティブ化して開始することはできません。シグナル
SIGTERM
この信号を受信すると、 systemd システムマネージャーはその状態をシリアル化し、それ自体を再実行して、保存された状態を再度逆シリアル化します。
これは主にsystemctl daemon-reexecと同等です。systemd ユーザーマネージャーは、このシグナルを受信すると、exit.target ユニットを開始します。
これはほとんどsystemctl --user start exit.target --job-mode=replace-irreversibleと同等です。SIGINT
この信号を受信すると、 systemd システムマネージャーは ctrl-alt-del.target ユニットを起動します。
これは、systemctl start ctrl-alt-del.target --job-mode=replace-irreversibleとほぼ同等です。
この信号が 2 秒間に 7 回以上受信された場合、即時リブートがトリガーされます。
コンソールで Ctrl + Alt + Del を押すと、この信号がトリガーされることに注意してください。
したがって、再起動がハングしている場合は、 Ctrl + Alt + Del を 2 秒以内に 7 回以上押すと、すぐに再起動する比較的安全な方法になります。systemd ユーザーマネージャーは、このシグナルを SIGTERM と同じ方法で処理します。
SIGWINCH
このシグナルを受信すると、 systemd システムマネージャーは kbrequest.target ユニットを開始します。
これはほとんどsystemctl start kbrequest.targetと同等です。このシグナルは systemd ユーザーマネージャーによって無視されます。
SIGPWR
このシグナルを受信すると、 systemd マネージャーは sigpwr.target ユニットを起動します。
これはほとんどsystemctl start sigpwr.targetと同等です。SIGUSR1
この信号を受信すると、 systemd マネージャーは D-Bus バスへの再接続を試みます。
SIGUSR2
このシグナルを受信すると、 systemd マネージャーはその完全な状態を人間が読める形式で記録します。
ログに記録されるデータは、systemd-analyze dumpによって出力されるものと同じです。SIGHUP
完全なデーモン構成を再ロードします。
これはほぼsystemctl daemon-reloadと同等です。SIGRTMIN+0
デフォルトモードに入り、 default.target ユニットを開始します。
これはほとんどsystemctl isolate default.targetと同等です。SIGRTMIN+1
レスキューモードに入り、 rescue.target ユニットを開始します。
これは、systemctl isolate rescue.targetとほぼ同等です。SIGRTMIN+2
緊急モードに入り、 emergency.service ユニットを開始します。
これは、ほとんどの場合、systemctl isolate immediate.serviceと同等です。SIGRTMIN+3
マシンを停止し、 halt.target ユニットを開始します。
これはほとんどsystemctl start halt.target --job-mode=replace-irreversibleと同等です。SIGRTMIN+4
マシンの電源を切り、 poweroff.target ユニットを起動します。
これはほとんどsystemctl start poweroff.target --job-mode=replace-irreversibleと同等です。SIGRTMIN+5
マシンを再起動し、 reboot.target ユニットを起動します。
これはほとんどsystemctl start reboot.target --job-mode=replace-irreversibleと同等です。SIGRTMIN+6
kexec を介してマシンを再起動し、 kexec.target ユニットを起動します。
これはほとんどsystemctl start kexec.target --job-mode=replace-irreversibleと同等です。SIGRTMIN+13
すぐにマシンを停止します。
SIGRTMIN+14
すぐにマシンの電源を切ります。
SIGRTMIN+15
すぐにマシンを再起動します。
SIGRTMIN+16
すぐに kexec でマシンを再起動します。
SIGRTMIN+20
カーネルコマンドラインの
systemd.show_status=1で制御されるように、コンソールでのステータスメッセージの表示を有効にします。SIGRTMIN+21
カーネルコマンドラインの
systemd.show_status=0で制御されるように、コンソールでのステータスメッセージの表示を無効にします。SIGRTMIN+22
カーネルコマンドラインの
systemd.log_level=debugと同等の方法で、サービスマネージャーのログレベルを「デバッグ」に設定します。SIGRTMIN+23
ログレベルを設定された値に復元します。
構成された値は、優先順位に従って、カーネルコマンドラインでsystemd.log-level=で指定された値、または構成ファイルでLogLevel=で指定された値、または組み込みのinfoのデフォルトから導出されます。SIGRTMIN+24
すぐにマネージャを終了します(--user インスタンスでのみ使用可能)。
SIGRTMIN+26
ログターゲットを設定された値に復元します。
構成された値は、優先順位に従って、カーネルコマンドラインで systemd.log-target で指定された値、または構成ファイルでLogTarget=で指定された値、または組み込みの default から取得されます。SIGRTMIN+27, SIGRTMIN+28
カーネルコマンドラインの
systemd.log_target=console(または SIGRTMIN+28 のsystemd.log_target=kmsg)と同等の方法で、ログターゲットを SIGRTMIN+27 のconsole(または SIGRTMIN+28 のkmsg)に設定します。環境
$SYSTEMD_LOG_LEVEL
systemd は、この環境変数からログレベルを読み取ります。
これは --log-level で上書きできます。$SYSTEMD_LOG_TARGET
systemd は、この環境変数からログターゲットを読み取ります。
これは --log-target で上書きできます。$SYSTEMD_LOG_COLOR
systemd が重要なログメッセージを強調表示するかどうかを制御します。
これは --log-color で上書きできます。$SYSTEMD_LOG_LOCATION
systemd がログのメッセージとともにコードの位置を出力するかどうかを制御します。
これは --log-location で上書きできます。$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
systemd ユーザーマネージャーは XDG Base Directory specification に従ってこれらの変数を使用して、その構成を見つけます。
$SYSTEMD_UNIT_PATH
systemd がユニットファイルを探す場所を制御します。
$SYSTEMD_SYSVINIT_PATH
systemd が SysV init スクリプトを探す場所を制御します。
$SYSTEMD_SYSVRCND_PATH
systemd が SysV init スクリプトランレベルリンクファームを探す場所を制御します。
$SYSTEMD_COLORS
値はブール値でなければなりません。
カラー化された出力を生成するかどうかを制御します。
これを指定して、 systemd が$TERMとコンソールの接続先に基づいて行う決定を上書きできます。$SYSTEMD_URLIFY
値はブール値でなければなりません。
これをサポートするターミナルエミュレータの出力にクリック可能なリンクを生成するかどうかを制御します。
これを指定して、 systemd が$TERMおよびその他の条件に基づいて行う決定を上書きできます。$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
ソケットベースのアクティベーション中に監視対象プロセス用に systemd によって設定されます。詳細については、 sd_listen_fds(3) を参照してください。
$NOTIFY_SOCKET
ステータスと起動完了通知の監視対象プロセスに対して systemd によって設定されます。
詳細については、 sd_notify(3) を参照してください。systemd とそのさまざまなコンポーネントによって理解されるその他の環境変数については、 Known Environment Variables を参照してください。
カーネルコマンドライン
システムインスタンスとして実行すると、 systemd はいくつかのカーネルコマンドライン引数を解析します。
systemd.unit=, rd.systemd.unit=
ユニットを上書きして起動時にアクティブにします。
デフォルトは default.target です。
これは、一時的に別のブートユニット、たとえば rescue.target や emergency.service でブートするために使用できます。
これらのユニットの詳細については、 systemd.special(7) を参照してください。
rd.で始まるオプションは、メインシステムでのみ接頭辞が付いていない RAM ディスクに対して、初期 RAM ディスク (initrd) でのみ有効です。systemd.dump_core
ブール引数を取るか、引数なしで指定した場合はオプションを有効にします。
有効にすると、 systemd マネージャー (PID 1) はクラッシュしたときにコアをダンプします。
それ以外の場合、コアダンプは作成されません。
デフォルトは有効です。systemd.crash_chvt
正の整数またはブール引数を取ります。
引数なしで指定することもでき、正のブール値と同じ効果があります。
正の整数(1 から 63 の範囲)が指定されている場合、システムマネージャー(PID 1)は、クラッシュしたときに指定された仮想端末(VT)をアクティブにします。
デフォルトは無効です。
つまり、そのような切り替えは行われません。
有効に設定すると、カーネルメッセージが書き込まれる VT が選択されます。systemd.crash_shell
ブール引数を取るか、引数なしで指定した場合はオプションを有効にします。
有効にすると、システムマネージャー(PID 1)は、クラッシュしたときに 10 秒の遅延後にシェルを生成します。
それ以外の場合、シェルは生成されません。
シェルはパスワード認証によって保護されていないため、セキュリティ上の理由から、デフォルトでは無効になっています。systemd.crash_reboot
ブール引数を取るか、引数なしで指定した場合はオプションを有効にします。
有効にすると、システムマネージャー(PID 1)は、マシンがクラッシュしたときに、 10 秒後に自動的にマシンを再起動します。
そうしないと、システムが無期限にハングします。
再起動ループを回避するために、デフォルトでは無効になっています。
systemd.crash_shell と組み合わせると、シェルの終了後にシステムが再起動されます。systemd.confirm_spawn
ブール引数、または確認メッセージが送信される仮想コンソールへのパスを取得します。
引数なしで指定することもでき、正のブール値と同じ効果があります。
有効になっている場合、システムマネージャ(PID 1)は、/dev/consoleを使用してプロセス起動時に確認を求めます。
パスまたはコンソール名(ttyS0など)が指定されている場合は、このパスで指定されている、または指定した名前で記述されている仮想コンソールが代わりに使用されます。
デフォルトでは無効になっています。systemd.service_watchdogs=
ブール引数を取ります。
無効にすると、すべてのサービスランタイムウォッチドッグ(WatchdogSec=)と緊急アクション(OnFailure=やStartLimitAction=など)がシステムマネージャー(PID 1)によって無視されます。
systemd.service(5) を参照してください。
デフォルトでは有効になっています。
つまり、ウォッチドッグと障害アクションは正常に処理されます。
ハードウェアウォッチドッグは、このオプションの影響を受けません。systemd.show_status
ブール引数または定数
autoを取ります。
引数なしで指定することもでき、正のブール値と同じ効果があります。
有効になっている場合、 systemd マネージャー(PID 1)は、起動時にコンソールに簡潔なサービスステータスの更新を表示します。
autoは、ユニットに障害が発生するか、起動に大幅な遅延が発生するまでfalseのように動作します。
カーネルコマンドラインオプションとしてquietが渡されない限り、デフォルトで有効になります。
この場合、デフォルトでautoになります。
指定した場合、システムマネージャー構成ファイルオプションShowStatus=が上書きされます。
systemd-system.conf(5) を参照してください。
ただし、プロセスコマンドラインオプション --show-status は、このカーネルコマンドラインオプションと構成ファイルオプションの両方よりも優先されます。systemd.log_target=, systemd.log_level=, systemd.log_location=, systemd.log_color
上記の $SYSTEMD_LOG_TARGET , $SYSTEMD_LOG_LEVEL , $SYSTEMD_LOG_LOCATION , $SYSTEMD_LOG_COLOR 環境変数と同じ効果で、ログ出力を制御します。
systemd.log_color は引数なしで指定でき、正のブール値と同じ効果があります。systemd.default_standard_output=, systemd.default_standard_error=
上記の --default-standard-output, --default-standard-error コマンドライン引数とそれぞれ同じ効果で、サービスのデフォルトの標準出力とエラー出力を制御します。
systemd.setenv=
VARIABLE=VALUEの形式の文字列引数を取ります。
フォークされた子プロセスに追加するデフォルトの環境変数を設定するために使用できます。
複数の変数を設定するために複数回使用できます。systemd.machine_id=
machine-id を設定するために使用される 32 文字の 16 進数値を取ります。
すべてのブートで同じ machine-id が必要なネットワークブートを主な対象としています。systemd.unified_cgroup_hierarchy
引数なしで、または
true引数とともに指定すると、 統合された cgroup 階層 の使用が可能になります(別名 cgroups-v2)。
false引数を指定した場合、ハイブリッドまたは完全な レガシー cgroup 階層 にフォールバックします。
このオプションが指定されていない場合、デフォルトの動作はコンパイル時に決定されます(-Ddefault-hierarchy=mesonオプション)。
カーネルが統合 cgroup 階層をサポートしていない場合、このオプションが指定されていても、レガシー階層が使用されます。systemd.legacy_systemd_cgroup_controller
完全な統合 cgroup 階層が使用されていない場合に有効になります(前のオプションを参照)。
引数なしで、またはtrue引数とともに指定するとhybridcgroup 階層(systemd に使用される cgroups-v2 ツリー、および他のコントローラーには 従来の cgroup 階層 、別名 cgroups-v1)の使用を無効にします。
完全なlegacyモードを強制します。
false引数を指定すると、hybrid階層の使用が有効になります。
このオプションが指定されていない場合、デフォルトの動作はコンパイル時に決定されます(-Ddefault-hierarchy=mesonオプション)。
カーネルが統合 cgroup 階層をサポートしていない場合、このオプションが指定されていても、レガシー階層が使用されます。quiet
systemd.show_status=noと同様に、起動時にステータス出力をオフにします。
このオプションはカーネル自体にも読み込まれ、カーネルログ出力が無効になることに注意してください。
したがって、このオプションを渡すと、システムマネージャとカーネルの両方からの通常の出力がオフになります。debug
デバッグ出力をオンにします。
これは、systemd.log_level=debugと同等です。
このオプションはカーネル自体にも読み込まれ、カーネルのデバッグ出力を有効にすることに注意してください。
したがって、このオプションを渡すと、システムマネージャーとカーネルの両方からのデバッグ出力がオンになります。emergency, rd.emergency, -b
緊急モードで起動します。
これはそれぞれsystemd.unit=emergency.targetまたはrd.systemd.unit=emergency.targetと同等であり、互換性の理由と入力の簡素化のために提供されています。rescue, rd.rescue, single, s, S, 1
レスキューモードで起動します。
これは、それぞれsystemd.unit=rescue.targetまたはrd.systemd.unit=rescue.targetと同等であり、互換性の理由と入力の簡素化のために提供されています。2, 3, 4, 5
指定されたレガシー SysV ランレベルで起動します。
これらは、それぞれsystemd.unit=runlevel2.target,systemd.unit=runlevel3.target,systemd.unit=runlevel4.targetおよびsystemd.unit=runlevel5.targetと同等であり、互換性の理由と入力の簡素化のために提供されています。locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=, locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=, locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=
使用するシステムロケールを設定します。これにより、
/etc/locale.confの設定が上書きされます。
詳細については、 locale.conf(5) および locale(7) を参照してください。
コア OS のコンポーネントが理解できる他のカーネルコマンドラインパラメータについては、 kernel-command-line(7) を参照してください。ソケットと FIFO
/run/systemd/notify
デーモンステータス通知ソケット。
これは AF_UNIX データグラムソケットであり、 sd_notify(3) によって実装されるデーモン通知ロジックを実装するために使用されます。/run/systemd/private
systemctl(1) と systemd プロセス間の通信チャネルとして内部的に使用されます。
これは AF_UNIX ストリームソケットです。
このインターフェースは systemd 専用であり、外部プロジェクトでは使用しないでください。/dev/initctl
systemd-initctl.service ユニットで実装されている、 SysV クライアントインターフェースの限定的な互換性サポート。
これは、ファイルシステム内の名前付きパイプです。
このインターフェースは廃止されているため、新しいアプリケーションでは使用しないでください。SEE ALSO
- The systemd Homepage
- systemd-system.conf(5)
- locale.conf(5)
- systemctl(1)
- journalctl(1)
- systemd-notify(1)
- daemon(7)
- sd-daemon(3)
- systemd.unit(5)
- systemd.special(5)
- pkg-config(1)
- kernel-command-line(7)
- bootup(7)
- systemd.directives(7)
NOTES
Linux コンテナー内で実行する場合、これらの引数は、上記のオプションセクションに列記されているコマンドラインオプションの横にある systemd 自体にコマンドライン引数として渡される場合があります。
Linux コンテナーの外部で実行する場合、これらの引数は代わりに/proc/cmdlineから解析されます。
- 投稿日：2020-07-10T18:07:08+09:00
Kali Linux ver2020.2をMacBook pro 2017にDual Boot(VMではなく)
書く動機
最近のMacbook proはTouchbar搭載と新しい周辺機器の導入などによって、
Linuxの起動後にはキーボードやタッチパッドが使用できないケースが多発します。
さらには、ファンなども動作しないので、パソコンが熱くなっていまいます。
しかし、多数のデベロッパーによる貢献でそのような問題は解決されつつあります。
友人や同僚に同じことが起きた場合に、参考になれば幸いと思い書きました。
ちなみに、初めての投稿なので小さいミスまたは改善点などあれば、コメントしてください。やること
- 周辺機器・ドライバーのアップデート(keyboard, Tocuhar, Touchpad)
- ファン管理モジュール
- 電源管理モジュール
- (随意) WiFiの改善
環境
- MacBook Pro 2017
- Kali Linux ver2020.2 - https://www.kali.org/downloads/
1. 周辺機器・ドライバーのアップデート
以下のGit Hubレポジトリを使用します。
https://github.com/cb22/macbook12-spi-driver
git clone https://github.com/cb22/macbook12-spi-driverそして、カーネルバージョンを確認します。
Kali Linux ver2020.2は5.3です。
カーネルが4.11以下であれば,ブートする際にはintremap=nosidと、
noapiをカーネルオプションに入っていないことを確認する必要があります。
次にファイルシステムイメージ**/etc/initramfs-tools/moduleに含ませるspiを書き足します。
それから、dkmsというカーネルモジュールサポートを入れ、Appleの周辺機器をインストールします。echo -e "\n# applespi\napplespi\nspi_pxa2xx_platform\nintel_lpss_pci" >> /etc/initramfs-tools/modules apt install dkms git clone https://github.com/cb22/macbook12-spi-driver.git /usr/src/applespi-0.1 dkms install -m applespi -v 0.1以上の行いによって、以下のことができるようになりました。
-キーボードでのタイピング
-TouchBar (Fnを押して、Fnキーが使える）
-基本的なタッチパッド機能（2,3,4本指のスクロール動作）2.ファン管理モジュール
最初に、applesmcとcoretempというモジュールが存在するか確認します。
lsmod | grep -e applesmc -e coretemp存在しなければ、/etc/modules/に以下のものを足します。
coretemp applesmc次に以下のGit Hubレポジトリを使用します。
https://github.com/linux-on-mac/mbpfan
git clone https://github.com/linux-on-mac/mbpfanそして、リポジトリに入って、
make && sudo make install sudo make tests管理ファイル/etc/mbpfan.confに入って、
適度にファン速度と反応温度を買えることができます。注意: macbookはファンが二つついているので、min_fan1, min_fan2とそれぞれ左右の情報を足します。
min_fan1_speed = 4500 min_fan2_speed = 4500 max_fan1_speed = 5500 max_fan2_speed = 5500 low_temp = 63 # try ranges 55-63, default is 63 high_temp = 66 # try ranges 58-66, default is 66 max_temp = 86 polling_interval = 1 # default is 1 seconds普通はファン速度2000rpmなんですけど、自分は冷やしたいので4500rpmに上げました。
あと、max_fan*はたまにいきなりmax_tempに到達するので、6200はファンに悪いと思い、下げました。Boot時にmbpfanを実行するために、mbpfan.debianをmbpfanに改名して、
sudo update-rc.d mbpfan defaultsと実行
実行ファイルは/usr/sbin/mbpfanにあります。
こんな感じで、ファン管理はお終いです。
3.電源管理モジュール
以下の公式サイトによるモジュールを使用しました。
デビアンの公式レポジトリーを/etc/apt/sources.listに足します。
deb http://ftp.debian.org/debian buster-backports main deb http://ftp.debian.org/debian stretch-backports-sloppy mainインストール
apt update && apt install tlp tlp-rdw起動
systemctl start tlp4.WiFiの改善
デフォルトの状態だと、WiFiが届きません。
参考：Wi-Fiの出力を下げることによる利点とは？ -gigazine.net-
https://gigazine.net/news/20190411-wi-fi-power/なので、WiFiの出力をさげました。
iwconfig wlan0 txpower 10結果：
wlan0 IEEE 802.11 ESSID:"router-xxx" Mode:Managed Frequency:2.422 GHz Access Point: xx:xx:xx:xx Bit Rate=72.2 Mb/s Tx-Power=10 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=31/70 Signal level=-79 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:64 Invalid misc:0 Missed beacon:0ちょっと離れていても、WiFiにつながるようになりました！
- 投稿日：2020-07-10T03:03:40+09:00
EC2 Linux上でinodeが枯渇した際の対処法
There appears to be insufficient space on your system to finish とエラーがでた！
とある日，会社のサービスが止まっていまい，原因の究明を行ったところ上記のエラーが発生して新規ファイルの作成ができなくなっていた．
そこでディスクのスペースを確認したところ空き容量は問題ないが，inodeが枯渇していることが判明．
ここに，この問題を対処した際の備忘録を残す．inode空き容量の確認
df -iコマンドでinodeの空き容量を調べる/dev/xvda1 217227 217227 217227 100% /確認すると使用率は100%になっている．
これでは新規ファイルの作成ができず，logを書き出したところでサービスが止まってしまう．ファイルシステムの確認
df -Tコマンドでファイルシステムを確認する/dev/xvda1 ext4 略今回はext4であった．
ext4ではinodeテーブルのサイズを動的に変更は(多分)できないので，ファイルシステムを再構築するか，ディスクサイズを拡張し，同時にinodeテーブルサイズを方法をとる．
EC2では手軽にディスクサイズを拡張できるため，今後の事も考えディスクサイズの拡張を行う．ボリュームサイズの拡張
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 8G 0 disk └─xvda1 202:1 0 8G 0 part /ボリュームサイズを確認しておく．
次にEC2ダッシュボードで，問題のインスタンスからEBS IDをクリックし，EBSボリュームのページに移動に移動する．
対象のボリュームのスナップショットを念のためとっておき，ボリュームの変更を行う．
ここで先ほど確認しておいたボリュームサイズ以上の値を指定し，変更リクエストを行う．
この変更は5分ほどかかる事もある．変更できたら以下のようになるだろう．
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 20G 0 disk └─xvda1 202:1 0 8G 0 part /ある程度待っても変更されない場合はインスタンスの再起動をすると変更される．
しかし，ルートのパーティションは8Gのままで変更されていないため，以下コマンドで拡張を行う．$ sudo growpart /dev/xvda 1（
mkdir: cannot create directory '/tmp/growpart.1959': No space left on deviceと出る場合は空きがなくtmpファイルが作成できないので，お掃除をしてから実行する）
FAILED: failed to make temp dir再度確認
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 20G 0 disk └─xvda1 202:1 0 20G 0 part /これでサイズが最大まで拡張されています．
ファイルシステムの拡張
最後にファイルシステムの拡張を行う
$ sudo resize2fs /dev/xvda1$ df -i /dev/xvda1 1310720 217227 1093493 17% /inode使用率が17%まで減りました．
これで完了です．おまけ
$ dpkg --get-selections | grep linux- linux-base install linux-headers-4.4.0-121 install linux-headers-4.4.0-121-generic install linux-headers-4.4.0-124 install linux-headers-4.4.0-124-generic install linux-headers-4.4.0-127 install linux-headers-4.4.0-127-generic install linux-headers-4.4.0-128 install linux-headers-4.4.0-128-generic install linux-headers-4.4.0-130 install linux-headers-4.4.0-130-generic install linux-headers-4.4.0-133 install linux-headers-4.4.0-133-generic install linux-headers-4.4.0-134 install linux-headers-4.4.0-134-generic install linux-headers-4.4.0-137 install linux-headers-4.4.0-137-generic install linux-headers-4.4.0-138 install linux-headers-4.4.0-138-generic install linux-headers-4.4.0-139 install linux-headers-4.4.0-139-generic install linux-headers-4.4.0-151 install linux-headers-4.4.0-151-generic install linux-headers-4.4.0-154 install linux-headers-4.4.0-154-generic install linux-headers-4.4.0-157 install linux-headers-4.4.0-157-generic install linux-headers-4.4.0-159-generic install linux-headers-generic install linux-headers-virtual install linux-image-4.4.0-101-generic deinstall linux-image-4.4.0-104-generic deinstall linux-image-4.4.0-108-generic deinstall linux-image-4.4.0-109-generic deinstall linux-image-4.4.0-112-generic deinstall linux-image-4.4.0-116-generic deinstall linux-image-4.4.0-141-generic deinstall linux-image-4.4.0-142-generic deinstall linux-image-4.4.0-143-generic deinstall linux-image-4.4.0-151-generic install linux-image-4.4.0-154-generic install linux-image-4.4.0-157-generic install linux-image-4.4.0-159-generic install linux-image-4.4.0-92-generic deinstall linux-image-4.4.0-93-generic deinstall linux-image-4.4.0-96-generic deinstall linux-image-4.4.0-97-generic deinstall linux-image-4.4.0-98-generic deinstall linux-image-virtual install linux-libc-dev:amd64 install linux-modules-4.4.0-143-generic deinstall linux-modules-4.4.0-151-generic install linux-modules-4.4.0-154-generic install linux-modules-4.4.0-157-generic install linux-modules-4.4.0-159-generic install linux-virtual install確認してみると古いカーネルがいっぱい残っていた．
これをお掃除すれば空きが増えそうなので，空きがない場合は確認してみると良いかと思う．
一応確実に使わないであろうカーネルを削除下記オプション
--dry-runで削除テストを行い,問題がなければ削除を行う$ apt-get autoremove --purge linux-*-4.4.0-{121,124,127,128,130,133,134,137,138,139}* --dry-run以上で処置完了です．おつかれさまでした！
