syslog vs journalctl：大規模サーバー運用におけるログ管理にはどっちが合理的？

大規模なサーバー運用において、ログ管理の設計はシステム全体の可観測性と障害対応速度を左右する重要な要素です。
特にLinux環境では長らくsyslogが標準的な仕組みとして利用されてきましたが、近年ではsystemdの普及に伴いjournalctlを中心としたジャーナルベースのログ管理が主流になりつつあります。

しかし、現場では依然として「syslogで十分なのか、それともjournalctlへ移行すべきか」という議論が残り続けています。
この選択は単なるツールの違いではなく、ログの永続化方式、検索性、運用コスト、分散環境との親和性といった複数の観点に関わるため、単純な優劣では判断できません。

例えば、それぞれの特徴を整理すると以下のようになります。

syslogは長年の実績があり互換性が高い
journalctlはバイナリ形式で高速な検索性を持つ
syslogはテキストベースで外部連携が容易
journalctlはsystemd統合により構成が一元化される

一方で、大規模環境ではログ量の増大や分散収集の設計がボトルネックとなり、どちらの方式も一長一短が明確に現れます。
そのため本記事では、単なる機能比較にとどまらず、実運用におけるスケーラビリティや障害解析の観点から両者を整理し、どのような条件下でどちらを選択すべきかを論理的に検討していきます。

syslogとは何か：Linuxログ管理の基本構造と役割
1. syslogのログアーキテクチャと運用上の特徴
journalctlとは何か：systemdジャーナルによるログ収集と検索
1. journalctlのバイナリログ構造と高速検索の仕組み
syslogとjournalctlの違いを比較：ログ形式・保存・検索性
大規模サーバー運用でのログ管理設計：スケーラビリティと分散収集
syslogが向いているケース：レガシー環境と互換性重視の運用
journalctlが向いているケース：systemd環境と高速トラブルシューティング
ログ収集基盤の選択肢：Fluentd・Grafana Loki・ELKスタックの活用
syslogからjournalctlへの移行戦略：ハイブリッド運用と注意点
結論：syslogとjournalctlの合理的な使い分け

syslogとは何か：Linuxログ管理の基本構造と役割

Linuxにおけるsyslogは、システムやアプリケーションが出力するログメッセージを一元的に収集し、適切なファイルやリモートサーバーへ転送するための古典的かつ標準的な仕組みです。
設計思想としては「シンプルで分散可能なログ転送基盤」であり、長年にわたりUNIX系OSの運用を支えてきました。

syslogの本質は、各プロセスが生成したログをsyslogデーモンが受け取り、ルールに基づいて振り分ける点にあります。
この仕組みにより、ログの保存先を柔軟に制御でき、例えば重要度や施設ごとに異なるファイルへ分離することが可能です。
結果として、障害解析や監査ログの追跡が比較的容易になります。

ただし、syslogはテキストベースの設計であるため、ログ量が増加するとI/O負荷や検索効率の低下が課題になります。
そのため大規模環境では、単体での運用ではなく補助的なログ収集基盤と組み合わせることが一般的です。

syslogのログアーキテクチャと運用上の特徴

syslogのアーキテクチャは「送信元」「デーモン」「保存先」という非常に明快な構造を持っています。
アプリケーションはsyslog APIを通じてログを送信し、syslogdやrsyslogといったデーモンがそれを受け取り、設定ファイルに基づいて振り分けを行います。

例えばrsyslogでは、以下のような設定によりログの分岐が可能です。

authpriv.*    /var/log/secure
mail.*        /var/log/maillog
*.info        /var/log/messages

このようにルールベースで処理できるため、運用担当者はログの整理方針を比較的直感的に設計できます。
一方で、ルールが増えるほど設定が複雑化しやすく、管理コストが上昇するという側面もあります。

さらにsyslogはネットワーク越しのログ転送にも対応しており、複数サーバーのログを集中管理する構成も一般的です。
しかし転送は基本的にUDPベースであることが多く、信頼性やセキュリティの面では追加設計が必要になるケースがあります。

このようにsyslogは「軽量・互換性・柔軟な転送」を強みとする一方で、大規模かつ高頻度なログ処理には工夫が求められる設計です。
現代のインフラでは、他のログ基盤と組み合わせて使われることが増えている理由もここにあります。

journalctlとは何か：systemdジャーナルによるログ収集と検索

journalctlは、systemdが提供するジャーナル機構に蓄積されたログを閲覧・検索するためのコマンドであり、従来のsyslogとは異なるアプローチでログ管理を実現しています。
最大の特徴は、ログをテキストファイルではなく構造化されたバイナリ形式で保存する点にあり、これにより高速な検索とメタデータの一元管理が可能になります。

従来のsyslogが「ファイルを追記していくモデル」であるのに対し、journalctlは「構造化データベースに近いログストア」を採用しているため、単なる文字列検索に依存しない柔軟なフィルタリングが行えます。
その結果、障害解析やパフォーマンス調査において、必要な情報へ迅速に到達できる設計になっています。

journalctlのバイナリログ構造と高速検索の仕組み

journalctlの内部では、ログはバイナリ形式で保存され、各エントリに対してタイムスタンプ、プロセスID、ユニット名、優先度といったメタデータが付与されています。
この構造により、単純な時系列ログではなく「属性付きイベント」として扱われる点が重要です。

この設計により、例えば以下のような条件検索が可能になります。

journalctl _SYSTEMD_UNIT=nginx.service --since "1 hour ago"

このように特定のサービス単位や時間範囲で即座にフィルタリングできるため、大規模システムにおけるログ解析効率が大幅に向上します。

さらにjournalctlはインデックス機構を内部に持ち、ログ全体を逐次スキャンする必要がありません。
そのためログ量が増加しても検索速度が比較的安定しており、syslogのようにファイルサイズ増大に比例して性能が劣化しにくいという特徴があります。

また、ログの圧縮保存やジャーナルのローテーションもsystemd側で自動管理されるため、運用者が手動でログファイルを分割・整理する必要がほとんどありません。
ただし一方で、バイナリ形式であるがゆえに直接テキストとして扱いにくく、外部ツールとの連携にはjournalctl経由の抽出が前提となる点は設計上のトレードオフです。

このようにjournalctlは、構造化データとインデックス検索を前提とした現代的なログ管理方式であり、特にsystemdベースのシステムにおいて強力な可観測性を提供する仕組みだといえます。

syslogとjournalctlの違いを比較：ログ形式・保存・検索性

syslogとjournalctlはどちらもLinuxにおけるログ管理の中核を担う仕組みですが、その設計思想は大きく異なります。
syslogはUNIXの伝統に基づいたシンプルなテキストログモデルであり、journalctlはsystemdの登場とともに設計された構造化ログシステムです。
この違いは単なる実装差ではなく、運用思想そのものの違いとして理解する必要があります。

まずログ形式の観点では、syslogはプレーンテキストを基本としています。
人間が直接ファイルを開いて読めるという利点があり、grepやawkなどの標準的なCLIツールと相性が良いという特徴があります。
一方でjournalctlはバイナリ形式でログを保存するため、直接ファイルを読むことは想定されていません。
その代わりにメタデータ付きの構造化ログとして扱われ、フィルタリングや集計が効率的に行えるよう設計されています。

次に保存方式の違いを整理すると、syslogはファイルベースであり、ログローテーションや圧縮は外部ツール（logrotateなど）に依存します。
これに対してjournalctlはsystemd-journaldが内部でログを管理し、自動的にローテーションやディスク使用量制御を行います。
この違いは運用負荷に直結し、syslogでは運用設計の自由度が高い反面、設計ミスによるディスク逼迫リスクも存在します。

検索性については両者の差が最も顕著です。
syslogは基本的にテキスト検索であり、以下のような形で利用されます。

grep "error" /var/log/messages

この方式は単純で分かりやすいものの、ログ量が増えるとスキャンコストが比例して増大します。
一方journalctlはインデックス化された構造を持つため、以下のような属性ベース検索が可能です。

journalctl -p err --since "2026-05-01"

この違いにより、大規模環境では検索効率に大きな差が生まれます。

さらに運用上の観点から両者を比較すると、以下のような特徴が整理できます。

観点	syslog	journalctl
ログ形式	テキスト	バイナリ＋メタデータ
保存管理	外部ツール依存	systemd内部管理
検索方式	逐次スキャン	インデックス検索
可搬性	高い	systemd依存
運用自由度	高い	標準化されている

この表からも分かる通り、syslogは「汎用性と互換性」に優れ、journalctlは「検索性能と統合性」に優れています。

重要なのは、どちらが優れているかという単純な二元論ではなく、システムの規模や運用ポリシーに応じて適切に選択することです。
例えばレガシーシステムや異種環境との連携が多い場合はsyslogが有利ですが、systemdベースで統一されたクラウドネイティブ環境ではjournalctlの方が合理的な選択になることが多いです。

このように両者の違いは技術的仕様だけでなく、インフラ設計の思想そのものに深く関わるため、単純な置き換えとして考えるのではなく、役割分担として理解することが重要です。

大規模サーバー運用でのログ管理設計：スケーラビリティと分散収集

大規模サーバー運用におけるログ管理は、単なる「記録の保存」ではなく、システム全体の健全性を維持するための基盤設計そのものです。
サーバー台数が数十から数千規模に拡大すると、各ノードで発生するログ量は指数的に増加し、単一サーバーでの管理は現実的ではなくなります。
そのため、スケーラビリティと分散収集の設計が極めて重要になります。

まずログのスケーラビリティという観点では、処理性能と保存容量の両方を同時に考慮する必要があります。
ログは常に増え続けるデータであるため、ストレージ設計を誤るとディスクフルによるサービス停止を引き起こすリスクがあります。
また、ログ解析の負荷が増大すると、障害発生時の原因特定が遅延し、復旧時間にも直接影響します。
このため、ログ処理系は水平スケール可能であることが望まれます。

次に分散収集の設計ですが、一般的にはエージェント型とストリーム型の2つのアプローチがあります。
エージェント型では各サーバーにログ収集プロセスを配置し、中央のログサーバーへ転送します。
一方ストリーム型では、ログイベントをメッセージキューやストリーミング基盤に直接流し込み、リアルタイム処理を行います。

この構造の違いは、syslogとjournalctlのようなローカルログシステムとも密接に関係します。
syslogは比較的軽量であるためエージェント型と相性が良く、journalctlはローカルでの構造化ログ管理を前提とするため、外部へは抽出・転送する設計が必要になります。

実際の大規模環境では、以下のような構成が一般的です。

層	役割	技術例
収集層	各サーバーからログ取得	syslog, journald
集約層	ログの統合と転送	Fluentd, Logstash
保存層	長期保管と検索	Elasticsearch, S3
可視化層	分析・監視	Kibana, Grafana

このような多層構造にすることで、各コンポーネントの責務を分離し、システム全体のスケーラビリティを確保できます。

さらに重要なのは、ログの「リアルタイム性」と「コスト」のトレードオフです。
リアルタイム分析を重視するとストリーミング基盤が必要になり、コストと設計複雑性が増加します。
一方でバッチ処理中心にするとコストは抑えられますが、障害検知の遅延が発生します。
このバランスはシステムのSLA要件によって最適解が変わります。

また、ログフォーマットの統一もスケーラビリティに直結します。
JSON形式のような構造化ログを採用することで、後段の解析基盤との親和性が高まり、クエリ性能の向上にも寄与します。

最終的に、大規模環境におけるログ管理設計は単一技術の選択ではなく、複数レイヤーの統合設計です。
syslogやjournalctlはあくまで「収集の入口」に過ぎず、その後の集約・保存・解析まで含めた全体設計こそがスケーラビリティを決定づける要因になります。

syslogが向いているケース：レガシー環境と互換性重視の運用

syslogは長い歴史を持つログ管理機構であり、その最大の強みは「互換性」と「汎用性の高さ」にあります。
現代のsystemd環境ではjournalctlが標準となりつつありますが、それでもsyslogが依然として選択され続ける理由は、既存システムとの親和性と運用の柔軟性にあります。
特にレガシー環境や異種混合システムでは、その価値が顕著に現れます。

まずレガシー環境においては、多くのアプリケーションやミドルウェアがsyslog前提で設計されています。
これは単純に古いという意味ではなく、長年安定稼働してきた実績に基づく設計思想です。
そのため、ログ出力インターフェースを変更することなくシステムを維持できる点は、運用コストの観点で非常に重要です。

またsyslogはテキストベースであるため、ログの可読性が高く、トラブルシューティング時に直接ファイルを確認できるという利点があります。
これは自動化されたツールが利用できない緊急時において特に有効です。
例えば以下のように単純なコマンドで状況を把握できます。

tail -f /var/log/messages

このようなシンプルさは、障害対応の初動において重要な役割を果たします。

さらに互換性という観点では、syslogはUNIX系OS全体で標準的にサポートされているため、LinuxだけでなくBSD系やネットワーク機器との統合にも適しています。
ルータやファイアウォールなどの機器は今なおsyslog転送を前提としていることが多く、インフラ全体のログ統合を考える際には無視できない要素です。

運用面では、syslogは設定の自由度が高いという特徴もあります。
rsyslogやsyslog-ngなどの実装を利用することで、ログのフィルタリングや転送ルールを柔軟に定義できます。
この柔軟性は一方で複雑性にもつながりますが、既存運用フローに合わせたカスタマイズが可能である点は大きな利点です。

また、syslogは外部ログ基盤との連携にも適しています。
例えばELKスタックやFluentdと組み合わせることで、収集・加工・可視化のパイプラインを構築できます。
このときsyslogは「最も互換性の高い入力層」として機能し、既存資産を活かしながらモダンな分析基盤へ移行する橋渡し役となります。

観点	syslogの特徴	適合理由
互換性	非常に高い	旧システムや機器と連携可能
可読性	テキスト形式	緊急時に直接確認可能
軽量性	軽量	オーバーヘッドが小さい
拡張性	設定ベースで柔軟	ルール制御が可能

このようにsyslogは、最新のログ基盤と比較すると機能面で劣る部分もありますが、それ以上に「既存環境との親和性」という現実的な価値を持っています。
特に長期運用されているオンプレミス環境や、異なるベンダー機器が混在するネットワークでは、syslogの安定性と互換性は依然として重要な選択理由になります。

したがってsyslogは単なる旧式技術ではなく、レガシー資産を維持しながら安定運用を継続するための現実的な選択肢として、今なお明確な役割を持ち続けています。

journalctlが向いているケース：systemd環境と高速トラブルシューティング

journalctlはsystemdに統合されたジャーナルシステムを基盤としており、特にmodern Linux環境におけるログ管理に最適化されています。
その最大の強みは、ログが構造化データとして保持されることによる検索性能と、systemd全体との強い統合性にあります。
これにより、従来のsyslogでは困難だった高速なトラブルシューティングが可能になります。

まずsystemd環境との親和性についてですが、journalctlは単なるログビューアではなく、systemdが管理するあらゆるユニットの状態と密接に連携しています。
サービスの起動・停止・失敗といったイベントはすべてジャーナルに記録されるため、障害解析時にはシステム全体の状態遷移を時系列かつ属性付きで追跡できます。
この点はsyslogにはない大きな特徴です。

例えば特定のサービスに関するログを確認する場合、以下のように非常に直接的なクエリが可能です。

journalctl -u sshd.service --since "today"

このコマンドにより、対象ユニットのログだけを抽出できるため、複数サービスが混在する環境でも情報のノイズを大幅に削減できます。

次に高速トラブルシューティングの観点ですが、journalctlは内部的にインデックスを持つ構造化ストレージを採用しているため、大量のログデータに対しても高速に検索が可能です。
syslogのようにファイル全体を逐次スキャンする必要がないため、障害発生直後の調査において特に効果を発揮します。

また、journalctlはメタデータ検索に優れており、以下のような条件指定が可能です。

journalctl _PID=1234
journalctl -p warning..err
journalctl --disk-usage

このようにプロセス単位、ログレベル単位、ディスク使用量単位での分析ができるため、問題の切り分けが非常に効率的になります。

さらに重要なのは、journalctlがsystemdの制御情報と一体化している点です。
サービスの再起動履歴や依存関係の失敗なども同じジャーナル内で確認できるため、単なるログ収集ではなく「システム状態の履歴データベース」として機能します。
この設計により、障害の原因分析がより構造的に行えるようになります。

観点	journalctlの特徴	効果
検索性能	インデックスベース	大量ログでも高速検索
統合性	systemdと完全統合	サービス状態と連携可能
構造化	メタデータ付きログ	精密なフィルタリング
運用効率	自動管理	手動メンテナンス不要

また、クラウド環境やコンテナ環境との相性も良く、systemdベースのイメージでは標準的に採用されるケースが増えています。
特に短命なコンテナ環境では、ログを外部へ即時転送する設計と組み合わせることで、可観測性を大幅に向上させることができます。

総合的に見ると、journalctlは「systemdを中心とした現代的なLinux運用」において、単なるログ閲覧ツールではなく、障害解析の中核を担うコンポーネントとして設計されています。
そのため、迅速なトラブルシューティングやクラウドネイティブな運用を重視する環境では、非常に合理的な選択肢となります。

ログ収集基盤の選択肢：Fluentd・Grafana Loki・ELKスタックの活用

大規模なログ管理を設計する際、syslogやjournalctlといったローカルログシステムだけでは限界があり、その上位レイヤーとしてログ収集基盤の選定が重要になります。
特に分散環境やクラウドネイティブアーキテクチャでは、ログの収集・転送・検索・可視化を統合的に扱う仕組みが必要となります。
その代表的な選択肢としてFluentd、Grafana Loki、ELKスタックが挙げられます。

まずFluentdは、ログ収集エージェントとして非常に広く採用されているOSSです。
プラグインベースの設計により、入力・変換・出力を柔軟に組み合わせることができ、syslogやjournalctlからのログを統合的に収集する役割を担います。
特に重要なのは、ログフォーマットを統一しながら複数の出力先へ同時に転送できる点であり、ログパイプラインのハブとして機能します。

次にGrafana Lokiは、比較的新しいログ集約システムであり、メトリクス監視ツールであるGrafanaとの統合を前提に設計されています。
従来の全文インデックス方式ではなく、ラベルベースの軽量インデックスを採用することで、ストレージコストを抑えつつスケーラブルなログ検索を実現しています。
この設計は特にコンテナ環境との相性が良く、Kubernetesなどの動的環境で強みを発揮します。

一方でELKスタック（Elasticsearch、Logstash、Kibana）は、長年にわたりログ分析基盤のデファクトスタンダードとして利用されてきました。
Elasticsearchによる強力な全文検索機能、Logstashによる柔軟なデータ変換、Kibanaによる高度な可視化機能が統合されており、分析能力という観点では非常に高い完成度を持ちます。
ただしその分リソース消費が大きく、設計と運用の複雑性も高いという特徴があります。

これらの基盤を比較すると、設計思想の違いが明確になります。

基盤	特徴	適用環境	強み
Fluentd	軽量エージェント	分散システム全般	柔軟な転送と変換
Grafana Loki	軽量ログ集約	コンテナ・Kubernetes	低コストなスケール
ELKスタック	高機能分析基盤	大規模分析環境	高度な検索と可視化

このように、それぞれのツールは単体で完結するものではなく、ログ収集パイプラインの中で異なる役割を担います。
例えばFluentdで収集したログをLokiやElasticsearchへ転送し、GrafanaやKibanaで可視化するという構成が一般的です。

また重要な視点として、syslogやjournalctlは「ログ生成と一次保存」、これらの基盤は「二次処理と分析」という役割分担になります。
この分離設計により、システム全体のスケーラビリティと保守性が向上します。

さらに近年では、ログを単なる記録ではなく「オブザーバビリティデータ」として扱う流れが強まっています。
そのためメトリクスやトレースと統合された可観測性プラットフォームの構築が一般的になりつつあり、ログ基盤の選択は単独ではなく全体アーキテクチャの一部として考える必要があります。

結論として、Fluentd・Loki・ELKはいずれも優劣ではなく用途依存の選択肢であり、ログの量・検索要件・コスト・運用体制によって最適解が変わるという点を理解することが重要です。

syslogからjournalctlへの移行戦略：ハイブリッド運用と注意点

syslogからjournalctlへの移行は、単純なツールの置き換えではなく、ログアーキテクチャ全体の再設計を伴うプロセスです。
特に長期間運用されてきたシステムでは、ログ生成・収集・保存の各層にsyslog前提の設計が深く組み込まれているため、段階的な移行戦略が不可欠になります。

まず理解すべき重要な点は、journalctlはsyslogの完全な代替ではなく、systemd環境に最適化されたログ管理層であるということです。
そのため移行の目的は「置き換え」ではなく「共存による最適化」と捉える方が現実的です。
実際、多くの本番環境ではハイブリッド構成が採用されています。

ハイブリッド運用の基本構造は、journaldがローカルでログを収集し、その出力をrsyslogやsyslog-ngへ転送する形です。
これにより、systemdベースの構造化ログ管理と従来型のテキストベースログ管理を同時に維持できます。
この構成は互換性を保ちながら段階的移行を可能にするため、リスクが低いという特徴があります。

例えばjournalctlからsyslog互換形式へ転送する設定は以下のように構成されます。

journalctl -f | logger

このような単純なパイプ構成でも基本的な連携は可能ですが、実運用ではフィルタリングやタグ付けを組み合わせた設計が必要になります。

移行戦略において重要なのは、ログの「意味的整合性」を保つことです。
syslogは基本的にフラットなテキスト構造であるのに対し、journalctlはメタデータを持つ構造化ログであるため、単純に変換すると情報の粒度が失われる可能性があります。
このため、どのメタデータをsyslogにマッピングするかを慎重に設計する必要があります。

また注意点として、ディスク管理の違いが挙げられます。
syslogはlogrotateなどの外部ツールによってログのローテーションを制御しますが、journalctlはsystemd-journaldが内部で自動管理を行います。
そのため両者を併用する場合、ディスク使用量の二重管理が発生しないよう設計する必要があります。

さらにセキュリティ面でも違いがあります。
journalctlはバイナリ形式で保存されるため改ざん検知やアクセス制御が比較的容易ですが、syslogはテキストファイルであるため外部からの直接編集リスクがあります。
この特性差を理解した上で、監査ログの扱いを設計することが重要です。

観点	syslog	journalctl	ハイブリッド運用時の注意
形式	テキスト	バイナリ構造化	変換時の情報欠落
保存	外部管理	内部管理	ローテーション重複
互換性	高い	systemd依存	レガシー機器対応
運用複雑性	中	低	構成増加による複雑化

移行を成功させるためには、まず観測対象を限定したパイロット導入を行い、その後段階的に範囲を拡張するアプローチが有効です。
特に本番環境では、ログの欠損や解析不能状態が直接インシデント対応に影響するため、いきなり完全移行することは避けるべきです。

最終的に重要なのは、syslogとjournalctlのどちらか一方に統一することではなく、それぞれの特性を理解した上で適切に役割分担させることです。
移行戦略とは技術選定ではなく、システム全体の観測可能性を維持しながら進化させるための設計プロセスであるといえます。

結論：syslogとjournalctlの合理的な使い分け

syslogとjournalctlは、どちらか一方が絶対的に優れているという関係ではなく、それぞれが異なる設計思想と適用領域を持つ補完的な技術です。
ログ管理という文脈において重要なのは、ツールの優劣ではなく「システム要件に対してどのように適合させるか」という設計判断になります。
そのため最終的な結論としては、両者を合理的に使い分けることが最も現実的かつ安定した選択肢になります。

まずsyslogは、互換性と汎用性に優れたログ基盤として位置付けられます。
レガシーシステムやネットワーク機器、さらには異なるOS間のログ統合においても広く利用できるため、異種混合環境では依然として中心的な役割を担います。
特にテキストベースであることは、障害発生時の即時調査や外部ツールとの連携において大きな利点となります。

一方でjournalctlは、systemdを前提とした現代的なLinux環境において、構造化されたログ管理と高速検索を実現するための設計になっています。
メタデータ付きのバイナリログにより、サービス単位や時間単位での精密なフィルタリングが可能であり、大規模環境におけるトラブルシューティング効率を大幅に向上させます。

この2つの関係性を整理すると、syslogは「互換性と外部連携の基盤」、journalctlは「内部解析と高速検索の基盤」として役割が分離されます。
この構造を理解することが、合理的な使い分けの出発点になります。

実際の運用では、以下のような分担が現実的です。
ローカルのシステムログやレガシーアプリケーションはsyslogで受け持ち、systemd管理下のサービスやコンテナ環境のログはjournalctlで管理し、その上位でFluentdやELKなどのログ基盤へ集約する構成が一般的です。
このように階層化することで、それぞれの技術の強みを損なうことなく統合できます。

観点	syslogの役割	journalctlの役割
互換性	外部機器・レガシー対応	systemd内部統合
検索性	テキスト検索中心	メタデータ高速検索
運用領域	汎用ログ収集	システム状態解析
拡張性	外部ツール依存	systemd内完結