ユニットファイルには、サービスやソケット、デバイスやマウントポイント、自動マウントポイントやスワップファイル／パーティション、起動ターゲットや監視対象のファイルシステムパス、タイマー制御や systemd による監督制御、一時的なシステム状態のスナップショットやリソース管理スライス、外部生成されたプロセスのグループなど、様々なものに対する情報が含まれています:

systemd では 「ユニットファイル」 という用語が多く現れますが、下記のような意味があります:

systemd のユニットファイルについてさらに詳しく知るには、 https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html をお読みください。

サービスを管理するためのサブコマンドは、 System V init でサービスを管理するためのサブコマンドとほぼ同じです (start , stop , ...) 。サービス管理コマンドの書式は下記のとおりです:

systemd では、複数のサービスを一括で管理することができます。 System V init ではそれぞれの init スクリプトを別々に動作させる必要がありましたが、 systemd では下記のように実行するだけです:

> sudo systemctl start 1_つめのサービス名 2_つめのサービス名

システムで利用可能な全てのサービスを一覧表示するには、下記のように実行します:

> sudo systemctl list-unit-files --type=service

下記の表では、 systemd と System V init における主要なサービス管理コマンドについて、その比較を行っています:

start

start

stop

stop

restart

restart

try-restart

try-restart

reload

reload

reload-or-restart

無し

reload-or-try-restart

無し

status

status

is-active

status

前のセクション内で説明しているサービス管理コマンドを利用することで、現在のセッションに対してサービスを制御することができます。 systemd ではサービスを恒久的に有効化したり無効化したりすることで、必要に応じて起動したり、もしくは常に利用できないようにしたりすることができます。これは YaST で行うことができるほか、コマンドラインでも実施することができます。

10.2.2.1 コマンドラインからのサービスの有効化／無効化 #Edit source

下記の表には、それぞれ systemd と System V init で有効化したり無効化したりするためのコマンドを示しています。

重要: サービスの起動

コマンドラインからサービスを有効化しても、サービスは自動では起動しません。時間のシステムの起動時や、ランレベル／ターゲットの変更時に起動されるよう設定されるだけです。有効化したあとにサービスを起動するには、 systemctl start サービス名 や rc サービス名 start を明示的に実行する必要があります。

表 10.2: サービスの有効化と無効化のコマンド #

処理	systemd のコマンド	System V init のコマンド
有効化：	systemctl enable サービス名_(複数可)	insserv サービス名_(複数可) , chkconfig -a サービス名_(複数可)
無効化：	systemctl disable サービス名_(複数可).service	insserv -r サービス名_(複数可) , chkconfig -d サービス名_(複数可)
確認： サービスを有効化しているかどうかを表示します。	systemctl is-enabled サービス名	chkconfig サービス名
再有効化： このコマンドは、サービスを再起動するのと同様に、いったんサービスを無効化して有効化し直します。サービスを既定値に戻したい場合に便利です。	systemctl reenable サービス名	(無し)
マスク： サービスを 「無効化」 したあとでも、手作業でサービスを開始することができます。マスクを実施すると、サービスを完全に無効化することができます。注意してお使いください。	systemctl mask サービス名	(無し)
マスク解除： マスクを設定したサービスは、マスクを解除しないと再度使用することができなくなります。	systemctl unmask サービス名	(無し)

System V init では、システムは 「ランレベル」 と呼ばれる状態に対して起動を行います。ランレベルは、どのようにシステムを起動するのかと、どのサービスを起動するのかを定義するものです。ランレベルは番号で設定されていて、よく知られているものは 0 (システムのシャットダウン), 3 (ネットワーク付きのマルチユーザ環境), 5 (ネットワークとディスプレイマネージャ付きのマルチユーザ環境) の 3 種類です。

systemd では 「ターゲットユニット」 と呼ばれる新しい考え方が導入されています。しかしながら、従来のランレベルの考え方と完全な互換性をもっています。ターゲットユニットには、番号ではなく名前が設定され、特定の用途ごとに用意されています。たとえば local-fs.target や swap.target などでは、ローカルのファイルシステムやスワップ領域をマウントします。

また、ターゲット graphical.target はネットワークとディスプレイマネージャ機能付きのマルチユーザ環境を表すターゲットで、これがランレベルで言うところの 5 に相当します。 graphical.target などは複雑なターゲットとして扱われていて、これは複数の他のターゲットを組み合わせた 「メタ」 ターゲットとして動作します。このように、既存の複数のターゲットを組み合わせることで、独自のターゲットを作成するだけの柔軟性を提供しています。

下記の一覧には、最も重要な systemd のターゲットユニットを一覧で示しています。完全な一覧は、 man 7 systemd.special をご覧ください。

System V init のランレベルシステムとの互換性を維持するため、 systemd には runlevelX.target という名前の特殊なターゲットが用意されています。ここで、 X には対応するランレベルの番号が入ります。

現在のターゲットを知りたい場合は、下記のコマンドを実行します: systemctl get-default

重要: systemd は /etc/inittab を無視する問題について

System V init システムでは、ランレベルを /etc/inittab で管理してきましたが、 systemd ではこの設定ファイルを 使用していません 。独自の起動可能なターゲットを作成する方法について、詳しくは 10.5.5項 「独自のターゲットの作成」 をお読みください。

systemd では、システムの起動処理を分析する機能を提供しています。全てのサービスの一覧とその状態を (/var/log/ などを処理することなく) 確認することができます。また systemd では、起動処理で時間のかかっている箇所を検出することもできます。

# systemctl
UNIT                        LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
iscsi.service               loaded active exited    Login and scanning of iSC+
kmod-static-nodes.service   loaded active exited    Create list of required s+
libvirtd.service            loaded active running   Virtualization daemon
nscd.service                loaded active running   Name Service Cache Daemon
chronyd.service             loaded active running   NTP Server Daemon
polkit.service              loaded active running   Authorization Manager
postfix.service             loaded active running   Postfix Mail Transport Ag+
rc-local.service            loaded active exited    /etc/init.d/boot.local Co+
rsyslog.service             loaded active running   System Logging Service
[...]
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

# systemctl --failed
UNIT                   LOAD   ACTIVE SUB    JOB DESCRIPTION
apache2.service        loaded failed failed     apache
NetworkManager.service loaded failed failed     Network Manager
plymouth-start.service loaded failed failed     Show Plymouth Boot Screen

[...]

systemd.log_level=debug systemd.log_target=kmsg

> dmesg -T | less

systemd は System V との互換性があるため、既に System V init スクリプトがある場合は、それらを使用することができます。ただし、 1 つだけ大きな問題があります。それは、 System V init スクリプトをそのまま systemd で動作させようとしても、動作しない場合があるという問題です。 init スクリプト内で su や sudo を利用してユーザを切り替えてサービスを起動している場合、スクリプトの実行が失敗して 「Access denied」 (アクセスが拒否されました) というエラーを発生させてしまいます。

su や sudo を利用してユーザを切り替える場合、 PAM のセッションが起動されることになります。このセッションは init スクリプトが完了したときに終了されますので、 init スクリプトから開始されたサービスについても、終了してしまいます。このエラーを回避するには、下記のようにしてください:

SUSE 製品に同梱される systemd ユニットファイルは /usr/lib/systemd/ に、カスタマイズしたユニットファイルやユニットファイルの ドロップイン は /etc/systemd/ にそれぞれ配置されます。

警告: カスタマイズを行う際の注意事項

systemd のカスタマイズは /etc/systemd/ 内で行うものとし、 /usr/lib/systemd/ 内では行わないでください。 /usr/lib/systemd/ でカスタマイズを行ってしまうと、次回の systemd の更新でそれらが上書きされて消えてしまいます。

ドロップイン・ファイル (または単に ドロップイン と記述する場合もあります) はユニットファイルの一部分のみを記述したファイルで、元のユニットファイルの一部分のみを修正するためのファイルです。ドロップインは元のユニットファイルより優先して解釈されます。たとえば systemctl edit サービス名 を実行すると、 /etc/systemd/system/サービス名.service.d/ ディレクトリを作成してその中に override.conf というファイルを作成し、既定のテキストエディタを起動してそのファイルを編集することができます。また、テキストエディタを終了すると、動作中の systemd プロセスに対して変更を通知します。

例として、 MariaDB の起動時に待機する時間をカスタマイズしてみることにします。 sudo systemctl edit mariadb.service コマンドを実行し、下記の内容を記述します:

# 起動または停止の際の待機時間
TimeoutSec=300

なお、 TimeoutSec の値は適宜変更して保存してください。変更をシステムに適用するには、 sudo systemctl daemon-reload コマンドを実行します。

詳しくは man 1 systemctl コマンドで表示されるマニュアルページを参照してください。

警告: ユニットファイル全体のコピーの作成について

systemctl edit --full サービス名 のように --full オプションを指定すると、元のユニットファイルをコピーしてから編集を行うようになりますが、元のユニットファイルは SUSE 側の更新によって内容が変化する可能性があるため、このような方式でのカスタマイズは推奨しません。カスタマイズを行う場合は、 /etc/systemd/system/ ディレクトリにカスタマイズしたい箇所のみを記述するようにしてください。またこれに加えて SUSE 製品では、ディストリビューションが独自にドロップイン・ファイルを提供する場合もあることに注意してください。この場合も --full で作成したドロップイン・ファイルが最優先で処理されます。このような理由から、混乱を防ぐために --full の使用は避けてください。

systemctl edit コマンドとは別に、ドロップイン・ファイルを独自に作成して優先順位を任意に調整することもできます。これらのドロップイン・ファイルは、元のユニットファイルを編集したり変更したりすることなく、ユニットやデーモンの設定を自由に変更することができるようになります。このような独自のユニットファイルは、それぞれ下記のディレクトリに配置します:

ヒント

ドロップインの検索パスの完全な一覧については、 man 5 systemd.unit で表示されるマニュアルページをお読みください。

たとえば systemd-journald の既定で設定されている流量制限を無効化したい場合は、下記のような手順を実施します:

注記: 名前の衝突回避について

ドロップイン・ファイルと SUSE が提供するファイルとの間で名前の衝突が起こらないように注意してください。一般的には、全てのドロップイン・ファイルのファイル名を 2 桁の数値とハイフンで始めてください。たとえば 80-override.conf のようになります。

なお、下記の数値範囲が予約されています:

• 0-19: systemd の提供元が使用します。

• 20-29: systemd 向けに SUSE が独自に使用します。

• 30-39: systemd 以外の SUSE パッケージが使用します。

• 40-49: その他のサードパーティ製パッケージが使用します。

• 50: systemctl set-property で作成されるドロップイン・ファイルが使用します。

上記に示した範囲よりも大きい 2 桁の数値を指定することで、 SUSE や systemd の提供元が設定する値を上書きできるようになります。

ヒント

なお、ドロップイン・ファイルでの上書き結果を表示したい場合は、 systemctl cat $UNIT コマンドを実行してください。

ヒント

なお、 systemd のコンポーネントに対する設定はファイルシステム内の様々なディレクトリに分散して存在しているため、全体の概要を知るのは難しいのが通常です。 systemd コンポーネントの設定を調査するには、下記のコマンドを使用してください:

• systemctl cat ユニットパターン: 1 つもしくは複数の systemd ユニットファイルの設定内容を出力します。たとえば下記のように実行します:

  > systemctl cat atd.service

• systemd-analyze cat-config デーモン名またはパス: systemd デーモンに対する設定ファイルとドロップインの内容をコピーします。たとえば下記のように実行します:

  > systemd-analyze cat-config systemd/journald.conf

openSUSE Leap 15 のリリース以降では、 xinetd のインフラストラクチャが削除されています。この章では、独自の xinetd サービスファイルを systemd のソケットファイルに変換する方法を説明しています。

それぞれの xinetd サービスファイルに対して、 2 つのsystemd ユニットファイルが必要になります。 1 つはソケットファイル ( *.socket ) で、もう 1 つはサービスファイル ( *.service ) になります。ソケットファイルでは systemd に対して、作成すべきソケットを指示し、サービスファイルでは起動すべきプログラムを指定しています。

たとえば下記のような xinetd サービスファイルがあるものとします:

# cat /etc/xinetd.d/example
service example
{
  socket_type = stream
  protocol = tcp
  port = 10085
  wait = no
  user = user
  group = users
  groups = yes
  server = /usr/libexec/example/exampled
  server_args = -auth=bsdtcp exampledump
  disable = no
}

systemd に変換するには、下記の 2 つのファイルを作成します:

# cat /usr/lib/systemd/system/example.socket
[Socket]
ListenStream=0.0.0.0:10085
Accept=false

[Install]
WantedBy=sockets.target

# cat /usr/lib/systemd/system/example.service
[Unit]
Description=example

[Service]
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
User=user
Group=users
StandardInput=socket

systemd の 「ソケット」 および 「サービス」 ファイルの全オプションを知りたい場合は、それぞれ systemd.socket と systemd.service のマニュアルページをお読みください (man 5 systemd.socket , man 5 systemd.service) 。

System V init の SUSE システムでは、ランレベル 4 は未使用で、管理者が独自のランレベル設定を作成できるようになっていました。 systemd では、必要に応じて任意の数のターゲットを作成することができます。作成するにあたっては、 graphical.target などの既存のターゲットから始めることをお勧めします。

systemd では、一時 (テンポラリ) ディレクトリを定期的にクリーニングする機能が用意されています。また、以前のバージョンのシステムに存在していた設定は、自動的に移行され有効化されます。 tmpfiles.d という一時ディレクトリの管理用ファイル、具体的には /etc/tmpfiles.d/*.conf , /run/tmpfiles.d/*.conf , /usr/lib/tmpfiles.d/*.conf の各設定ファイルを利用しています。 /etc/tmpfiles.d/*.conf 内にある設定は、残りの 2 つのディレクトリの設定を上書きするために用意されているディレクトリです (通常は /usr/lib/tmpfiles.d/*.conf 内にパッケージ側の設定ファイルが配置されます) 。

設定の書式は 1 行に 1 つずつアクションとパスを指定する形式で、必要であればモードや所有者、世代やアクションに応じたその他のパラメータなどを指定します。下記の例では、 X11 のロック (施錠) ファイルを削除しています:

Type Path               Mode UID  GID  Age Argument
r    /tmp/.X[0-9]*-lock

tmpfile タイマーの状態を取得するには、下記のように実行します:

> sudo systemctl status systemd-tmpfiles-clean.timer
systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
 Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
 Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago
   Docs: man:tmpfiles.d(5)
         man:systemd-tmpfiles(8)

Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.

一時ファイルの処理方法について、より詳しく知るには man 5 tmpfiles.d をお読みください。

10.6.9項 「サービスのデバッグ」 では、特定のサービスに対してログメッセージを閲覧する方法を説明しています。しかしながら、ログメッセージはサービスに限ったものではありません。 systemd 自身が生成した完全なログメッセージにアクセスしたり、それを検索したりすることもできます。 systemd では、ログメッセージを総称して 「ジャーナル」 と読んでいます。 journalctl コマンドを使用すると、最も古い記録から順に完全なログメッセージを表示することができます。フィルタの適用や出力形式の変更など、様々なオプションについては、 man 1 journalctl をお読みください。

systemd では、現在の状態を名前付きのスナップショットとして保存し、後から isolate サブコマンドで復元できる機能が用意されています。これは、任意の時点の状態にいつでも戻れるという機能から、サービスや独自のターゲットをテストする際に便利な機能です。ただし、スナップショットは現在のセッションに対してのみ有効で、システムを再起動すると自動的に削除されます。また、スナップショットの名前は .snapshot で終わらなければなりません。

systemd では、 /etc/modules-load.d 内に存在する設定ファイルに従って、システムの起動時に自動的にカーネルモジュールを読み込みます。ファイル名は モジュール名.conf という名前でなければならず、下記のような内容を記述します:

# モジュール を起動時に読み込む
モジュール名

特定のパッケージが、カーネルモジュールを読み込ませるために設定ファイルをインストールすると、そのファイルは /usr/lib/modules-load.d 内に保存されます。また、同じ名前の設定ファイルが /etc/modules-load.d 内にも存在すると、 /etc/modules-load.d 内に存在するもののほうが優先的に処理されます。

詳しくは modules-load.d(5) のマニュアルページをお読みください。

System V init では、サービスを読み込む際に何らかの処理を行う必要がある場合、/etc/init.d/before.local 内に記述を行っていました。 systemd ではこのようなファイルには対応していませんが、サービスの開始前に何らかの処理をする必要がある場合は、下記のようにして行います:

従来の System V init システムでは、サービスとして起動したプロセスを明示的には管理していませんでした。ただし、 Apache のようなサービスでは、 Apache 自身が必要な多数のプロセス (CGI や Java プロセスなど) を起動して管理していました。このような方法では、プロセスからサービスを探るのが難しくなってしまうか、場合によっては全く不可能になってしまっていました。これに加えて、サービスが正しく終了しなかった場合、子プロセスが残ったままになってしまう場合もありました。

systemd では、このような問題を cgroup で解決しています。 cgroup はカーネルの機能で、プロセスをまとめ、生成された子プロセスを階層構造型のグループとして管理する仕組みです。 systemd では、それぞれのサービスを別々の名前付き cgroup として管理しています。なお、非特権プロセスに対しては cgroup からの 「脱退」 は認められていませんので、サービスが起動した全てのプロセスを、効率的に名前で管理できるようになっています。

サービスに属する全てのプロセスを一覧表示するには、 systemd-cgls コマンドを使用します。たとえば下記のようになります:

# systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│   ├─session-102.scope
│   │ ├─12426 gdm-session-worker [pam/gdm-password]
│   │ ├─15831 gdm-session-worker [pam/gdm-password]
│   │ ├─15839 gdm-session-worker [pam/gdm-password]
│   │ ├─15858 /usr/lib/gnome-terminal-server

[...]

└─system.slice
  ├─systemd-hostnamed.service
  │ └─17616 /usr/lib/systemd/systemd-hostnamed
  ├─cron.service
  │ └─1689 /usr/sbin/cron -n
  ├─postfix.service
  │ ├─ 1676 /usr/lib/postfix/master -w
  │ ├─ 1679 qmgr -l -t fifo -u
  │ └─15590 pickup -l -t fifo -u
  ├─sshd.service
  │ └─1436 /usr/sbin/sshd -D

[...]

cgroup についての詳細は、 第10章 「カーネルコントロールグループ」 をお読みください。

10.6.6項 「カーネルコントロールグループ (cgroups)」 でも説明しているとおり、 System V init のシステムでは、プロセスとサービスとの関係性の管理が確実にできるという保証がありませんでした。これにより、サービスを終了させて全ての子プロセスを確実に終了させるということも難しくなっていました。サービスが正しく終了できない場合、子プロセスがゾンビとして残ってしまうこともありました。

それぞれのサービスを cgroup に閉じこめる、という systemd の考え方により、サービスの全ての子プロセスを明確に管理できるようになるほか、これによってこれらのプロセスそれぞれに対して、シグナルを送信できる仕組みも提供できるようになっています。サービスに対してシグナルを送信するには、 systemctl kill コマンドを使用します。利用可能なシグナルの一覧については、 man 7 signals をお読みください。

D-Bus サービスは systemd クライアントと systemd マネージャ (プロセス ID=1) との間のメッセージバスとなるサービスです。 dbus は単独のデーモンではありますが、初期化インフラストラクチャでは必須の構成部品です。

動作中のシステムで dbus を終了したり再起動したりする行為は、 PID 1 の終了や再起動と同様であり、 systemd のクライアント／サーバ間通信を破壊してしまい、 systemd が正しく動作しなくなってしまいます。

そのため、 dbus の終了や再起動は非推奨であるほか、サポートの対象外となっています。

dbus それ自身や dbus に関連するパッケージを更新した場合、システムの再起動が必要となります。システムの再起動が必要となっているかどうかを調べたい場合は、 sudo zypper ps -s と入力して実行してください。表示されているサービスの中に dbus が存在する場合、システムの再起動が必要となります。

なお自動更新の設定で、システムの再起動を必要とするパッケージの更新を行わないようにしている場合でも、 dbus は更新されてしまうことに注意してください。

既定では、 systemd はそれほど多くの出力を行いません。サービスが問題なく起動できた場合は、全く出力を返しません。失敗した場合にのみ、短いエラーメッセージを表示します。しかしながら、 systemctl status コマンドを使用すると、サービスの起動や動作に関して様々なデバッグメッセージを取得することができます。

systemd には独自のログ記録機構 (「ジャーナル」 と呼びます) が備えられています。これにより、サービスのメッセージと状態に関するメッセージの両方を取得することができます。 status サブコマンドは tail コマンドに似た仕組みであるほか、異なる形式でログメッセージを表示することができるなど、パワフルなデバッグツールとして便利な存在になっています。

タイマーユニットでは、間隔の指定だけでなく、具体的な日時を指定することもできます。

systemd のタイマーユニットにはそれぞれ対応するユニットファイルが存在しています。言い換えると、 .timer ファイルは、対応する .service ファイルを有効化し、管理する役割を担っていることになります。タイマーとしてユニットファイルを使用する場合は、 .service ファイル内に [Install] セクションを指定する必要はありません。これは、タイマー側で管理するためです。

systemd のタイマーユニットの基本を理解するため、例として foo.sh というシェルスクリプトをタイマーユニットで起動する場合を想定してみます。

最初に systemd のサービスユニットファイルを作成します。このファイルがシェルスクリプトの制御を行うことになります。テキストエディタを起動して、下記のような内容でサービスユニットファイルの設定を作成してください:

[Unit]
Description="Foo shell script"

[Service]
ExecStart=/usr/local/bin/foo.sh

このファイルを、 /etc/systemd/system/ ディレクトリ内の foo.service という名前で保存します。

次にタイマーユニットを作成します。テキストエディタで下記のような内容を記述します:

[Unit]
Description="Run foo shell script"

[Timer]
OnBootSec=5min
OnUnitActiveSec=24h
Unit=foo.service

[Install]
WantedBy=multi-user.target

上記の例では、 [Timer] セクションで対応するサービスユニットファイルを指定 ( foo.service ) し、起動間隔を指定しています。この例では OnBootSec を指定していますので、まずはシステムの起動後を基準として 5 分間隔でシェルスクリプトを起動することになります。また、 OnUnitActiveSec の指定も存在することから、ユニットの有効化から 24 時間が経過するタイミングでも起動することになります (つまり 1 日 1 回) 。また、 WantedBy の指定では、システムがマルチユーザターゲットに到達している場合にタイマーを開始すべきである旨を示しています。

単調タイマーの代わりに、 OnCalendar でリアルタイムタイマーを指定することもできます。たとえば下記のように指定すると、月曜日の 12:00 を開始時点として、週 1 回の間隔で対応するサービスを起動することができます。

[Timer]
OnCalendar=weekly
Persistent=true

ここでは Persistent=true を指定していますが、これはシステムが直前の起動時間を判断できない場合 (たとえばシステムの電源を落としていた場合) に、タイマーを即時に起動することを示しています。

このほか、 OnCalendar では 曜日 年-月-日 時:分:秒 のような書式で指定することで、特定の日時に起動を行うこともできます。たとえば下記のように指定すると、毎日 AM5:00 にサービスを起動することになります:

OnCalendar=*-*-* 5:00:00

cron と同様にアスタリスク記号で任意の数値を、カンマ区切りで複数の数値を指定することもできます。また、 2 つの値の間に .. を入れることで、連続した値を指定することもできます。たとえば下記の例は、毎月最初の金曜日の PM6:00 に起動する意味になります:

OnCalendar=Fri *-*-1..7 18:00:00

複数の日時を指定したい場合は、 OnCalendar の項目を複数に分割してください:

OnCalendar=Mon..Fri 10:00
OnCalendar=Sat,Sun 22:00

上記の例では、月曜日から金曜日までの AM10:00 と、週末の PM10:00 にそれぞれ起動する意味になります。

タイマーユニットファイルを作成したら、 /etc/systemd/system/ ディレクトリ内に foo.timer というファイル名で保存してください。ユニットファイルが正しく設定できているかどうかを確認するには、下記のようなコマンドを実行します:

> sudo  systemd-analyze verify /etc/systemd/system/foo.*

上記のコマンドを実行しても何も出力されなければ、問題なくユニットファイルが設定できていることを示しています。

タイマーを開始するには sudo systemctl start foo.timer を、システムの起動時にタイマーを有効化するには sudo systemctl enable foo.timer をそれぞれ実行してください。

タイマーは systemd のユニットとして扱われるため、管理も systemctl コマンドで行います。タイマーを起動するには systemctl start を、タイマーを有効化するには systemctl enable をそれぞれ実行してください。これに加えて、 systemctl list-timers を実行すると、現在有効なタイマーの一覧を表示することができます。有効になっていないタイマーも含めたい場合は、 systemctl list-timers --all を実行してください。