タグ付けされた質問 「systemd-journald」

Googleでシステム化されたジャーナルをクリアする安全な方法を見つけることができませんでした。誰でも安全で信頼できる方法を知っていますか？ 私が何かを試していて、ログがさまざまなエラーメッセージで乱雑になったとしましょう。さらに、Conkyを使用してデスクトップにジャーナルを表示しています。これらのエラーは、私がこの問題を修正していたひどい日を思い出させるので、本当に見たくありません。この恐怖の後、新鮮な男のように感じたいです。これはログをクリアする正当な理由であることに誰もが同意すると思います：P

209 systemd  systemd-journald 

journalctlCentOS 7システムで実行すると、最後のブート後に生成されたメッセージのみが出力されます。 コマンド # journalctl --boot=-1 プリント Failed to look up boot -1: Cannot assign requested address ステータス1で終了します。 それを現在のFedoraシステムと比較すると、CentOS 7にはない/var/log/journal（そしてjournalctl提供しない--list-boots）ことがわかります。 したがって、私の最後のブート日より前に書き込まれたログメッセージを表示する方法について質問します。 または、おそらくこの機能をCentOS 7で有効にする必要がありますか？ （journalctlマニュアルページには、バージョン番号として「systemd 208」が記載されています。）

78 centos  systemd  systemd-journald 

私の質問は簡単です：どのように再起動せずに journaldに設定ファイルを再読み込みするように伝えるのですか？ 私はいくつかの変更を加えました。/etc/systemd/journald.confそれらが正しく、すべてが期待どおりに機能するかどうかを確認したいと思います。 再起動したくありません。

46 systemd  systemd-journald 

当たり前のことを見落としているように感じますが、リモートシステムからメッセージsystemdを受信して​​ログに記録するためにを使用するArch Linuxサーバーを取得する方法がわかりませんsyslog。 Cisco 678 DSLモデムとDD-WRT WAPがあり、syslog形式のメッセージを他のマシンに送信するように両方を構成できます。そのマシンをArch Linuxサーバーにしたいのですが。 私はあちこち探してみましたが、「systemdがsyslogに置き換わる」、またはもう実行する必要がsyslogないか、質問と同様に無関係なものを見つけただけです。 更新 Archフォーラムで質問したところ、関連する回答はありませんでした。UDPポート514でリッスンするためだけにsyslog-ngをインストールしました。syslog-ngはCisco 678からのメッセージと、持っているDD-WRT WAPを書き込みます。残念ながら、メッセージはsystemdのジャーナルではなく、フラットファイルに保存されます。したがって、正確な解決策はありませんが、回避策があります。むしろ、フラットファイルではなく、ジャーナルにsyslogメッセージが必要です。

25 systemd  syslog  systemd-journald 

デバイスでarch linuxが失敗します。デバイスには画面がなく、ネットワークに応答しません。だから私はそのSDカードを取り、ubuntuデスクトップに挿入し、そこに新しいsystem.journalを見て、そして...中身を見る方法は？ Arch Linuxのドキュメントから、私ができることはわかっています： strings /mnt/arch/var/log/journal/.../system.journal | grep -i message しかし、それは本当に基本的なことです。質問は： 文字列を使用するよりも、別のシステムからsystem.journalを検査するより便利な方法はありますか？たとえば、journalctlで読み込むファイルを指定できますか？

23 systemd  systemd-journald 

systemd-journaldはsyslogプロトコルの新しい実装なのか、それともrsyslog、syslog-ngなどのsyslog実装を使用するのか 私は少しグーグルで調べましたが、それについて納得できるものは何も見つかりませんでした。

22 syslog  systemd-journald 

私はちょうどこのverifyオプションに気づきjournalctl、それを試してみることにしました、それは破損を示しています、何がそれを引き起こす可能性がありますか？そして、私はそれについて何をしたらいいですか？さらに調査する必要がありますか？ journalctl --verify PASS: /var/log/journal/19184893a1d645c7a43729e79b10a876/user-1000.journal Invalid object contents at 3733856░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0% File corruption detected at /var/log/journal/19184893a1d645c7a43729e79b10a876/system.journal:3733856 (of 91734016, 4%). FAIL: /var/log/journal/19184893a1d645c7a43729e79b10a876/system.journal (Bad message) Invalid object contents at 21575496░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 45% File corruption detected at /var/log/journal/19184893a1d645c7a43729e79b10a876/system@60e058db556e4de4b256d0b1ff176aa4-0000000000000001-0004e0b436d20aa1.journal:21575496 (of 44052480, 48%). FAIL: /var/log/journal/19184893a1d645c7a43729e79b10a876/system@60e058db556e4de4b256d0b1ff176aa4-0000000000000001-0004e0b436d20aa1.journal (Bad message) PASS: /var/log/journal/19184893a1d645c7a43729e79b10a876/user-1000@60e058db556e4de4b256d0b1ff176aa4-0000000000000a91-0004e0b4ff9a949a.journal PASS: /var/log/journal/19184893a1d645c7a43729e79b10a876/user-1001.journal

22 systemd  systemd-journald 

このloggerコマンドはsyslogを介してエントリを記録します/var/log/messages。通常、この行はのようなファイルに書き込まれます。 Arch Linuxでドキュメントを正しく理解している場合、すべてのロギングはsystemdを介して行われますが、loggerを使用してエントリを見つけることができませんjournalctl。 loggerArch Linuxでメッセージが表示されるとどうなりますか？ ログエントリはどこに保存されますか？（簡単なgrepが提案し/var/log/journal/*/system.journalます。） このログにアクセスするにはどうすればよいですか？（特別なオプションは必要journalctlですか？）

18 arch-linux  systemd  systemd-journald  logger 

Pythonスクリプトを作成し、そのためのsystemdユニットファイルを作成するのに数日費やしました。テスト中、スクリプトは多くのエラーをjournaldに記録しました。完了したら、これらのエラーをjournaldからクリアしたいと思います。 ここで説明するように、ジャーナル全体をクリアする方法はいくつかあります： using journalctl --vacuum-time=2d、using journalctl --vacuum-size=500M、およびSystemMaxUse=/etc/systemd/journald.confを非常に低い値に一時的に設定するなど、journalctlをクリアする方法。 これらはすべて、ジャーナル全体をクリアするように見え、すべてのユニットに影響します。単一のユニットのエントリをクリアするだけです。これは可能ですか？

18 systemd  logs  systemd-journald 

この記事に記載されている情報に基づいて、tomcatアプリケーションを実行するsystemdサービスを作成しました。この記事の短いバージョンでは、適切な環境とコマンドラインを使用して、シェルスクリプトラッパーを回避し、javaを直接実行することを推奨しています。 systemdサービス全体を以下に示します（アプリ名が置き換えられています）。 [Unit] Description=MyApp Tomcat Container [Service] EnvironmentFile=/opt/myapp/environment ExecStart=/usr/bin/env ${JAVA_HOME}/bin/java $JAVA_OPTS $CATALINA_OPTS \ -classpath ${CLASSPATH} \ -Dcatalina.base=${CATALINA_BASE} \ -Dcatalina.home=${CATALINA_HOME} \ -Djava.endorsed.dirs=${JAVA_ENDORSED_DIRS} \ -Djava.io.tmpdir=${CATALINA_TMPDIR} \ -Djava.util.logging.config.file=${CATALINA_BASE}/conf/logging.properties \ -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ org.apache.catalina.startup.Bootstrap start ExecStop=/usr/bin/env $JAVA_HOME/bin/java $JAVA_OPTS \ -classpath $CLASSPATH \ -Dcatalina.base=$CATALINA_BASE \ -Dcatalina.home=$CATALINA_HOME \ -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS \ -Djava.io.tmpdir=$CATALINA_TMPDIR \ -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties \ -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ org.apache.catalina.startup.Bootstrap …

15 systemd  tomcat  systemd-journald 

珍しいが重要な情報をログに記録する特定のサービスがあります。数か月前にセットアップしましたが、今日journalctl -n 50 --unit=my-serviceはエントリがないことを確認するためだけに実行しました。 ほとんどのユニットでこの動作に完全に満足しています。すぐに（または多くても数日前）起こったことが必要であり、数か月前のレコードは気にしません。 しかし、journald単一の特定のユニットのレコードに対して、独立したストレージおよび保持ポリシーを持つように指示する方法はありますか？私はそれらの特定のログを、たとえば5年間、それがかかるサイズに関係なく保持したいと考えています。他のユニットのログはこれによる影響を受けず、既存の動作を保持する必要があります。 私は理解を失っていてjournald.conf(5)、ユニット単位の構成が可能な場合はいつでも理解できません。もしそうなら-簡単で具体的な例に感謝します-どのファイルを編集/作成し、何を書くべきか。または、確かにそれが確実に実行できないことを知っている場合-それも同様に良い答えでしょう。 注：私の特定のケースにはArch Linuxホストが関係していますが、これはそれほど問題ではないと思います。

14 arch-linux  systemd  logs  systemd-journald 

Arch Linuxのジャーナルにログ情報を出力するいくつかのデーモンが（systemdユニットとして）実行されているシステムがあります。これらのユニットファイルのいくつかのジャーナル出力を、場所を指定する別のテキストファイルに送り、基本的にユニットのサブセットのログファイルを作成します。どうすればそれを実現できますか？

12 arch-linux  systemd  logs  systemd-journald 

私は（自分で作成した）サービスをDebian（Jessie）サーバーで実行していて、サービスのログは、特定の時間に再起動したことを示しています。私は今、アプリケーションが何らかの形であれば把握しようとしていますので、セグメンテーション違反または他のクラッシュの兆候はありませんが、静かに失敗したとsystemdに再生成によって得た、またはユーザーが意図的に介してサービスを再起動するかどうかsystemctl。 シェルの履歴にはそのようなアクティビティは表示されませんがexport HISTCONTROL=ignoreboth、SSHセッションがタイムアウトしたため、以前のログインのbash履歴がディスクに書き込まれなかったため、これは決定的なものではありません。現時点ではサーバーは再起動されていません。 しかし、systemd自体は、サービスが意図的に再起動されたときを示すログを保持する必要があると思います。驚いたことに、journalctlそのようなログを取得する方法に関するドキュメント（例：）を見つけることができませんでした。 他のいくつかの投稿（たとえば、通常のユーザーsystemdサービスのログはどこにあるのか、なぜログがないのですか？）は、次のようなログメッセージがあるはずであると示しています。 Jan 15 19:28:08 qbd-x230-suse.site systemd[1]: Starting chatty.service... Jan 15 19:28:08 qbd-x230-suse.site systemd[1]: Started chatty.service. しかし、システムにそのようなログメッセージは表示されません。 systemdサービスがいつ開始、停止、または再起動されたかを知る方法はありますか？ 編集：人々が遭遇する可能性がある典型的な問題はjournalctl、非特権ユーザーとして実行することです。これは私には当てはまりません、私はずっと操作してきましrootた。コメントに応じて、実行するとgrep systemd /var/log/syslogこれだけしか得られません： Jun 6 09:28:35 server systemd[22057]: Starting Paths. Jun 6 09:28:35 server systemd[22057]: Reached target Paths. Jun 6 09:28:35 server systemd[22057]: Starting Timers. Jun 6 09:28:35 server …

12 systemd  systemd-journald 

RHEL7では、systemd-journaldかつてによって行われていたことの多くの責任を引き継ぎrsyslogdます。バグによるか、これら2つのデーモン間の競合によるかは、場合/dev/logによっては行方不明になります。その結果、syslog(3)呼び出しに依存するプログラム（など）は正しく機能しませんlogger。/dev/logソケットを復元するにはどうすればよいですか？

10 systemd-journald  rsyslogd 

Debian Jessieを実行しているデスクトップコンピュータは、起動するたびに緊急モードのシェルにドロップし始めました。画面にはjournalctl -xb、理由を見つけるために使用systemctl defaultし、起動を続行するために使用するように言われています。を実行するsystemctl defaultと、システムは起動し続け、数週間システムを使用した後、明らかに問題はありません。 に目を通すjournalctl -xbと、緊急シェルにドロップする理由として何も目立ちません。緊急モードにすることを決定した理由を正確に判断する簡単な方法はありますか？問題がどこにあるかを明らかにする他のフラグまたは起動オプションはありますか？

10 debian  systemd  systemd-journald