kz5835さんの助け合いフォーラム投稿一覧

書き込み内容を閉じる
助け合いフォーラムの投稿
2023/08/01 コメント
マウントオプションのdefaultの内容の確認方法
arashi1977様 情報のご提供、有難うございます。大変参考になりました。 宜しくお願いします。
2023/07/31 コメント
findでのメタキャラクタの説明について
arashi1977様 貴重な情報のご提供、有難うございます。大変参考になりました。 宜しくお願いします。
2023/07/31 コメント
mount -t ext4 /dev/sr0 /mnt/cdromの投入結果
arashi1977様 貴重な情報のご提供、有難うございます。大変参考になりました。 宜しくお願いします。
2023/07/31 コメント
マウントオプションのdefaultの内容の確認方法
arashi1977様 貴重な情報のご提供、有難うございます。大変参考になりました。 私の質問の理由ですが、私の環境のfstabが以下の様に記載されており optionはdefaultsのみの様でした。 （先頭が#の行以外） /dev/mapper/rl-root / xfs defaults 0 0 UUID=5c1b2769-6434-45d9-87c0-c07b71e2a326 /boot xfs defaults 0 0 /dev/mapper/rl-swap none swap defaults 0 0 実際には、先日、別の問題の質問で情報を頂いた、relatimeなど マニュアルにないパラメータもデフォルトに含まれるのかと思い そうであれば、試験で前提となるパラメータもマニュアル通りでは ないかもしれないので、実際のdefaultsの内容を表示する コマンドがあれば、確認しておきたいと思ったために質問させて 頂きました。 もし、上記の目的にあうコマンドやファイルなどをご存じでしたら 教えて頂けますと幸甚です。 （不明な場合は、無視して頂ければと思います。） 宜しくお願いいたします。
2023/07/31 コメント
xfs_repairの検査とxfs_checkの相違有無
arashi1977様 貴重な情報のご提供、有難うございます。大変参考になりました。 宜しくお願いします。
2023/07/31 コメント
fsckの-tの指定の要否
arashi1977様 ご回答、有難うございます。おかげ様で理解できました。 当方の検証不足については、申し訳ございませんでした。 宜しくお願いします。
2023/07/30 投稿
findでのメタキャラクタの説明について

この問題の誤答の解説に、以下の記載があります。
find -name '.f' -exec ls -l {} ; ---①
「」は、「0文字以上の文字列」の意味を持つ、検索時に便利なメタキャラクタです。---②

参考に以下の記載があります。
メタキャラクタは、シェルによって特別に解釈される文字です。 ---③

①の '*.f' が③のメタキャラクタを含む文字列であるとすると
''で囲まれているため、*はメタキャラクタではなくなってしまう様に思われました。

findコマンド内の '*.f' は、どの様に理解すればよいでしょうか。

例えば ' は、なんらかの理由でメタキャラクタではないが、''で
囲まれた中身は③のメタキャラクタであるということなのでしょうか。

ご存じの方がおられたら、教えて下さい。
宜しくお願いします。

2023/07/30 投稿
mount -t ext4 /dev/sr0 /mnt/cdromの投入結果

この問題の誤答である
mount -t ext4 /dev/sr0 /mnt/cdrom
について、誤って、このまま投入した場合には、どの様な結果と
なるでしょうか。
（マウント元が「iso9660」であるときに、-tでそれとは
異なるファイルシステム（この例ではext4）を指定すると
どの様な状態になるかの質問です。）

ご存じの方がおられましたら、教えて下さい。
宜しくお願いします。

2023/07/30 投稿
マウントオプションのdefaultの内容の確認方法

この問題で、マウントオプションに「defaults」があると記載されています。
この「defaults」の内容（defaultsに含まれるオプションパラメータのリスト）
を表示させることができる方法、コマンドはあるでしょうか。

ご存じの方がおられましたら、方法の内容とあわえて教えて下さい。
宜しくお願いします。

2023/07/29 投稿
xfs_repairの検査とxfs_checkの相違有無

この問題の解説で、以下が記載されています。
xfs_repair ファイルシステムを検査・修復する
xfs_check ファイルシステムをチェックする

上記の「xfs_repairでのファイルシステム検査」と
「xfs_checkでのファイルシステムチェック」は
同じことを実施するのでしょうか。
（「検査する」と「チェックする」は同じ意味でしょうか
という質問です。）

相違がある場合、相違点の内容とあわせて教えて頂けないでしょうか。

ご存じの方がおられましたら、教えて下さい。
宜しくお願いします。

2023/07/29 投稿
fsckの-tの指定の要否

この問題の正答である fsck -N -t ext3 /dev/sda4 について、質問させてください。
（質問1）
既に、ext3でフォーマットされている/dev/sda4への操作なので
「-t ext3」は、不要ではないかと思われました。
あえて、「-t ext3」を入れることのメリットは、ございますでしょうか。
（質問2）
このケースで、誤って -t でext3以外を指定して実行してしまった場合
ファイルシステムの破壊など、重大が問題が発生するでしょうか。

ご存じの方がおられたら教えて下さい。
宜しくお願いします。

2023/07/29 コメント
nice値と優先度の用語について
arashi1977様 詳細な解説、誠に有難うございます。 最後のご指摘は、おっしゃる通りだと思います。 おかげ様で、理解できました。 宜しくお願いします。
2023/07/29 コメント
SIGHUPの効果について
arashi1977様 ご回答、有難うございます。頂いた情報を読み落としておりました。 大変、失礼いたしました。 おかげさまで、理解できました。 宜しくお願いします。
2023/07/29 コメント
SIGHUPの効果について
arashi1977様 詳細な解説、誠に有難うございます。 おかげ様で、だいぶ、理解が進みました。 お忙しいことろ恐縮ですが、もう少し、教えて下さい。 頂きました情報、urlから以下の様に理解しました。 ・SIGHUPは、プロセスを終了させるものであって、再起動させるものではない ・アプリケーションの設定反映は、一般に、apacheのapachectl xxx の様に アプリケーションで用意されたコマンドで実行することである 上記の理解だけからですと、この問題の解説の 「HUPシグナルは、デーモンプログラムによっては、プログラムの設定ファイルを変更した後その設定ファイルをプロセスに再度読み込ませて設定を反映させる為に用いられます。」 は、誤りではないのかとの疑問が生じました。 これは、実際には、HUPシグナルを与えると設定ファイルを再読み込みする デーモンプログラムが多数あるので、この様に解説されているという ことなのでしょうか。 また、頂きました情報からしますと、「設定ファイルを再読み込みする」 方法は、必ずしも再起動ではなく、HUPシグナル受信により 再起動を伴わずに設定ファイルを再読み込みするデーモンプログラム も多数あるということでしょうか。 ご存じの範囲で、教えて下さい。 可能であれば、上記質問の回答に該当するデーモンプログラムの 例（名前）にも言及して頂けますと、大変に有難いです。 宜しくお願いいたします。
2023/07/29 コメント
nice値と優先度の用語について
arashi1977様 ご回答、有難うございます。 お忙しいところ恐縮ですが、もう少し、教えて下さい。 ご紹介頂いたurlでは、PRIをPriority value、本問題の選択肢の 情報をNice valueと表現しています。 日本語では、前者が優先度、後者がnice値になる思っています。 私の質問意図は、上記の表現が一般的であるとすると 実際のlpic試験でも、選択肢の19～-20の値のことを 「優先度」と表現（翻訳）される可能性がないのではないかということで 「優先度」と表現（翻訳）される可能性がない（あるいはほとんどない） のであれば、本問題の「優先度」「実行優先度」は、「nice値」に 変更/修正すべきではないかと思われたのですが、この点については いかがでしょうか。 上記の考えが妥当なのか、あるいは、そうではなく、一般的に 選択肢の19～-20の値が「優先度」と表現されることはよくあり 実際の試験でもその様に表現される可能性があるのかを もし、ご存じであれば、教えて頂けますと、大変に有難いです。 宜しくお願いいたします。
2023/07/29 コメント
fileコマンドでatimeが更新されない
arashi1977様 ご指摘、有難うございます。 >ご認識の通り、1回目かどうかで変わってくるんですね。なので「全体的な実施手順を開示」していただきたいなというところでした。 承知いたしました。私の方から、ファイル作成直後に発見した問題では ないことをお伝えできておらず、大変失礼いたしました。 このたびは、貴重な情報をご提供頂き、有難うございました。 おかげ様で、本件の状況を理解することができました。 宜しくお願いします。
2023/07/29 投稿
nice値と優先度の用語について

この問題の文章は「testプログラムの優先度は次のうちどれか。」
となっており、選択肢の19～-20の値のことを「優先度」と表現しています。
これに対して、その後の解説では、19～-20の値のことを「nice値」と表現し
参考では、「実行優先度」とも表現されています。
つまり、「nice値」「優先度」「実行優先度」が同じ意味で使われており
全て、選択肢の19～-20の値のことを指し示しています。

一方、ps -l では、PRI と NI の2つの値が表示され、19～-20の値
はNI列に表示されます。

この問題の表現が正しいとすると
NI = 「nice値」「優先度」「実行優先度」
になりますが、その場合、PRIは、日本語では、どの様な用語になるのかと
いう疑問が生じます。

19～-20の値のことを「nice値」「優先度」「実行優先度」と表現すること
は正しいのでしょうか。

正しい場合、ps -lのPRIは、日本語では、どの様な用語になるのでしょうか。

ご存じの方がおられたら、教えて下さい。
宜しくお願いします。

2023/07/29 投稿
SIGHUPの効果について

質問①
この問題の解説に、以下の記載があります。
「HUPシグナルは、デーモンプログラムによっては、プログラムの設定ファイルを変更した後その設定ファイルをプロセスに再度読み込ませて設定を反映させる為に用いられます。」
上記は、以下に言い換えることができるという理解で正しいでしょうか。
「HUPシグナルにより、対象プロセスを再起動する」

質問②
上記①が正しい場合、HUPシグナルは、プログラム（プロセス）によって
単に終了してしまうものもあれば、再起動するものもあるという理解で
正しいでしょうか。

質問③
上記がいずれも正しい場合、上記解説の様に、HUPシグナルで
「プログラムの設定ファイルを変更した後その設定ファイルをプロセスに再度読み込ませて設定を反映させる」
ことができるかどうかは、プログラムの書き方に依存するので
HUPシグナルでの設定変更の反映は、プログラムごとに仕様を調べ、可能と
わかった場合のみ実施するものであるという理解で正しいでしょうか。

ご存じの方がおられましたら、教えて下さい。
宜しくお願いします。

2023/07/29 コメント
fileコマンドでatimeが更新されない
arashi1977様 この質問の上記のtnishita2様のご指摘により、relatimeが 効いていても、ファイル作成後の最初のfileコマンド実行時のみ atimeが更新され、2回目以降が(24h以内には）更新されなくなる ことがわかりました。 上記を踏まえて、arashi1977様より頂きました情報を確認すると ファイル作成後の最初のfileコマンド実行時の情報の様でしたので 私の環境との違いがあったわけではなく、fileコマンドが １回目の実行か、2回目以降の実行かで差がでていたということ だった様です。 宜しくお願いします。
2023/07/29 コメント
fileコマンドでatimeが更新されない
tnishita2様 >私の提示したコマンドをよく見ていただくと、最後のスラッシュとシングルクォートの間に半角スペースを入れています。 失礼いたしました。実行してみると、以下で、relatimeが見えました。 [root@rocky01 study]# mount | grep 'on / ' /dev/mapper/rl-root on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) > 最初の1回目のfile コマンドだけはatime が更新されると思います。 まさにご指摘の通りでした。以下の様になりました。 root@rocky01 study]# echo 1 > file-test.txt [root@rocky01 study]# stat file-test.txt File: file-test.txt Size: 2 Blocks: 8 IO Block: 4096 通常ファイル Device: fd00h/64768d Inode: 35334998 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-29 00:30:05.338263018 +0900 Modify: 2023-07-29 00:30:05.338263018 +0900 Change: 2023-07-29 00:30:05.338263018 +0900 Birth: 2023-07-29 00:30:05.338263018 +0900 [root@rocky01 study]# [root@rocky01 study]# file file-test.txt file-test.txt: ASCII text [root@rocky01 study]# [root@rocky01 study]# stat file-test.txt File: file-test.txt Size: 2 Blocks: 8 IO Block: 4096 通常ファイル Device: fd00h/64768d Inode: 35334998 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-29 00:30:19.219273129 +0900 <-更新された Modify: 2023-07-29 00:30:05.338263018 +0900 Change: 2023-07-29 00:30:05.338263018 +0900 Birth: 2023-07-29 00:30:05.338263018 +0900 [root@rocky01 study]# [root@rocky01 study]# file file-test.txt file-test.txt: ASCII text [root@rocky01 study]# [root@rocky01 study]# stat file-test.txt File: file-test.txt Size: 2 Blocks: 8 IO Block: 4096 通常ファイル Device: fd00h/64768d Inode: 35334998 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-29 00:30:19.219273129 +0900 <-更新されない Modify: 2023-07-29 00:30:05.338263018 +0900 Change: 2023-07-29 00:30:05.338263018 +0900 Birth: 2023-07-29 00:30:05.338263018 +0900 [root@rocky01 study]# [root@rocky01 study]# file file-test.txt file-test.txt: ASCII text [root@rocky01 study]# [root@rocky01 study]# stat file-test.txt File: file-test.txt Size: 2 Blocks: 8 IO Block: 4096 通常ファイル Device: fd00h/64768d Inode: 35334998 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-29 00:30:19.219273129 +0900 <-更新されない Modify: 2023-07-29 00:30:05.338263018 +0900 Change: 2023-07-29 00:30:05.338263018 +0900 Birth: 2023-07-29 00:30:05.338263018 +0900 [root@rocky01 study]# このたびは、詳細に解説頂き、誠に有難うございました。 おかげさまで、疑問点が全て理解できました。 宜しくお願いいたします。
2023/07/28 コメント
fileコマンドでatimeが更新されない
tnishita2様 貴重な情報のご提供、誠に有難うございます。 mount | grep 'on /'　としてみると、多数の行がでてきたのですが /rootに関係しそうな行に /dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) がありました。上記でrelatimeが見えていますが、上記が / で、relatimeが効いていることを示すでしょうか。 >arashi1977 さんの環境でも、2回目以降のfile コマンドではatime が更新されないと思います。 についてですが、arashi1977様のログでは [root@localhost study]# stat 3705.txt -- 省略 -- Access: 2023-07-27 10:31:17.694303902 -0400 -- 省略 -- [root@localhost study]# file 3705.txt 3705.txt: ASCII text, with no line terminators [root@localhost study]# stat 3705.txt -- 省略 -- Access: 2023-07-27 10:31:53.690778999 -0400 ←変わっている となっており、atimeが36秒後に更新できているので relatimeが効いておらず、次のfileの実行でも、atimeは 更新される様に見えます。 宜しくお願いします。
2023/07/28 コメント
fileコマンドでatimeが更新されない
arashi1977様 アドバイス有難うございます。 結果は以下で、同じ表示になっている様に見えます。 [root@rocky01 ~]# cd study/ [root@rocky01 study]# pwd /root/study [root@rocky01 study]# findmnt -T $(pwd) TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/rl-root xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota [root@rocky01 study]# 上記で、relatimeの文字が見えますが、これは /root/studyで、relatimeが効いているということになるので しょうか。 ご存じの点について、教えて下さい。 宜しくお願いします。
2023/07/28 コメント
fileコマンドでatimeが更新されない
arashi1977様 ご指摘、有難うございます。 >元々の3705.txtをどう作ったかとかも含めて、全体的な実施手順を開示していただくことは可能でしょうか？ Rocy Linuxはwindows11 pro上のVMware Workstation 17 Player (17.0.2 build-21581411)にインストールしています。 完全な初心者のため、とくにデフォルトから変えることなく Rocky Linuxをインストールし、rootのhome directoryだった /rootの下で、vi 3705.txtを開いて内容を記入し、:wq!で保存しました。 その後、study directoryを作り、mvで、3705.txtを移動しました。 全て、ユーザはrootで操作しました。 tnishita2様よりご紹介頂いたurlに 「このオプションを有効にすると、ファイルが変更された、つまり atime が更新された (mtime) 場合、またはファイルが最後にアクセスされてから一定以上の時間 (デフォルトでは 1 日) が経過している場合に限り、atime データがディスクに書き込まれます。」 の記載があることに気づき、ちょうど、こちらの3705.txtのatime から24時間余りを経過したことに気づきましたので、同じ操作を してみたところ、atimeが変更されました。 (modify,changeは、それ以前に、他の操作で更新しています。） [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-27 22:15:28.328395363 +0900 Change: 2023-07-27 22:15:28.328395363 +0900 Birth: 2023-07-24 22:39:14.256882058 +0900 [root@rocky01 study]# [root@rocky01 study]# date 2023年 7月 27日 木曜日 22:47:09 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-27 22:47:26.485396585 +0900 Modify: 2023-07-27 22:15:28.328395363 +0900 Change: 2023-07-27 22:15:28.328395363 +0900 Birth: 2023-07-24 22:39:14.256882058 +0900 [root@rocky01 study]# このあとの file 3705.txt では、また、atimeが更新されない 状態に戻りましたので、私の環境では、tnishita2様にご指摘 頂いた relatime が効いているということの様に思われます。 とすると、私の環境とarashi1977様環境で 同じrocky linux8.8で　relatime が効いている/効いていないの 違いが現れている様に思われたのですが、この点について なにかお気づきになることは、ございますでしょうか。 もしありましたら、教えて下さい。
2023/07/27 コメント
fileコマンドでatimeが更新されない
tnishita2様 情報のご提供、誠に有難うございます。 質問対象のatimeが更新されないファイルのディレクトリは /root/study です。 mount | grep relatimeでは、以下の様に、多数の行が出力されましたが /root/studyについての行はありませんでした。 [root@rocky01 study]# mount | grep relatime sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) ---- 省略 ---- mount | grep noatime、mount | grep norelatimeは、なにも出力 されませんでした。 [root@rocky01 study]# mount | grep norelatime [root@rocky01 study]# [root@rocky01 study]# mount | grep noatime [root@rocky01 study]# ご紹介頂いたurlに以下の記述がありました。 「デフォルトでは、relatime が有効な状態ですべてのファイルシステムがマウントされるようになります。」 上記から、/root（およびその配下のディレクトリ） に対しては、デフォルト でrelatimeが有効化されているんおで、mount で、/root/xxxについての情報 が出力されないのかと推測しましたが、その様な理解で正しいでしょうか。 ご存じであれば、教えて下さい。 宜しくお願いします。
2023/07/27 投稿
fileコマンドでatimeが更新されない

この問題で、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]#

戻る