蚊帳の中の日記

ゆる〜りゆるり..hoge...fuga....fu.....zzzz

2019.08.05~08.11

8/5

  • 衝撃の人事発表
  • intellijとcacherの連携が良かった
  • スプリントタスクのプルリクを修正完了
  • ペアプロというかペア調査みたいな感じのことをした
  • 社内ツールでバグが出て、graphql周りのエラーだと判明。色々調査。初めてGraphQL周りを触ったかも
  • rebuild聞きながら帰る

8/6

  • レビュー
  • とある移行作業の検証を行う。デバック楽しい
  • 1on1して下半期目指すべき事が少し明確になった。やるぞ。
  • プルリクで色々議論した。問題を整理しきらないで実装を進めると、実装が分かりづらくなるので気をつけないと。でも議論楽しかった。

8/7

  • 諸々レビュー
  • PRの修正
  • とある移行作業の検証作業の続き。昨日で終わらなかったし、また問題点を見つけた。うーむ、難しい。こういう時Rspecが充実しているとデバックがやりやすいな〜と感じた
  • BigQueryのTIMESTAMPって、タイムゾーンの表記に少し癖があった。嘘だった。
  • BIさんに聞いたけど、最近のデータサイエンス周りのトレンドはTDからBigQueryに移っているらしい。ふーん。

8/8

  • とある移行作業の検証作業がやっと終わった!
  • ちょっと急ぎ案件が出てみんなで対応
  • 目標設定を一通り書き終えた
  • 夏休み明けに来る新卒くんの最初のメンターみたいなのを務めることに。務まるかな。。。頑張ろう。
  • とある機能の仕様についてAndroidエンジニアと会議

8/9

  • 夏休み前の最終日
  • 夏休み明けにメンターやることになったので、色々準備する

8/10

  • 実家に帰って老犬を愛でる
  • 明日中国に飛ぶので色々準備する

8/11

  • 中国初上陸!

これ、中国のホテルで書いてるんだけど、初日にして日本帰りたくなってきたw

2019.07.29~08.04

7/29
  • とあるライブラリのアップデートが完了。アップデート業ってめんどくさいイメージあるけど、意外とライブラリコードなど見れて面白かったりする。やっと出せて良かった。
  • とある移行作業の見積もり(これに時間かかってめっちゃ疲れた。でも、具体化出来ていなかったところを洗い出せたし、チームメンバーと色々話せて良かった)。
  • 移行作業系のPRレビューを諸々

 

7/30
  • 体調不良で午後から出社
  • いろんなPRレビュー
  • 移行作業の今後の進め方について、他職種の人と会議祭り。午後まるまる施策主導者の方や開発Dや開発メンバーに共有するのが大変だった。苦手な作業だけどやらないとダメなやつ。
  • ログ関連のバグを修正

 

7/31
  • 昨日の会議の続き。マジで会議しかしてない。今日、殆ど会議だった。人と喋るの慣れてないから疲れる。
  • 昨日のログ関連のバグを再度修正。
  • web+db pressのrails6の特集読んだけど、新しいコンポーネント群に今までよりどう嬉しいのか?…さらに疑問が湧いてしまった。

 

8/1
  • 日直担当
  • いろいろ問い合わせや雑作業
  • 会議後に、もろもろの関係各所に確認作業

 

8/2
  • 別で行われた作業のミスがあり、対応で午前中からリリース
  • 今日も日直担当。問い合わせや雑多作業を、諸々行う。
  • nginxの知識をつける機会があった。それに合わせてスプリントタスクの開発修正

 

8/3
  • 疲れが溜まってたし、外は暑いので、家でダラダラしてた
  • もうすぐアイスボーン発売するか、適当なクエストでリハビリしたけど、ヤバイ

 

8/4
  • 夏休み中の旅行の計画を練りまくる

 

総括感想

先週、今週と慣れないことして疲れた。次の週はもっと開発する事に集中できる時間が欲しい。

あと体力の衰えを感じてて、なんか運動しないと。

2019.07.22~28

毎日色々なことを経験しているはずなのだけど、暫く経つと自分が何をしていたのか思い出せなくて「自分は一体何をやっていたのだろう?」とよくわからない謎の喪失感を感じるときが最近よくあった。

何もやってないということはなくて、単純に色々なことを経験して思い出せないだけな気がしているので、せっかくブログもあるんだし、週記を今日から残していこうかなと思う。*1

今日は記念すべき1回目(さて、いつまで続くかな)


7/22(月)

  • インフラ関連のアカウントの整理
  • とある機能のABテストを実施するので、その処理の実装
  • ライブラリアップデート作業

7/23(火)

  • ログ基盤PJについて色々詳しい対応方法を調査
  • PRレビュー(結構重いのがあった)
  • チームの振り返り会

7/24(水)

  • いろんなPRレビュー
  • リリース作業(途中でエラーが出て、ちょっとハマった)
  • 見積もり作業

毎度思うけど、この見積もりをどこまで細かくやるべきかいつも迷う。他のところとかどうやってうまいことやってるのかな。。。

7/25(木)

  • いろんなPRレビュー
  • とある画像関連の施策で、実装上の仕様や懸念点を洗い出し
    • 割といままで触ったことがないJS周りのコードをデバックしながら既存仕様を再確認する作業だったので楽しかった
  • とある施策のスケジュールを調整
  • 自分の新しい目標の設定

目標設定、まだ迷っている...。

7/26(金)

  • 昼ぐらいに出社
  • ○ベン
  • お問い合わせ対応
  • とある画像関連の施策について、開発Dと話し合い
  • 開発主担当をしたツールの仕様について、改善点を提案されたので会議
  • 他の人の開発環境がバグったのでデバック

7/27(土)

  • OSS Gateにビギナーとして参加しました!
  • マインクラフト PS4ブックオフで買ったらドハマリした

7/28(日)

  • 昼ぐらいまで爆睡
  • イクラ
  • ニトリ珪藻土マットを買った(これ最高。うちの風呂場のQOL(?)が1UPした)。

総括感想

開発時間を捻出が課題と思った一週間


こんな感じかな。 仕事の内容は詳しく書けないので、抽象化してる。 継続していってみようっと。

*1:日記だと毎日書くのがだるいし、3日坊主確実だったので週記にすることにした。

OSSの門を叩いた土曜日

OSS Gateという体験ワークショップに初参加したのだけど、楽しくて、あっという間に時間が過ぎてしまった

oss-gate.doorkeeper.jp

参加のきっかけ

以前からOSS開発に興味はあったのだけど、正直何から始めればいいのかわからなかった。
普段からOSS開発している人の話を聞いたりすると、「とりあえずプルリク投げてみればいいじゃん」と言われるのだけど、その「とりあえず」がわからない。何かお作法はあるのか?英語がいいのか日本語がいいのか?どういった観点で、どういった粒度のプルリクを送ればいいのか?...色々な疑問や不安はあった。
そんな時、今年のRubyKaigiに参加した際にOSS Gateのことが紹介されていて、興味を持った。同僚の先輩も参加経験があり、話を聞いてみると「めちゃくちゃいいイベントだよ」と教えてくれたので、思い切って申し込んでみたのがきっかけ。

OSS Gateの概要

参加者は、ビギナー、サポータ、サポートメンターの3種類に別れている。*1
文字通り、ビギナーは僕のような初心者で、初心者をサポータが助けてくれる。サポータが困ったら、より知識があるサポートメンターの人が助けてくれて、更に知見が広がるような仕組みになっている(この仕組みは非常に良かった)。

進め方としては、難易度などは関係なく、ビギナーが何かOSSを一つ決めて、それを題材にOSSを実際に動かしてみることから始まる。そして、何かフィードバックができる観点を見つけたら、実際にPRを送ってみるという感じ。フィードバックを送るまでの間に実際どういった作業をしたのかは、OSS Gateのリポジトリがあり、そこにissueを立てて作業内容を逐一記録していく。

僕の記録は👇

github.com

会の途中で、2回ほど振り返りをする時間があり、その時間は自分を担当してくれたサポータ以外のサポータからアドバイスを貰う時間もある。

PRは、何かOSSのバグを見つけてきてPR送るような難易度が高いことからやるわけではなく、READMEの説明が足りないとか、ドキュメントのリンクが切れているなどの比較的小さな問題に対してフィードバックするのでも全く構わない。

参加前は「何かバグを見つけてPRを送るくらいまでやるのかな?大丈夫かな?自分に出来るかな」と少し不安だったけど、意外と敷居が低くて取り組みやすいフィードバックから見つけていくことも出来るので、やりやすかった。

あと、色々なサポータのアドバイスや知見を共有してもらえる時間が用意されているのは、有意義で最高と思った

個人的な観点で、会に参加して良かったなと思った事

  • OSSにPRを投げる初歩を学べた。そして実際にPRも送れた!
  • 何かバグを見つけてPRを送らなきゃ!と身構えなくても、ドキュメントの間違いやちょっとしたtypo修正だけでも色々PRチャンスがあることに気づけた
  • OSSによって文化やフィードバックの仕方に違いはあるので、READMEや他の人のPR、issueを見ることも参考になることを知れた。
  • OSSの開発者に、自分の送ったPRの意図がわかる説明を吟味することが重要だということを知れた。*2
  • コミット、ブランチ名、PRの説明。これらに、より神経を使うことが必要であることを知れた。
  • 英語の文法を気にしすぎるよりも、まずはエイヤッ!とPR投げてみる気持ちが大事(少し拙い英語でも開発者は理解してくれる事が比較的多いらしく、理解できなければ聞いてくるはず)。

自分が題材に上げたのは GitHub - fluent/fluent-logger-ruby: A structured logger for Fluentd (Ruby) 。最近業務で触る機会があったので、せっかくだから取り上げてみた。そして、PRを投げることにも成功。マージしてもらえるかな。ドキドキ。

github.com

実際、OSSをイチから触り始めると、意外とREADMEに説明がなくて詰まったりすることがあり「〜の説明があったのほうがOSSの利用者に親切なのでは?」という場面が多かった。
僕の場合、「どうすればよりわかりやすいドキュメントになるか?」という議論がサポータさんとの間で白熱して、結果的にプログラムにフィードバックするのではなく、ドキュメントのちょっとした更新のPRになった。意外とこういった比較的敷居が低そうな観点のPRチャンスもあるのだなとということを知れたのでは、個人的にとても新鮮だった。

PRを投げる前には、該当のOSSに何か作法はないか(issueテンプレなどあるか?他の人はどうやってPRを送っているか?)を調べたりしたが、大きい規模のOSSなどはissueテンプレなどが事細かに用意されてる一方で、自分が選んだOSSは特に何もなくてPRにissueのリンクが雑に貼られているだけになっており、ものによって雰囲気がぜんぜん違うのは、比べて見ていて面白かった。

あとは英語力。「英語の文法を気にしすぎるよりも、まずはエイヤッ!とPR投げてみるのが大事だよ!」とアドバイスもらった。確かに!と思いつつ、もっと英語をスラスラ書けると更に楽しいだろうな〜。

OSSの門を潜った実感のある1日だった

実は、会に参加する前に題材に上げたOSSのバグを踏んでいたので、それを今日の課題にしようと思っていたのだけど、会の直前に修正PRが出てマージされてるのを見つけてしまい、「やばい、今日の題材、どうしよう、、、」と焦ったりもした。
しかし、実際は簡単なところからOSSに取り組む作業を教えてもらったので、とても有意義な時間を過ごせた。仮に何もOSSに取り組む当てがなくても、イチから教えてくれるので、そういった方でも参加する価値がある会だと思う。

非常に楽しかったです。ありがとうございました。もう少し個人でOSSに取り組んでみて、そのうちサポータとして再参加してみたいなと思っております。

*1:OSS Gateは、以前ビギナーで参加した人は、任意で次の回の時にサポータとして参加することが可能。つまり、ビギナーを経験して慣れきたら、サポータとして再参加し、また新たなビギナーを助け、OSSコミュニティの和を広げていく事ができるような仕組みになっている(良い仕組みだ)。ただ、このサポータも最初はどうやってビギナーを助ければいいのか困る時がある。この時にサポータを援助してくれるのがサポートメンターという役割の人。比較的普段からOSSに参加してる強い人達がいるみたい。

*2:例えば、実際の作業・期待した結果・実際の結果という観点で説明を書くと流れが理解しやすくわかりやすかったりする

lpic 101 - level 1に合格したけど、実務で使えそうな知識をまとめてみる【コマンド探索編】

これで第3段。

コマンドを探したい時に、whichを使ってコマンドの絶対パスが調べたり、$PATHに含まれてるかどうか確かめたりすると思うが、他にも似たようなコマンドがあって自分の中の整理の意味でもまとめようと思う。

とあるコマンドやファイルを探したい!という時に覚えておくと便利そう。

which

指定したコマンドが格納されている絶対パスを表示する。

重要なのは、検索するディレクトリは、環境変数PATHに設定されているパスになる。つまり、環境変数PATHに設定されていないと見つけられない。とあるコマンドをインストールしたけど、パスが通ってなくてコマンドを打ってもCommand not foundになってしまうので、

export PATH="$PATH:/usr/local/bin"

した経験はあるはず。上のように$PATHに追加すれば、whichの検索対象になるというわけ。

whereis

whichと同じくコマンドが格納されているパスを表示するが、こちらは環境変数PATHを検索対象とせず、コマンドが格納されている標準的なディレクトリから検索してくれる環境変数PATH以外で探したい場合に便利。

コマンドをインストールしたはずなのにwhichで見つけられない!という時に、このコマンドで見つけられることがあったりする。*1

locate

今回、コマンド探索編というタイトルで記事を書いているので、このコマンドをこの記事で紹介するのは違う気がするけど、一応コマンド探索は出来るので紹介してみる。

コマンドに限らず、指定した検索パターンにマッチしたファイルなどもすべて表示してくれる。
ただちょっと難点があり、検索をするのにデータベースを構築する必要。そのデータベースを元にfindなどよりも高速な検索を行ってくれる。
もう一つ難点があって、そのデータベースは定期的に更新処理をしないといけないこと。まあ使う機会は殆ど無いコマンドだと思う*2

whatis

manコマンドで表示されるコマンド名と、省略された説明1行が表示される。

$ whatis ruby
erb(1)                   - Ruby Templating
irb(1)                   - Interactive Ruby Shell
ri(1)                    - Ruby API reference front end
ruby(1)                  - Interpreted object-oriented scripting language

検索対象はlocateと同じ感じでwhatisデータベースと呼ばれるデータベースファイルがあり、makewhatisまたはmandbで更新することが可能。これもデータベースの管理が面倒だし、whereisで見つけて、manで表示で事足りるので、余り使う機会はない気がしている。ただ、データベースを用意すれば検索は普通よりも早いらしい。

ちなみに、whatisman -fと同じ

*1:ちなみにバイナリファイルやマニュアル、ソースファイルが置かれている場所をオプションをつけて調べることも可能。

*2:じゃあ、なんで紹介したんだよ!!!

続きを読む

lpic 101 - level 1に合格したけど、実務で使えそうな知識をまとめてみる【テキスト処理系コマンド編】

前回の続き。

lpic試験では基本的なunixコマンドについても学べるのだけど、今回は普段あまり使ってなかったけど使ってみると非常に便利そうなテキスト処理系のコマンドjoin,cut,grep,sed….etc)を集めてみた。*1

テキスト処理系コマンドって便利

ちょっと前に達人プログラマーという本を読んだのだけど、第3章基本的なツールの19節に「テキスト操作」というのがあって、

正しく使えばこういったツール(テキスト操作言語やシェルなど)は驚くほど手際よく巧妙な成果物を生み出せます。しかし、マスターするのにはそれなりの時間がかかるのです。

と書かれている。まあ、覚えておかなくてもいいけど、ちょっと痒いところに手を伸ばしたい時に、今回のコマンドは非常に役に立つなと感じている。

grep, egrep, fgrep

grepは有名だけど、egrepfgrepというのもある。(この2つはどちらもgrepで出来ることなので、なぜあるのかよくわからないけど、トリビア要素としては面白かった)

  • egrep:拡張正規表現と呼ばれる普通の正規表現とは少し異なったパターンの正規表現を使う場合に使う。grep -Eと同じ。
  • fgrep:正規表現使わないgrep*?などを正規表現の特定文字ではなく普通の検索文字列として識別したい場合に利用する。例えば、fgrep ‘*’ hoge.txtgrep ‘\*’ hoge.txtは同じ。
最近良く使った手法
# -vで指定の文字列を除外 
grep -v ‘hoge’ sample.txt

# 複数文字列をOR検索(-eをつなげても出来るけど見づらくなる)
grep ‘hoge|fuga|hugo’ sample.txt

# 一致した行の前後の行も出力
grep ‘hoge’ sample.txt -A 10 -B 10

# 上の-vと組み合わせて、余計なログは省いてtail -fする
tail -f xxx.log | grep -iv 'hoge' | grep -Ev [poke|fuga]

…etc *2

正直自分のローカルマシン上だと、ptコマンド(Platinum Searcher)などを使って検索することが殆どだし、標準出力をパイプで渡して検索したいときなども、grepよりもpecoを使ってしまう(最近だとfzfがいいのかな)ことが多いから、ほぼgrepを使う機会はないのだけど、sshした先のlinuxサーバーにはそれらのツールはインストールしていない事が多いので、grepの使い方を覚えておくと便利だったりする。

sort

行単位でテキストファイルをソートしてくれる。デフォルトでは昇順になっている。csvとかリストファイルとかログファイルで、ちょっとしたソートをして表示したい時にたまに使える。

個人的には-bオプションで行頭の空白を無視してくれるのが便利で、行頭に空白があるテキストファイルでも特に気にせずにソートしてくれる。
あと-nをつけないと数値をテキストとして処理してソートしてしまうので、数値でソートしたいときは覚えておくと便利。

sort -b hoge.csv | pbcopy

uniq

入力されたテキストの中で重複している行を調べてくれる。
デフォルトなら重複を排除して表示してくれるのだけど、-dをつけると重複している行のみを出力する。-uなら重複していない行のみを出力する。

-uの方を使う機会が多くて、最近だと、とあるcsvファイルに重複した情報がないかどうかを確認する時に

uniq -d hoge.csv

ってやって、特に出力がなければ重複なしと判断したりした。便利。*3

wc

テキストの行数、単語数、バイト数を表示してくれる。 最近でかいcsvを扱う時に行数を確かめるために使いまくった。

xargs

標準入力で受け取ったテキストを引数にして、与えられたコマンドを実行する

# findでhogeという名前のファイルを見つけて、それらをrmする。
find . -type f -name ‘hoge’ | xargs rm

これだけではあまりは利点はなさそうに見えるけど、findするファイルが非常に多かったとき、rm *とかだとシェルの制限で削除するファイルが多すぎてエラーになってしまうことがある。でも、xargs経由で渡すとxargsがうまい具合にシェルの制限を超えないように処理してくれる。*4

split

指定した行数でファイルを分割してくれる。

これもでかいcsvを扱ったときの話なのだけど、そのcsvを分割したいとなって、その時はviエディタでシュッと分割したい行に移動して別ファイルに残りをコピペして分割するということをしたのだけど、splitを使えば一瞬だったな〜と反省した。ちょっとしたテキスト分割には重宝するはず。

tee

標準出力とファイル書き出しを両方を行ってくれる。文字通りT字に処理結果を分岐してくれることから、teeという名前らしい。

正直、勉強したときは「いつ使うんだ?」と思ったけど、以下の記事を見て「なんか覚えておいたら、かっこよそう!と思ってしまった。

www.atmarkit.co.jp

(番外)便利そうだけど使い道に困ってしまった子達

  • tr
  • join
  • nl
  • od
  • expand
  • unexpand
  • fmt
  • pr

jointrは工夫すれば使えそうな気はしているのだけど、まだ真価がわかっていない。どういったコマンドなのか、他も調べてもらえればわかるけど、正直「いつ使うの?」と感じてしまった。

*1:あくまでlpic 101 level1の試験範囲のコマンドに今回は限定している。

*2:全然簡単な使い方かも知れないけど、これくらいのことを新しく覚えておくだけでも出来ることが増えた実感がある

*3:ぐぐるとsortコマンドとの組み合わせが多く見られる感じがあるけど、他にも色々使い道はありそう

*4:ちょっと用法は違うけど、xargsで並列処理を実験してるqiita記事があって、面白かった。ref:

xargs のオプションいろいろ - Qiita

続きを読む

lpic 101 - level 1に合格したけど、実務で使えそうな知識をまとめてみる【systemd編】

先日lpic level 1 101試験を合格したのだけど、非常に勉強になったし、いままで触れていたlinuxの周辺技術の理解を更に深めることができた。

kayanaka.hatenablog.com

その中には実務で役立ちそうだなと思ったものもあれば、そうでないものもあったのだけど、せっかく役立つ方をまとめておけば、今後のためにもなりそうだったのでブログに書いておこうかと思った。

今回は、システムアーキテクチャの章で出てくる systemd辺りの話をまとめておこうと思う。

systemdとは?

ググれば幾らでも出てくる。自分なりにまとめてみると、linuxシステムで起動処理や起動時の設定などを行ってくれるシステムの一つSysVinitUpstartなどもあるがsystemdはそれらを更に改良したシステムで、自分が勉強した限りでは現在界隈で一番主流になっているシステム。
systemdのおかげで今まで直列型のようにシステムを起動していたのが、並列型のように起動できるようになったのでシステム起動が早くなったりした。また、いろいろなシステムの処理の設定・管理をUnitという単位で管理してくれたり、Service UnitをCLIから管理するためにsystemctlというコマンドも用意されていて、サービスの起動・停止・再起動などを行える。

webサービスを触っていて「nginxを再起動したいけど、どうするのかな」と思い、ググった結果「systemctl restart nginxでできるよ」と書いてる記事があったり、そうでない記事があったりで、自分はよく混乱したけど、systemctlを利用しているのは「systemdで管理しているnginx serviceをsystemctlで再起動する」ということ。linuxの知識が薄い自分にとっては、systemctlの正体を知るキッカケになった。

Unit

systemdはUnitと呼ばれる単位で処理を分けているといったが、このUnitもいくつか種類がある。service, swap, target’, device, mountが主な種類。特にwebサービスを触っているエンジニアなら、Service Unitを触る機会が多いはずで、linuxシステム上で管理している各種サービスはだいたいここに属するはず。
Unitの実態になる設定ファイル(Unitファイルと呼んだりする)は、/etc/systemd/system以下、もしくは/usr/lib/systemd/system以下にxxxx.serviceという拡張子で置かれている。ちなみにシステム起動時には、前者から後者の順で適用される。*1

実際にxxxx.serviceファイルの中身を見てみるとわかるのだが、そのサービスがインストールされたときの挙動や、systemctl restart,systemctl reloadなどのコマンドを送ったときの挙動が定義されていたりする。つまり、「systemctl hogefuga serviceを叩くと、どういった挙動になるのか?」は、Unitファイルを参照すると色々なことがわかるというわけ。

Unitという概念で各種サービスを管理してて、どこに設定ファイルがあるのか?これを知れただけでも、個人的に非常に勉強になった。 最近、Consulを通してどういったserviceが動いていて、それらserviceはどういった設定になっているのかをxxxx.serviceを見に行ったりする機会があり、ちょうど勉強した内容について触れられたのも良かった。多分、今後も役立ちそうな知識だ。

systemctlコマンド

man systemctlすると色んなオプションやサブコマンドがあるけど、まあ自分レベルが実務で今すぐ使えそうなのはこのくらいかなと思う。

  • systemctl start
  • systemctl stop
  • systemctl restart
  • systemctl reload
  • systemctl status
  • systemctl is-active
  • systemctl enable
  • systemctl disable
  • systemctl list-unit-files

is-activestatusがあるので、ほとんど使う機会がないかも知れない。

enable,diableは実際に叩いてみるとわかるのだけど、起動しているTarget配下にシンボリックリンクを作る or 削除することで、次回のシステム起動時に指定したserviceを自動起動するのかどうかを設定できる。
Targetは、Unitの種類の一つで、複数Unitをグループ化してくれる。主にmulti-user.targetrescue.targetなどのターゲットに分けられ、これをsystemdの起動時に最初に読み込む/etc/systemd/system/default.targetシンボリックリンクを貼れば、linux起動時に指定のtargetランレベル)を指定して、グルーピングされたUnitも順次起動するという仕組み。つまり、システム起動時にどんなサービスが自動起動するのだろう?というのを知りたければ、目当てのtargetの設定ファイルとディレクトリを見に行けば良い。

list-unit-filesは知らなかったのだけど、unitを一覧で見れて、覚えておくと使い所はありそうな感じ。

systemd-journald

systemdのプロセスには主に

  • メインプロセスである`systemd``
  • ログを管理するプロセスsystemd-journald
  • ログイン処理プロセスsystemd-logind
  • バイスの検知プロセスsystemd-udevd

などが存在する。
この中で特に実務で使いそうなのが、ログを管理するsystemd-journaldだと思う。サービスが予期せぬ事で停止してしまった時や不具合が起きた時にログを確認して、原因究明に役立てる。実際、このプロセスに対して指示を出すのは、systemctlと同じようにjournalctlというのがあり、それを使う。lpic101 level1ではよく出る題目ではないが、journalctl -xeとか、journalctl -u xxxx.serviceなどを叩く機会は多いかと思う。

自分も実務で「start叩いてるのに、なんかミドルウェアが起動しない!!」という場面があったりした時にお世話になった。各種サービスのログは、主にjournaldプロセスで管理していて、journalctlで見たりできることを覚えていれば、システム不具合等の時の調査で役立てられるはずだ。

———————

systemdは結構前からあるシステムで、ググったりすると私、systemd嫌いみたいなタイトルの記事も出てきたりで、良きところもあれば悪いところもあるらしい。でも、linux初学者の自分にとってLinuxシステムがどういった仕組みで動いているのかの基本的な内容を知れたのは、めちゃくちゃ良かった。

次はunixコマンドを辺りで、実務で役立ちそうな内容をまとめたいと思う。

*1:前者のディレクトリはホスト毎に修正されたUnitが置かれ、後者のディレクトリはユーザが作ったUnitを置く場所、という使い分けが一般的になっている。