systemdのenvfileを普通のコマンド実行時に流用する - たごもりすメモ
普段はsystemd経由で実行しているコマンドをCLIから実行したい、環境変数もsystemd経由で起動するときと同様にセットしたいのでenvfile(EnvironmentFile)をそのまま使いたいんだけどなんか微妙にやりにくくないか、と思って何度か調べたことがあるんだけど、あんまりうまい方法が検索結果に出てこない。 んだけど、あれ、これ簡単じゃん。(追記: これはごく単純なケースでしか動かなかった、後段参照) $ env $(cat myenvfile | grep -v '^#') target-commandenvfileをシェルスクリプトとして実行して追加された変数をなんとかexportすれば……みたいに考えてたけどenvコマンドで一発だった。変なコメントとか入ってると厄介だけど、こんな感じでいいのでは。ということでメモ。 空白を含む値の処理 まあいいやとスルーしてたけど値が空
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
Page Scrolling Vertical Scrolling Horizontal Scrolling Wrapped Scrolling
Ubuntu 18.04 で OS 起動時の apt update と unattended-upgrade を抑制する方法 - （ひ）メモ
時間のない人向けのまとめ sudo systemctl edit apt-daily.timer sudo systemctl edit apt-daily-upgrade.timer どちらも次の内容で保存します。 [Timer] Persistent=false もしくは、直接ファイルを編集して反映してもよいです。 sudo install -d -o root -g root -m 755 /etc/systemd/system/apt-daily.timer.d cat <<EOF | sudo tee /etc/systemd/system/apt-daily.timer.d/override.conf [Timer] Persistent=false EOF cp -pR /etc/systemd/system/apt-daily.timer.d/ /etc/systemd/s
CentOS 7などのSystemdに対応したデーモンプログラムを作る
B! 82 0 0 0 RHEL 7系のCentOS 7などではそれまでRHEL 6系で使われていたSystem V系のinitから Systemdを用いたデーモン管理がベースになるようになりました。 CentOS 7でデーモンを自作したいものがあって作ったので 基本的な作り方についてまとめておきたいと思います。 Systemd (systemctl) デーモン本体作成 最小限の設定 サービスファイル rsyslogの設定ファイル logrotate インストール/アンインストールスクリプト 動作チェック まとめ Systemd (systemctl) initのときには/etc/init.d/の中にデーモン名の(通常)シェルスクリプトが入っていて、 このスクリプトがstartとかstopとかの引数を受ける様に作られ、 直接 # /etc/init.d/httpd start とかするか、
CoreOS Container Linuxにおいてリアルタイムプロセスを実行できない問題 - Cybozu Inside Out | サイボウズエンジニアのブログ
はじめに こんにちは、技術顧問の武内です。 本記事はサイボウズの次期インフラ開発チーム(Necoチーム)が遭遇した、CoreOS Container Linux (以降 CoreOS)においてリアルタイムプロセスを実行できないという問題について、次のようなことを記載したものです。 どういう問題なのか どのように根本原因を突き止めたのか 今後どのように対処するのか 問題要旨 本来なら成功するはずのroot権限におけるリアルタイムプロセスの実行が失敗する 根本原因 CoreOSではカーネルのリアルタイムグループスケジューリングという機能が有効になっている 同機能が有効な場合、cpu cgroup配下のプロセスはデフォルトではリアルタイムプロセスを実行できない systemd環境下で生成されたプロセスは何らかのcpu cgroupに所属させられる 対処方法 リアルタイムプロセスが属するcpu c
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)
Dockerじゃないsystemd-nspawn＋machinectlが非常に良い
前回、 自作FRPライブラリTimeEngineをブラッシュアップして http://timeengine.github.io/ を公開しました。 次回は、その日本語訳、 Reactの応用技術、あるいはReact再入門についての記事をUPしますのでお楽しみに！ と書いていたのですが、Dockerじゃないsystemd-nspawn＋machinectlが非常に良い、ので予定を変更して、こちらを先にエントリします。いろいろ印象を忘れないうちに。TimeEngineに関してはとりあえず自分がすでに英文で書いたものを和訳してどこかにUPしておいたほうが、何か別展開や国内のためになるかな程度のことなのでお急ぎの方は上記リンクから英文読んでください。そちらも全部仕上がっているとは言えないですし、行き届いていないところをセルフチェックするために和訳もしておこうという感じです。 実用的で枯れた技術「コン
systemd時代に困らないためのlimits設定 | 外道父の匠
数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール／SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上
systemd超入門 | DevelopersIO
これはとある勉強会用の資料です。スライド作るのが面倒臭くなったのでブログにすることにしました。 Systemdとは Systemdは、Linuxの起動処理やシステム管理を行う仕組みです。 Linuxの起動処理 Linuxの起動はざっくりと以下の4段階によって行われます。 電源投入によりBIOSが起動する。 BIOSからブートローダーが呼び出される。 ブートローダーがLinuxカーネルを起動する。 Linuxカーネルがinitプロセス(PID 1)を起動する。 このinitプロセスが、Linuxの起動処理を司ります。古くから使われていたのがSysvinitで、Sysvinitの代替えとして近年Ubuntuなどで採用されていたのがUpstartです。そしてFedora 15やCentOS 7、Red Hat Enterprise Linux 7で採用されたのがSystemdです。 System
systemdとcgroup - Plan9日記
systemdではcgroupを活用しているようだ。サービスごとにcgroupでアイソレーションされているので、関係するプロセスを一網打尽で殺せるし、サービスごとの資源利用量を観測できる。確かにpidをファイルに記録しておいて、殺すってのはダサいよね。流れとしてはユニットファイルでExecStopで指定されているコマンドを実行し、それでも当該グループのプロセスが残っている場合は、SIGTERM、SIGKILLの順でシグナルを投げるそうな。詳細はレッドハット中井さんの「Linux女子部 systemd徹底入門」とか。 次はsystemd-cgtopの実行例。 Path Tasks %CPU Memory Input/s Output/s / 86 0.3 197.3M - - /system.slice/NetworkManager.service 2 - - - - /system.sli
「Systemd」を理解する ーシステム管理編ー | ギークを目指して
前回の記事「Systemd」を理解するーシステム起動編ーでは、Systemdの概念とSystemdによるLinux起動プロセスの内容を解説させていただいた。第二回となる今回の記事では、Systemdを利用したシステムの管理方法を記載していきたいと思う。 今回の記事ではSystemdのsystemctlコマンドを利用したサービス（プロセス）管理方法と、journalctlコマンドを利用したSystemd journalログ照会の2章立てでSystemdによるシステム管理を解説させていただく。また、各コマンドは先日リリースされたCentOS7上で動作確認させていただいた。 systemctlを利用してサービスを管理する Systemd環境にてサービス管理を行う場合、主にsystemctlコマンドを利用するが、一部、従来のコマンドも利用可能となっている。使途別のコマンドを見ていこう。 Unitの
「Systemd」を理解する ーシステム起動編ー | ギークを目指して
2014年6月10日、とうとうRHEL7が正式リリースを迎えた。RHEL7での変更点については、このスライドに詳しく記載されているが、今回の記事では特に大きな変更点である「Systemd」について解説していきたいと思う。 Systemdは従来のinit/Upstartの代替であり、非常に高速なシステム起動・終了や、様々なシステム管理機能を提供する。ただし、その仕組みや管理方法は従来のinit/Upstartとは大きく異なり、init/Upstartに慣れ親しんだ方は習熟に時間を要するだろう。 Systemdは様々な機能と役割を持っているが、今回の記事ではSystemdによるシステム起動に焦点を当てた内容とさせていただく。Systemdを利用したシステム管理については、後日別の記事を投稿する予定だ。なお、当記事はRHEL7のベースとなっているFedora19を元に動作確認させていただいた。
Hello, systemd
8. SIGKILLしたらどうなるか # systemctl status httpd httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: active (running) since Thu 2014-07-24 03:57:50 JST; 1min 21s ago Main PID: 1311 (httpd) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service ├─1311 /usr/sbin/httpd -DFOREGROUND ├─1451
第1回 Linuxの起動プロセスとsystemd
Red Hat Enterprise Linux 7（RHEL7）では、「systemd」という新しいLinuxの起動処理とサービス管理の仕組みが導入された。システムの起動処理にかかる時間を短縮するなど、さまざまなメリットを備えている。 従来のバージョンであるRHEL5では「SysVinit」、RHEL6では「Upstart」という仕組みが採用されていた。systemdは、これらの仕組みとは大きく異なるプロセスで、Lnuxを起動する。systemdは従来の仕組みとどう異なるのか、それによってどんなメリットが得られるのか、詳しく解説していこう。 これまではシェルスクリプトでシステム起動を管理 SysVinitやUpstartでは、システムを起動してLinuxカーネルが動き始めると、最初にシェルスクリプト「/etc/rc.d/rcsysint」によって、ファイルシステムの整合性チェックとマウン
Systemdコマンド早見表(CentOS 7対応)
CentOS 7ではsystemdが導入されているので、サービスの管理が従来と大きく変わっています。詳しい解説はsystemd徹底入門のスライドを参照するとして、ここでは「前のコマンドはsystemdでどう入力するの？」というのだけ、簡単にまとめてみました。 サービス名にはsshdを指定していますが、もちろん任意のサービスが指定できます。 サービスの起動、終了など 操作SysV InitSystemd 起動/etc/init.d/sshd startsystemctl start sshd 終了/etc/init.d/sshd stopsystemctl stop sshd 強制終了PID探してkill -9systemctl kill -s 9 sshd 再起動/etc/init.d/sshd restartsystemctl restart sshd 設定反映/etc/init.d/s
Linus様がSystemdにぶちきれる
systemdは、/proc/cmdlineをパースして、もし、その中に"debug"という文字列を発見した場合、大量の冗長なデバッグメッセージをdmsegに出力する。これは様々な問題を引き起こす。まず、"debug"というあまりに一般的すぎる文字列に勝手に反応してしまうことがひとつ。dmseg、すなわちカーネルのリングバッファーをsystemdの冗長なデバッグメッセージだけで溢れ返させてしまうことがひとつ。そして、なぜかLinuxカーネルのブートに失敗してしまうことがひとつ。 Bug 76935 – Do not parse "debug" command line parameter カーネルコマンドラインに"debug"を与えると、systemdによりパースされる。適当なassertに引っかかると、こんな風にぶっ放される。 [ 150.308000] systemd-journald
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linux Network Interface Configuration With udev
Charming Python: Functional programming in Python, Part 3
Linux女子部 systemd徹底入門