kz5835さんの助け合いフォーラム投稿一覧
この問題で、fileコマンドで対象のファイルを処理すると
atimeが更新されるとされていますが、私の環境
(RHELクローンのRocky Linux8.8)では、実行例と
同じ操作をしても、atimeが更新されませんでした。
操作は、rootユーザが実行しました。
この原因/理由について、推測は可能でしょうか。
もし、なにか思いつく方がおられましたら、可能性のある
原因/理由を教えて下さい。
（私の環境での実行例と同じ操作のログ）
[root@rocky01 study]# stat 3705.txt
File: 3705.txt
Size: 53 Blocks: 8 IO Block: 4096 通常ファイル
Device: fd00h/64768d Inode: 34304122 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2023-07-26 22:35:17.077198384 +0900
Modify: 2023-07-24 22:39:14.256882058 +0900
Change: 2023-07-24 22:39:14.256882058 +0900
Birth: 2023-07-24 22:39:14.256882058 +0900
[root@rocky01 study]#
[root@rocky01 study]# date
2023年 7月 27日 木曜日 15:15:05 JST
[root@rocky01 study]#
[root@rocky01 study]# file 3705.txt
3705.txt: ASCII text
[root@rocky01 study]#
[root@rocky01 study]# stat 3705.txt
File: 3705.txt
Size: 53 Blocks: 8 IO Block: 4096 通常ファイル
Device: fd00h/64768d Inode: 34304122 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2023-07-26 22:35:17.077198384 +0900 <-更新されない！
Modify: 2023-07-24 22:39:14.256882058 +0900
Change: 2023-07-24 22:39:14.256882058 +0900
Birth: 2023-07-24 22:39:14.256882058 +0900
[root@rocky01 study]#
この問題の正答は、以下とされています。
①grep -E '17:[0-5][0-9]:[0-5][0-9]' system.log
②grep -E '17:[0-9]+:[0-9]+' system.log
①は、拡張正規表現が使用されていないので、-Eがなくてもよい
のに対して、②は、拡張正規表現が使用されているため
-Eをつけるかegrepを使用しなければならない認識です。
ということは、常に -E付き または egrepを使えば
拡張正規表現が含まれる場合も、含まれない場合も対応できる
ので、 -E/egrepのみを使用するほうが拡張正規表現で
失敗するリスクがないのでよいと考えられる様に感じました。
上記は必ずしもそうではなく、-E/egrepではなく
grepを使用しなければならないケースが存在するのでしょうか。
あるいは、機能的には上記でよいが、-E/egrepの方が
処理速度が遅い、多くのリソースを必要とするなど
なんらかのデメリットがあるのでしょうか。
ご存じの方がおられましたら、教えて下さい。
宜しくお願いします。
この問題の解説に、以下の記載があります。
①このような状況下でパッケージを更新する場合、upgradeとdist-upgradeでは異なるアプローチをとり、結果も変わります。なお、カーネルについては更新しません。
②dist-upgrade：ディストリビューション全体、つまりシステム内の全パッケージとカーネルを最新の状態に保つことを優先します。
②の見ると、dist-upgradeでは、カーネルを更新すると言っている様に見えます。
このことから、①の「なお、カーネルについては更新しません。」は、upgradeだけにあてはまり
upgrade：カーネルを更新しない
dist-upgrade：カーネルを更新する
と理解したのですが、正しいでしょうか。
ご存じの方がおられたら、教えて下さい。
宜しくお願いします。
この問題の解説に
「グラフィカルログイン（ランレベル5）に相当するターゲットです。上記の通り無駄なリソースを使用してしまうターゲットのため、誤りです。」
の記載があり、ランレベル5はサーバでは使用すべきでないとされていると思います。
上記のランレベルは、3と５が区別されているので、RedHat系のランレベルの認識です。
一方、別の問題の参考情報などで、Debian系では
「Debian系の場合はランレベル2～5(マルチユーザモード)を区別しません。」
との情報があります。
上記の両方を字義通りに解釈すると、Debian系はランレベル3と5が区別されていないので
サーバ利用には適しておらず、クライアントで利用すべきとなる様に思うのですが
この解釈は、正しいでしょうか。
あるいは、Debian系のlinuxもサーバ用途で使用されることは一般的であり
Debian系のlinuxをサーバで使用する場合には、ランレベルとは別の方法で
グラフィカルインタフェース機能を削除するのが通例であるということでしょうか。
ご存じの方がおられたら、教えて下さい。
宜しくお願いします。
この問題で解説されているランレベルとtargetとの関係について、いくつかわからない点が
あったので、教えて下さい。
①解説の冒頭に、ランレベルとtargetの対応表があります。
この表では、ランレベル2～4と5が区別されているため、Debian系のランレベルではなく
RedHat系のランレベルを意味していると理解したのですが、正しいでしょうか。
②RedHat系のランレベルでは、4は未使用とされているかと思います。
それにもかかわらず、「/lib/systemd/system」配下にrunlevel4.target
があるのは、どの様な理由でしょうか。
③multiuser.targetが対応するランレベルは2,3,4とされていますが、別の問題のランレベルの解説では
2 マルチユーザモード(テキストログイン、NFSなし）
3 マルチユーザモード(テキストログイン)
4 未使用
とされており、2,3,4には違いがあるとされています。
ランレベル2,3,4に違いがあるのであれば、「multiuser.targetが2,3,4に対応する」
というのは矛盾があるので、2,3,4のうち、どれがひとつのランレベルに対応するという
ことになると思うのですが、正しいでしょうか。
④上記③の理解が正しい場合、multiuser.targetは、どのランレベルと対応するのでしょうか。
ご存じの方がおられたら、教えて下さい。
宜しくお願いします。
この問題の解説に
「「/etc/inittab」を設定ファイルとして使用しないinitプログラムは「Upstart」と「systemd」です。」
と記載されています。
一方、問題ID:3410の参考情報に、以下の記載があります。
「ただし、UpstartはSysVinitと互換性があるため、「/etc/inittab」ファイルを新規に作成し、先述のSysVinitの場合と同じように記述することでデフォルトのランレベルを設定することもできます。その場合、「/etc/inittab」ファイルのランレベルが優先されます。」
上記の両方とも正しいとすると、Upstartが利用できる「/etc/inittab」の
設定項目はデフォルトのランレベルのみで、他の設定は利用できないという
ことになるかと思ったのですが、この理解で正しいでしょうか。
この問題(3311)の解説は、Upstartが「/etc/inittab」の全部の設定を
利用できるわけではないので、Upstartが「/etc/inittab」を利用しない
としているとの理解です。
ご存じの方がおられたら、教えて下さい。
宜しくお願いします。
この問題の解説に
「ESP（EFIシステムパーティション）はUEFIシステムにおいて、物理的なマシンを起動し、ファームウエアが読み込まれた後、その後の起動シーケンスで最初にアクセスされる領域になります。ESPは「/boot/efi」にマウントされます。」
と記載されています。
上記記述からは、ESPを利用するのは、linuxが起動される前の様に思われたのですが
「ESPは「/boot/efi」にマウントされます」の例（図）を見ると、linux上で
マウントされている様に思いました。
なぜ、linux上で、ESPをマウントするのでしょうか？
ご存じの方がおられたら、教えて下さい。
宜しくお願いします。