はじめに 昨今では1行につき、1つの JSON を出力する様なログファイル形式も珍しくはありません。 grep しやすい データベース化しやすい これらの理由で各所で多く使われています。僕も仕事で普通に使っているのですが、ある日突然そのログファイルを集計するスクリプトで以下の様なエラーが出始めました。
grep の「バイナリファイル (標準入力) に一致しました」が出る条件を調べていたらそれは長い旅路の始まりだった。
はじめに 昨今では1行につき、1つの JSON を出力する様なログファイル形式も珍しくはありません。 grep しやすい データベース化しやすい これらの理由で各所で多く使われています。僕も仕事で普通に使っているのですが、ある日突然そのログファイルを集計するスクリプトで以下の様なエラーが出始めました。
2020年はsystemd-homedの登場でLinuxのユーザー管理が大きく変わるぞ - Qiita
これまでのLinuxでは、ユーザーの追加はuseraddで行われ、ホームディレクトリは/home以下にディレクトリとして作られ、ユーザーのアカウントは/etc/passwd、/etc/group、/etc/shadowで管理されていました。 これからは、systemd-homedがその全ての仕事を置換することになります。 ※タイトル詐欺感がありますが、従来の方式も並行して使えます。安心してください。 systemd-homedとは？ systemd バージョン245で追加された、ユーザー管理デーモン。実体はsystemdのサービスユニットファイルで、systemd-homed.serviceとして起動されます。 今後、ユーザーの管理や認証はsystemd-homed（以下、 homed ）によって行われることになるようですね。 出典が無く間違いだったため、訂正しました。systemd-ho
systemd serviceから呼ぶシェルではsudoではなくsetprivを使う - 赤帽エンジニアブログ
Red Hatの森若です。 自分でsystemdのservice unitを作るときに、起動用のいくつかのコマンドを記述したシェルスクリプトを呼ぶ事は(理想的ではないですが)あるかと思います。 今回はこの場合に、sudoを利用するとまずい理由を説明して、かわりにsetprivを使うほうがよいという話です。 例題用のservice 実行してみる 別のcgroupだと何がまずいのか? 対策はsetprivコマンド 例題用のservice sudoによるまずい動作を確認するためのできるだけ単純な例として、hoge.service を用意します。 /opt/hoge/hoge.sh #!/bin/bash sudo -u moriwaka sleep 5000 /etc/systemd/system/hoge.service [Unit] Description=hoge [Service] Ty
なぜsystemdなのか？ | POSTD
このブログ記事は2014年5月21日に行った私の講演の内容に基づいています。 ここ数年、GNU/LinuxのディストリビューションはSysV initを避ける傾向にあり、代わりに多種多様な新しいinitシステムへと移行が進んでいます。SysV initに満足しているユーザにとっては、これは予想外の流れでしょう。問題なく使えるのに、なぜ多くのディストリビューションはSysV initに背を向けているのでしょうか。 この記事ではSysV initの問題点と、それに対してsystemdがどんな解決法を提供しているのか説明してみようと思います。 私は特にsystemdの大ファンだというわけではなく、ただ広く使われているツールだという認識以上の思い入れは無いことだけお断りしておきます。 initシステムの役割とは何か？ コンピュータが起動する時には、ビルトインされたファームウェア（コンピュータの場合
Ubuntu 16.10 その7 - ローカルDNSリゾルバーの仕組みが変わる・systemd-resolvedの採用
「Ubuntu 16.10」では、現在のローカルDNSリゾルバーに代わり新しいローカルDNSリゾルバーが採用されます。 DNSリゾルバーとは DNSリゾルバーとは、ホスト名をIPアドレスに変換するサービスのことです。 例えばこのサイトにアクセスする場合、ブラウザーに「http://kledgeb.blogspot.com/」を入力します。 この時URLのホスト名は「kledgeb.blogspot.com」です。 ホスト名が文字列のままではサイトにアクセスできません。 サイトにアクセスするにはIPアドレスが必要です。 そこでブラウザーはDNSサーバーにホスト名に対応したIPアドレスを問い合わせます。 URLのホスト名の部分をDNSサーバーから取得したIPアドレスに置き換えます。 するとURLは、「http://192.168.0.1/」のようになります。 これでようやくこのサイトにアクセス
「Systemd」を理解する ーシステム起動編ー | ギークを目指して
2014年6月10日、とうとうRHEL7が正式リリースを迎えた。RHEL7での変更点については、このスライドに詳しく記載されているが、今回の記事では特に大きな変更点である「Systemd」について解説していきたいと思う。 Systemdは従来のinit/Upstartの代替であり、非常に高速なシステム起動・終了や、様々なシステム管理機能を提供する。ただし、その仕組みや管理方法は従来のinit/Upstartとは大きく異なり、init/Upstartに慣れ親しんだ方は習熟に時間を要するだろう。 Systemdは様々な機能と役割を持っているが、今回の記事ではSystemdによるシステム起動に焦点を当てた内容とさせていただく。Systemdを利用したシステム管理については、後日別の記事を投稿する予定だ。なお、当記事はRHEL7のベースとなっているFedora19を元に動作確認させていただいた。
第546回 journaldとsyslogの関係 | gihyo.jp
前回に引き続き、systemd-journald（以下、journald）について解説します。今回はrsyslogとの関わりを中心に、journaldを見ていきます。 journaldによるログの受信とrsyslogへの転送 systemd環境ではjournaldがシステムやサービスのログを一手に集めています。一方で、Ubuntuでは従来からのログ収集・格納サービスであるrsyslogが現在も稼働しています。おそらく、後方互換性のためと筆者は考えています。 詳しくは後述しますが、実際にはsystemd環境ではjournaldがまずシステム上のログを受け取り、必要に応じてrsyslogへログを転送しています。 たとえば、journaldは/dev/kmsgを通じてカーネルログを集めていますし、/dev/logより従来のsyslog宛てのログも集めています。もちろん、ネイティブのjournal
コラム - クラウド時代のオープンソース実践活用 | 第56回 RHEL7/CentOS7のjournaldでシステムログを一元管理｜CTC教育サービス 研修/トレーニング
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第56回 RHEL7/CentOS7のjournaldでシステムログを一元管理 (中井悦司) 2014年12月 はじめに RHEL7/CentOS7が公開されて数ヶ月が過ぎましたが、systemdやNetworkManagerなどの新しいコマンド体系にも馴染んできたでしょうか？ 今回は、systemdのシステムログ管理サービス「journald」について解説したいと思います。 journaldって何？ journaldは、systemdの環境で標準的に提供されるログ管理のサービスで、正式名称は、「systemd-journald.service」になります。次のように、systemdが管理するサービスの1つとして稼働していることが分かります。
「Systemd」を理解する ーシステム管理編ー | ギークを目指して
前回の記事「Systemd」を理解するーシステム起動編ーでは、Systemdの概念とSystemdによるLinux起動プロセスの内容を解説させていただいた。第二回となる今回の記事では、Systemdを利用したシステムの管理方法を記載していきたいと思う。 今回の記事ではSystemdのsystemctlコマンドを利用したサービス（プロセス）管理方法と、journalctlコマンドを利用したSystemd journalログ照会の2章立てでSystemdによるシステム管理を解説させていただく。また、各コマンドは先日リリースされたCentOS7上で動作確認させていただいた。 systemctlを利用してサービスを管理する Systemd環境にてサービス管理を行う場合、主にsystemctlコマンドを利用するが、一部、従来のコマンドも利用可能となっている。使途別のコマンドを見ていこう。 Unitの
Systemd入門(1) - Unitの概念を理解する - めもめも
Linuxの起動処理は、これまでinit/upstartと呼ばれる仕組みで行われていました。Red Hat Enterprise Linux 7 (RHEL7)では、これが、systemdと呼ばれるまったく新しい仕組みに置き換わります。Fedoraでは、すでに先行してsystemdが採用されていますが、この連載（？）では、Fedora 17での実装をベースとして、systemdの考え方や仕組み、利用方法を説明していきます。今回は、systemdの動作の基礎となる「Unit」の概念を理解します。 systemdを採用したFedoraでLinuxの基礎を学びなそう！という方には、「「独習Linux専科」サーバ構築/運用/管理――あなたに伝えたい技と知恵と鉄則」がお勧めです。(^^/ systemdの考え方 参考資料 ・Rethinking PID 1：systemdの開発者であるLennart
第557回 systemdのユニットの関係を読む | gihyo.jp
systemdではユニット（Unit）という単位でサービスやソケット、あるいは他のユニットをまとめるターゲットなどを管理しています。ユニット設定ファイルはプレーンテキストで書かれていて、これをsystemdが解釈してサービスやシステムの起動・停止を管理しています。 ところで、サービス同士やサービスとその関連するソケットの間では、「あるサービスは別のサービスが先に起動していないと使えない」「このサービスはあるソケットを必要としており、これよりあとに起動する必要がある」など、アクティベート順序（起動順序）や依存関係があります[1]。これらのアクティベート順序や依存関係もユニット設定ファイルに記載されていて、systemdが解釈し、適切に実行していきます。 今回は、このアクティベート順序や依存関係について、systemdのユニットの設定ファイルで使われる基本的なディレクティブとその設定を調
第598回 systemdユニットの設定を変える | gihyo.jp
第557回では、systemdユニットの依存関係を読む方法を紹介しました。 今回は、systemdユニットの設定を変更する方法を紹介します。 事前準備 systemdユニットの設定変更は最悪の場合、システムが正常に起動しなくなる恐れもあります。したがって手順を実際に試す際には、壊れても大丈夫なように検証用の仮想マシンなどを用意してください。 また、本稿では題材としてApacheの設定を変更する手順を解説しますので、以下のようにインストールしておきます。 $ sudo apt -y install apache2 systemdユニットの設定の在り処 さて、apache2パッケージのインストールが完了したら、systemdユニットを見てみましょう。ここは第557回のおさらいです。 インストール直後の状態だと以下のように表示されているはずです。 $ systemctl cat apache2.
SystemdForUpstartUsers - Ubuntu Wiki
Introduction This document compares Upstart and systemd with a view to aiding in the transition to the latter. Support status First, it is important to note that systemd is only fully supported in Ubuntu 15.04 and later releases. While systemd is available in prior releases through the Ubuntu repositories, there is a deemphasis of support for these releases as noted here. Hence, it is advised to u
systemd & systemctl - とみぞーノート
現在のtargetを変更するにはsystemctl isolateを使う。例えば、以下のようにするとRescueモード(シングルユーザモード)に遷移する。 # systemctl isolate rescue.target 現在のtargetを取得するには、systemctl list-units --type targetを使う。 # systemctl list-units --type target <略> graphical.target loaded active active Graphical Interface <略> multi-user.target loaded active active Multi-User System <略> ただし、targetには依存関係があり、このコマンドだと読み込んでいるtargetを全て表示してしまうので、結局どのtargetで動作し
起動が遅い原因は？そんな時はsystemd-analyzeでチェック
# 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
systemd/タイマー - ArchWiki
タイマーは名前が .timer で終わる systemd のユニットファイルであり、.service ファイルやイベントを制御します。cron の代わりとしてタイマーを使うことができます (#cron を置き換える を読んで下さい)。タイマーにはカレンダー時刻のイベントとモノトニック時刻のイベントのサポートが入っており、さらに非同期に実行することも可能です。 タイマーユニット タイマーは拡張子が .timer の systemd のユニットファイルです。他の ユニット設定ファイル と似ていますが特別に [Timer] セクションが存在します。[Timer] セクションにはタイマーが作動する時間と処理を定義します。タイマーには2つのタイプがあり、どちらか一つを使って定義されます: モノトニックタイマー は刻々と変わる開始点と相応したタイムスパンの後に作動します。様々なモノトニックタイマーが存
cron(crontab)の代わりにsystemdのtimerを使う - @znz blog
最近 gitlab omnibus などの環境を作っていて、GitLab CE の role でバックアップ処理を定期実行するのに crontab ではなく systemd の timer を使ってみました。 利点 systemd 管理下で統一的に扱えるので、覚えれば楽 ログも journald で統一されるので cron だといちいちメールが飛ぶと鬱陶しいような粒度でも簡単にログに残せる 環境変数なども含めた環境が本番と同じ状態ですぐに実行を試しやすい systemd 依存の機能が使える (後述の例では After と Requires) などが利点に感じました。 欠点 情報が cron (crontab) に比べてまだ少ないので、何かあったときに調べにくい systemd に大きく依存してしまう などが欠点に感じました。 確認環境 Ubuntu 16.04.2 LTS (xenial)
第555回 いま、あらためてudev | gihyo.jp
皆さん、ホットプラグってますか!? 猫も杓子もUSB端子なこのご時世、いろんなデバイスをPCに繋いだり取り外したりしていることと思います。そこで今回はデバイスの自動認識やデバイス名の設定など、システムの裏方として大活躍しているudevの基本を紹介します。 動的デバイス管理ツールudev udevとはsystemdの別名です。 すみません、言い過ぎました。Ubuntuで使われているudevは、systemdの一部として提供されるデバイスの認識に関わるデーモンでありツールです。もともとは独立したソフトウェアでしたが、2012年にsystemdと同じソースツリーから提供されるようになりました。ただしデーモンプロセスとしてはsystemd（PID=1）から独立しています[1]。 udevは具体的には次のような流れでデバイスを認識し、設定された作業を行います。 カーネルが追加・削除されたデバイスを
systemd サービスユニット覚書 - Qiita
initはもはや昔のしくみで、OS起動・停止時の制御はsystemdが行う。initよりも並列度を高める設計思想なので、HWの進化ともあいまって最近のOS起動はとにかく速い。 操作には冪等性があるし、Pre/Postといったライフサイクルフックな仕組みもあるので、応用の幅は旧式のinitと比べるとかなり広がっている。独自にシェルを組まずとも、ユニットファイルと呼ばれる定義ファイルをsystemdに食わせてやるだけでよい。 やはりなによりも統一されたインタフェースでサービスを操作可能というのがいい。起動・停止はsystemctlコマンドだけで済む。 というわけで、systemdサービスユニットファイルの覚書。 変更履歴 2019-02-26: Type=forkingで複数子プロセス生成時にcgroup内のプロセスが終了した場合の挙動を追加 2019-02-26: journal.confの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linux女子部 systemd徹底入門
