vimのチートシート 基本 行番号の表示：カーソルモード（esc）を押した状態で、 :set nonumber 中堅 I : カーする業の行頭から挿入モードに遷移する gI: カーソル行の行頭から挿入モードに遷移 dd : カーソルがいる行を削除 ndd : カーソルがいる行からn行削除 e.g., 10dd : カーソルがいる行から10行削除 j : to down k : to up h : to the left l : to the right 複数選択 v : visual modeに入ってから、カーソルキーで複数選択。 さらにyをすることでやんく（こぴー）が可能。これは 応用
c/c++を使うならcmake! を使えるようになろう 前提知識 c/c++をライブラリとして提供するときに必要な奴ら /include, /lib, だよね。 /includeにはヘッダーが入っていて、/libには、コンパイルによって生成されたライブラリが入ります。hogehoge.soとか、hogehoge.aとか。 で、こいつらは基本的に、/usr/local/いかに格納されます。 ヘッダーについても説明しておく。ヘッダーは簡単にいうと、関数の入出力を規定したファイルです。 プログラムをビルドする流れは、コンパイルー＞リンク だけど、コンパイルの時点では、ライブラリとして読み込まれたファイルがどんな ヘッダーファイルの種類 ヘッダーファイルには２種類ある。 #include<stdio.h> #include "my_library.h" みたいな感じで、<>で囲まれているやつと、““で囲まれているやつ。<>は、システムのライブラリを読み込むときに使われます。システムライブラリのヘッダーは、/usr/local/includeとか、 /usr/include/に置かれます。ライブラリ (オブジェクトファイル) 本体は、/usr/libとか、/usr/lib64とかにおかれます。 一方、““はユーザが作ったライブラリを読み込むために使われます。““を使うと、コンパイラはカレントディレクトリの中で該当するヘッダーファイルを探します。 ライブラリとヘッダーは、一対一対応します。つまり、 プログラムからライブラリを読み出すときは必ず、ヘッダーでインクルードして、最後リンクする必要があります。 ユーザが定義したヘッダーでも同じです。まず、hogehoge.hppとhogehoge.cppを作って、コンパイルするときに g++ main.cpp hogehoge.cpp みたいな感じで、hogehoge.cppもコンパイルします。オブジェクトができて、最後にリンクしています。 コンパイルー＞リンクって流れを覚えておけば問題ないです。 サーチパスを追加したいときは、-Iで、ヘッダーのディレクトリ、-Lでライブラリのディレクトリをつけます。 ld (リンカー) がデフォルトで見に行くディレクトリパス LD_LIBRARY_PATH という環境変数で定義されています。これは変えられます。次のようにサーチパスを追加します。 export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH ちなみに、ldっていうのは、 Origins of the name "ld" are "LoaDer" and "Link eDitor" らしいです。知らんけど。 共有ライブラリと静的ライブラリ 共有ライブラリは、実行時に動的に読まれるのに対して、静的ライブラリは、コンパイル時に実行ファイルに組み込まれる。 どちらがいいかはわからないけど、共有ライブラリは、実行ファイル (実行バイナリ) の大きさが小さくなるよね。 ちなみに、共有ライブラリはShared Objectだから、.soっていう拡張子が付きます。一方、静的ライブラリは、 a collection of object files bundled together into a single archive fileなので、arichveの.aが付きます。 つまり、hogehoge.soとhogehoge.aですね。 ...
ことはじめ Linuxに関するいろいろなことをまとめてあるサイトを見つけたので、自分に有益な部分だけをまとめて行きたいと思う。 参考文献 これです 俺が思うLinux中級者向けのコマンド達 中級者というか、今の時点で俺が知らない、もしくは使いこなせていないコマンドって感じかな。 find ファイルを検索する。 find <検索パス> -name <ファイル名> ファイル名の一部 的にやるのもだいぶいいと思うけど。 useradd 新規ユーザの作成 id ユーザの確認 stress dmesg lsmod ロード済みのカーネルモジュール一覧を表示する ちなみに、カーネルモジュールとは「カーネルの機能を拡張するためのバイナリファイルです。 例としては、ディスク・ネットワークカード等をLinuxカーネルで使用可能にするためのデバイスドライバなどがあります。 デバイスドライバは各ハードウェアベンダーから提供されることが多いです。 初期のUNIX系OSでは新しいハードウェアを使うにはカーネルの再構築が必要でしたが、 現在のLinuxカーネルは、必要ありません。 起動時に常駐カーネルがメモリにロードされ、必要に応じてロード・アンロードが出来るようになっています。 です。いつか自分でも自作してみたいきはだいぶしていますねー。 modprobe カーネルモジュールのロード、アンロードを行うコマンド 「カーネルモジュールとは、Linuxカーネルの機能の一部を、カーネル本体とは別にロード、アンロードできるように分離したサイズの小さいバイナリファイルです。多くの場合、ハードウェアにアクセスし、操作するためのドライバ部分がカーネルモジュールとなっています。 ドライバ自体をカーネルに組み込む古い方式では、ハードウェア構成を変更した場合に、カーネルの再構築が必要になります。現在では、ほとんどのドライバがモジュールとして提供されているため、ハードウェア構成変更後は、必要なカーネルモジュールをロードしてカーネルに組み込むだけで対応できるようになっています。 modprobeは、モジュールの依存関係を確認し、必要なモジュールがあれば同時に組み込むといった処理も行います。モジュールの組み込みには内部的に「insmod」コマンドを用いており、取り外しでは「rmmod」コマンドを使っています。 」 ってことですね。 FHS (Filesystem Hierarchy Standard)について /bin コマンドファイルが入っている。すべてのユーザが利用するコマンドが保存されているディレクトリ。lsとか、echoとか。 ここに入っているコマンド全部覚えておいて損はないと思いますけどね。 bash fusermount netcat su bunzip2 grep netstat sync busybox gunzip networkctl systemctl bzcat gzexe nisdomainname systemd bzcmp gzip ntfs-3g systemd-ask-password bzdiff hciconfig ntfs-3g.probe systemd-escape bzegrep hostname ntfscat systemd-hwdb bzexe ip ntfscluster systemd-inhibit bzfgrep journalctl ntfscmp systemd-machine-id-setup bzgrep kbd_mode ntfsfallocate systemd-notify bzip2 keyctl ntfsfix systemd-sysusers bzip2recover kill ntfsinfo systemd-tmpfiles bzless kmod ntfsls systemd-tty-ask-password-agent bzmore less ntfsmove tar cat lessecho ntfsrecover tempfile chgrp lessfile ntfssecaudit touch chmod lesskey ntfstruncate true chown lesspipe ntfsusermap udevadm chvt ln ntfswipe ulockmgr_server con2fbmap loadkeys openvt umount cp login pidof uname cpio loginctl ping uncompress dash lowntfs-3g ping4 unicode_start date ls ping6 vdir dd lsblk ps wdctl df lsmod pwd which dir mkdir rbash ypdomainname dmesg mknod readlink zcat dnsdomainname mktemp red zcmp domainname modeline2fb rm zdiff dumpkeys more rmdir zegrep echo mount rnano zfgrep ed mountpoint run-parts zforce egrep mt sed zgrep false mt-gnu setfont zless fbset mv setupcon zmore fgconsole nano sh znew fgrep nc sleep findmnt nc.openbsd ss fuser nc.traditional stty /lib 共有ライブラリを保存するディレクトリです。 共有ライブラリが何なのかわかる？ ...
個人的基本 ローカルで新しいブランチ作成 git branch <new branch> ブランチ一覧を見る git branch ブランチ移動 git checkout <branch name> ローカルのブランチ削除 git branch -d <branch name> ローカルのブランチをリモートブランチにpush git push origin <branch name> originは省略できませんねー。お願いします。これでgithubに新しくブランチができます。 ちなみに、originはブランチ名ではなく、リポジトリ名です。つまり、githubのリポジトリをoriginで指定しています。 ファイルの差分を確認 git diff <filename> 作業していると、どのような変更を加えたか忘れてしまうこと多いと思うんですけど、これがあると、最後のコミットからどのような変更が加えられたのかが 一瞬でわかります。 個人的中級 ## リポジトリの特定のブランチをクローン git clone -b <branch_name> <repository_url> issue branchをmainにマージ まずmain branchに移動。その後、merge git checkout main git merge issue コンフリクトが起こったらその個所を直してコミット！！ 個人的上級 プルリクの送り方 前提として、何かしらのossを開発しているものとしましょう。まず、プルリクエストっていう概念は、gitではなく、github上のものなので、ローカルではできませんね。じゃあどうやるか？それを今から説明していくぜ。 まず、github上でforkします。forkしたものをローカルにcloneします。cloneしたものに変更を加えます。そして、githubにプッシュします。で、github上でフォークされたリポジトリから、コピー元となったリポジトリ (これをベースブランチと呼ぶらしいです)にプルリクエストを送るわけですね。 変更メッセージを指定して、レビュアーを指定して、Create pull requestをクリックすればプルリクエストの作成が完了するんですね。そうすると、プル陸タブにプル陸が表示されるようになるんだよね。 れびゅあーに指定できるのは、リポジトリのコラボれーた （共同編集者） となっているアカウント。 ちなみに、企業でいわれているコードレビューっていうのはこのプルリクエストを送る作業のことなんだと思います。 だから、去年のインターンの面接で「コードレビューをしてもらったことはありますか？」って聞かれたときにはい、あります、先生に見てもらってここをこうした方がいいとか、そういうアドバイスをもらいました、って言った俺は、意味が分かっていなかったわけですね。 mergeには3種類ある create a merge commit ：もっとも一般的 squash and merge rebase and merge : ブランチを一直線にする 特定のブランチorタグをcloneする git clone リポジトリ名 -b ブランチorタグ名 いちばんやさしいgit&Githubの教本を読んで新しく学んだこと forkはgithub上でリポジトリをコピーすること。 ...
バックグラウンド実行のあれこれについて ジョブをバックグラウンドで実行する方法は、実行したいジョブ、もしくはコマンドの最後に&をつける。 ./job.sh& みたいな感じで。しかしこれだとsshセッションが切れるとバックグラウンドで走っていたジョブも死んでしまう。 なぜか？ まずは親子関係について説明しよう。bashの親はsshdで、ジョブはbashの子供として生成される。そして、通常は、「親が死んだらinit (systemd)が親になってくれる」しかし、sshの場合はsshのセッションが切れるとkernelからbashにSIGHUPが送られる。さらに、bashが各プロセスにSIGHUPを送る。 バックグラウンドで走っているジョブを殺すSIGHUPシグナルを無視するためのコマンドがnohupである。これを使うことでプロセスはSIGHUPを無視するようになる。これは、disown -hでも同じである。先に実行するか後で実行するかの違い。 tmux/screen tmuxとかscreenを使おうという話です。screenの話をします。 screenコマンドについて セッションの保存方法 # creationg new session screen # detach the session <ctrl> + <a> d # creating new session with a name screen -S <name> # list the sessions and check the status screen -ls 実験 screenで新しいセッションを作ってその中でsingularityを動かす。 ps axfの結果は以下の通り。 28987 ? S 0:00 sshd: foo@pts/1 28988 pts/1 Ss 0:00 \_ -bash 29057 pts/1 S+ 0:00 \_ screen -S singularity 29058 ? Ss 0:00 \_ SCREEN -S singularity 29059 pts/2 Ss 0:00 \_ /bin/bash 29104 pts/2 Sl 0:00 \_ Singularity runtime parent 29125 pts/2 S+ 0:00 \_ /bin/bash --norc 意図的にbashを切る。 ps xfでログインユーザに関係するプロセスを一覧表示すると一見死んだかに思える。しかし、 ...
個人的、Linuxを触ってて面白かったとか、納得の行ったことをここにメモっておきたい。 disown -hについて sshでつないで、bashでプログラムを実行するとき、そのプログラムはbashの子プロセスとして実行されるのよね。 そもそもbashはsshdの子プロセスとして実行されるのだけれども。 でね、bashの子プロセスとして実行されるわけだから、bashを閉じるとその子プロセスであるプログラムも死ぬんだよね。 でも、bashを抜けても死なないでほしいプログラムってあるわけじゃないですか。それを実現する方法が プロセスを ctrl + zで一旦停止、bgでバックグラウンド実行。そして、disown -h なわけですね。 で、そうするとそのプロセスの親は誰になるか？って不思議に思いますよね。 1058 ? Ss 0:00 1 1080 13483 1836 0.0 /lib/systemd/systemd --user 1059 ? S 0:00 0 0 35244 1184 0.0 \_ (sd-pam) 2345 ? S 0:00 18 0 7408 2860 0.0 sudo hugo server -p 443 --bind=0.0.0.0 --baseURL=https://ingenboy.com/alpha/ 2346 ? Sl 0:18 38 0 2141188 1696712 43.7 \_ hugo server -p 443 --bind=0.0.0.0 --baseURL=https://ingenboy.com/alpha/ そうなんです。systemdなるんですねー。これが結構面白いところ。覚えておいていいです。 ちなみに、親子関係を含めて全プロセスを表示するのが、 ...
docker kubernetesの基本の基本 chapter 1,2 dockerはLinuxマシンを想定して作られている。cgroupがLinuxの概念だからね。 コンテナはイメージから作る コンテナはカーネルを持たない。が、カーネル以外のosの機能を持っている (本書ではそこを周辺部分と言っている)。カーネルはホストOSと共有する。だから軽い。 コンテナはdocker Engineがあればどこでも動く コンテナはイメージとして書き出すこともできる！ここがsingularityのsifとは違うところだね。おそらくDockerはデフォルトでsingularityのsandboxと同じように、中身の改変が可能なのではないか？と思っている。まだ確信には至っていない。 –> そのとおりです。dockerはどの時点においても動いているコンテナをイメージとして書き出すことができます。 そのときに使うコマンドが、commitです。 dockerでは物理的なマシンのディスクをマウントすることが可能。 コンテナの外部のディスクに書き込むことで、ほかのコンテナとデータを共有することができる。 dockerイメージはdocker hubからダウンロード可能 chapter3 dockerを使う dockerの環境構築方法が書いてあるだけでした。お疲れ様です。 chapter4 systemctl enable dockerでデーモンを自動起動させてください dockerコマンドの基本構文を抑えましょう docker <上位コマンド> <副コマンド> <オプション> <上位コマンド> == 何を <副コマンド> == どうする っていうのが結構しっくりきました。 ...
linuxを制すものはITを制す とはよく言ったものだ。 将来の夢はlinuxカーネルを理解することである自分ですが、まあ、そこへのかけ橋が必要ということで、「linuxの仕組み」を読むわけですね。裏表紙を見るだけで良本感が出ているこの本、さっそく読んでいきましょう ちなみに、筑波大学のこの人の授業もめっちゃためになります。 ref 1章：Linuxの概要 プログラムとは何か、プロセスとは何かを簡単に説明した後、カーネルの必要性について話しています。 これはかなり重要だけど、カーネルモードとユーザモードはcpuによって提供されている機能なんですね。カーネルモードで動いているプログラムは何の制限もないのに対して、ユーザモードで動いているプログラムには特定の命令を実行できなくする等、様々な制限がかかるんですね。 で、linuxの場合は、カーネルだけがカーネルモードで動作しています。つまり、プロセスはユーザモードで動いている、ということですね。だから、プロセスはカーネルを通じてデバイスにアクセスするのですが、この時にカーネルに操作をお願いする命令のことを「システムコール」というんですね。そうなんです、システムコールです。 カーネルの助けがないと実行できない処理をカーネルにお願いするんです。具体的には、nicを介した通信とかはそうですね。あとは、デバイスへのアクセス。プロセスの生成、削除。ファイルシステム操作。メモリ確保、解法。など。 システムコールが発行されると、cpuにおいて例外というイベントが発生するんですね。で、これをきっかけにcpuのモードがユーザモードからカーネルモードに遷移します。で、システムコールが終了すると再びユーザモードに戻ってプロセスが動くって感じですね。 で、straceコマンドってのがプログラムの中で発行されるシステムコール一覧を出してくれるんだよね。 strace python だけでもシステムコールがたくさん呼び出されることからも、pythonがインタープリタ言語であることがわかると思う。 前に研究室のサーバでwコマンドがハングしてしまう問題が起こったよね。そういう時は strace w とかってやると、wコマンド実行中のシステムコールがみられて、どこでハングしているのかとかがわかるわけですね。 こないだ調べた時は、特定のプロセスのプロセス情報 (/proc/<pid>/cmdlineとか) を閲覧しようとするとハングしてしまっていました。strace wとかするとreadシステムコールがハングするのがわかるはず。 ただ、なぜそうなってしまうのかはわかっていません…調べるとcgroupsによるメモリ制限と関係がありそうな情報が出てきましたが、まだ調査していません。 sudo yum install -y sysstat つぎのコマンドでsysstatを起動しましょう sudo systemctl start sysstat.service sarコマンドで遊びましょう。 sar -P 0 1 1 ちなみに、このコマンドの意味は、論理CPU0の(-P 0)のデータを1秒ごとに1回だけ収集しましょう。てこと。 sar -P 0 1 4 をやると次のような結果が出てくるよ。 Linux 5.15.32-v8+ (zeta) 09/02/23 _aarch64_ (4 CPU) 16:08:49 CPU %user %nice %system %iowait %steal %idle 16:08:50 0 0.00 0.00 0.00 0.00 0.00 100.00 16:08:51 0 0.00 0.00 0.00 0.00 0.00 100.00 16:08:52 0 0.00 0.00 0.00 0.00 0.00 100.00 16:08:53 0 0.00 0.00 0.00 0.00 0.00 100.00 Average: 0 0.00 0.00 0.00 0.00 0.00 100.00 この表の見方は、CPU 0がユーザモードで動作した時間の割合(%userと%nicdの和)、カーネルモードで動作した時間の割合(%system)、何もしていない時間の割合(%idle)って感じだね。 ...