# systemd-analyze Startup finished in 666ms (kernel) + 2.171s (initrd) + 4.705s (userspace) = 7.542s kernel, initrd, userspace それぞれの合計時間をだしてくれる。 より詳細を知りたい場合は、blame オプションを使う。systemd-analyze blame の実行結果 # systemd-analyze blame 1.120s firewalld.service 1.032s network.service 987ms boot.mount 712ms tuned.service 574ms vboxadd.service 458ms vboxadd-x11.service 320ms systemd-vconsole-setup.service 293ms
A perhaps surprising consequence of Requires dependencies in systemd I tweeted: Oh right. This service restarted because I said 'Requires=rsyslog.service' & I updated rsyslogd (which restarted it). Moral: don't do that. The systemd.unit manpage tells you that this will happen if you read it carefully. In the section on Requires: If this unit gets activated, the units listed here will be activated
CentOS7ではなぜかmessagesログやsecureログに無用と思われるような多くのお知らせログが出力され、重要な内容を見落としてしまう可能性が高いように思われます。 そこでこれらの無用なログの出力を抑制し、ログを少しでもわかりやすくしてみます。 このCentOS7のサーバーは今のところふだん使いのパソコンを兼ねてバックアップサーバーとして使用している。 いまいちデスクトップ(GNOME3)が使いにくかったりわけのわからないアプリケーションエラーが起きたりで本サーバーとして使用するには不安だったが、OSのバージョンも7.2になってようやく少し安定してきたようだ。 でもコマンド等使いなれているということもあって本サーバーはまだしばらくこのままCentOS6で行こう。 ときにCentOS7ではまだサーバーとして本稼働していない段階なのにmessagesログ(/var/log/messag
systemd というと unit ファイルを書いてデーモンを起動して、というイメージが強いかもしれないけど、systemd-run を使うと単発のコマンドを systemd の管理下で実行できる。 こうすることで、CPUQuota=50% とか MemoryLimit=10M とか BlockIOWeight=10 のようにリソースを制限でき、しかも実行中に変更することもできる。 たとえば http://hb.matsumoto-r.jp/entry/2015/12/02/133448 にあるような CPU 使用率を制限しながら yes を実行する例だと、 % sudo systemd-run --scope --uid=eagletmt -p CPUQuota=10% yes > /dev/null Running scope as unit run-rcab5dc0a5f8e4620
systemdは~/.config/systemd/userにserviceファイルを置くことで、そのユーザー用のinit時の処理を動かすことができるんですね。基本的に使い方は通常と同じで、唯一違うのは--userをパラメータとして使用すること。詳細はArch Wikiを見ましょう。 このようにserviceファイルを書いたとして、 masami@kerntest:~$ cat ~/.config/systemd/user/foobar.service [Unit] Description=User's service file [Service] Type=oneshot ExecStart=/usr/bin/touch /tmp/test.txt RemainAfterExit=yes [Install] WantedBy=default.target このように実行します。 masa
オペレーティングシステムは、コンピュータのハードウェア管理、ファイル管理、データの入出力と管理、アプリケーションプログラムやユーティリティの実行、ユーザーとの対話などを効率的に行うための制御・処理プログラムの基本セットです。
cronの無い世界 systemdに移行するディストリが増えてきた昨今、cronが担っていた部分もsystemdに移行されてきています。初期のsystemdにはtimerがありませんでしたが、2013年にtimerユニットの実装が入り、だいぶ安定してきた感があります。また、昔はcron系のデーモンが必須パッケージだったディストリも、いまでは必須ではなくなってきています。crontabといえばUNIXの入門書にも載っていますし、POSIXでも定められたユーティリティです。systemdを採用しているディストリであっても、cron系のパッケージ(cronieやfcron)を入れればいいだけの話なのですが、少なくともcron系を使うかsystemdのを使うか選ばなければなりません(両方使うことも・・・できますが)。cronはちょっと使ったことがあるので、一度も使ったことがないsystemdのti
Systemdの仕組みをつかうと、自分で作ったコマンドを簡単にサービスとして登録することができます。 例として、hello worldを延々とファイルに書き込むコマンドをサービス化してみましょう。 1. コマンドを作る /opt/hello.sh というスクリプトを用意します。
結論(ショートカット) ディスクのマウントに失敗してもブートしてほしいときには、/etc/fstabでnofailオプションを付けます。 何をしたかったか サーバ運用を行っていると、OS用とは別にデータディスクを追加することがあると思います。アプリケーションサーバやサービスが使用するデータとOSを分けておくためです。データディスクはRAIDだったり、エンクロージャだったり、AWSでEBSだったりします。 ところがRAIDは崩壊したり、エンクロージャは線が抜けていたり、EBSは別のインスタンスを立ち上げるときにつけ忘れたりします。そのため、CentOS6ではデータディスクは/etc/fstabで第5オプションと第6オプションを0 0にしていたのでした。(正確には起動時に無視するかどうかは第6オプション) /dev/system/root / ext3 defaults 1 1 /dev/sy
$ rpm -q --changelog tmpwatch * 月 2月 11 2013 Miloslav Trma? <mitr@redhat.com> - 2.11-3 - Drop the cron.daily script, systemd default configuration handles the same places. systemdで管理するようになったのでcronからは削除されたらしい /usr/lib/systemd/system/systemd-tmpfiles-clean.timer /usr/lib/systemd/system/systemd-tmpfiles-clean.service $ ls -l /usr/lib/tmpfiles.d/ 合計 64 -rw-r--r-- 1 root root 91 6月 19 2014 abrt.conf -r
systemdにはsystemd-tmpfilesという機能が合ってテンポラリなファイルやディレクトリをsystemdを使って作ることができます。systemdを使うので使い道としてはシステムの起動時に作るというのが基本的なユースケースだと思います。 マニュアルはsystemd-tmpfilesとtmpfiles.dになります。 systemd-tmpfilesは設定ファイルに従ってディレクトリ/ファイルの作成をします。設定ファイルの置き場所は以下の3箇所があります。この中のどこにファイルを置くかというと/etc/tmpfiles.dが無難でしょうね。/runは大概のディストリビューションだとtmpfsでしょうし、/usr/lib/は基本的にディストリビューションが使いますし。 /etc/tmpfiles.d/*.conf /run/tmpfiles.d/*.conf /usr/lib/t
はじめに systemdを使っていて、以下のような理由でunitファイルを編集したくなることがあります。 起動用のコマンドラインオプションを編集したい 起動時に独自のフックを入れたい unitファイルがバグってて起動できない ここでは、systemdで既存のunitを編集するための2つの方法を紹介します。 unitファイルの差分だけを書く 個人的にはこちらの方法をおすすめします。 なぜなら、ほとんどの場合は設定を1〜2個編集するだけで済むはずで、新たにunitファイルを作るのはやりすぎだと思うためです。 この方法でnginx.serviceを編集したい場合は以下のコマンドを実行します。 このコマンドを入力するとエディタが立ち上がるので差分を書いて、保存して終了します。 差分は/etc/systemd/system/<unit名>.d/override.confに保存されます。 unitファ
「Systemd入門(4) - serviceタイプUnitの設定ファイル」で、[Service]セクションのオプション「PrivateTmp」を紹介しました。実はこの他にも、ファイルシステムのセキュリティ保護を図るオプションがあります。今回は、これらオプションの紹介に加えて、それがどのような仕組みで実装されているのかを解説します。 参考資料 systemd for Administrators, Part VI - Changing Roots systemd for Administrators, Part XII - Securing Your Services ファイルシステム保護オプション serviceタイプのUnitについて、[Service]セクションで次のようなオプションを指定できます。(念のため、PrivateTmpも再掲しています。) オプション 説明 ReadOnl
Linux Daily Topics 2014年10月8日「魚は頭から腐るんだよ!」─systemd開発者、Linusとコミュニティに噛みつく Linus Torvaldsの暴言癖はLinuxコミュニティではもはや「平常運転」と捉えられていることが多いが、このLinuxコミュニティの人間にとってはごくあたりまえの日常風景を、ときには激しく嫌悪する向きも存在する。 以前本コラムでも紹介したが、LinusのGKHことGreg Kroah-Heartmanに対する厳しい言葉に、IntelのSarah Sharpがブチ切れた経緯はまだ記憶にあたらしい。また、GNOME生みの親でSUSEの開発者でもあったMiguel de Icazaは何度かLinusを激しく批判したのち、「あんな独裁的な体制にはついていけない」とみずからLinuxコミュニティを去った。Linusとともに初期のカーネル開発に貢献し
systemdでネットワークが完全に立ち上がってからサービスを動かしたい場合のめもです。ありますよね、こういうケース。 で、Unitセクションにこんな感じで書くんですがこれだと上手く動かない場合があったりして困るわけです。 After=network.target そんな時に使えるのがsystemd-networkd-wait-onlineです。これを使うと確実にネットワークの起動後にサービスを起動できるようにできます。 使い方は簡単で、systemd-networkdとsystemd-networkd-wait-onlineをenableにするだけです。ようは↓ですね。 # systemctl enable systemd-networkd # systemctl enable systemd-networkd-wait-online 基本的にこれで問題ないはずですが、もしこれで上手く動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く