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

別のサービスが失敗したときにのみ実行したいサービスがあります（[Unit] OnFailure=foo）が、このサービス（foo）が起動時に自動的に起動しないようにしたい。1つのオプションは実行systemctl disable foo中ですが、別の方法を探しています。 背景：私はOSイメージを作成していますが、マシンを起動してそのコマンド（systemctl disable foo）を実行し、イメージをfinalと宣言する前にシャットダウンする必要はありません。

12 systemd 

dbaグループのユーザーがdatabase@サービスを制御できるようにする必要があります。この関連する質問に対する答えsystemctlは、sudoersファイルに許可したいすべての「動詞」をリストすることですが、システムに存在する可能性のあるデータベースが事前にわからないため、私のケースには当てはまりません。たとえば、私がリストした場合 %dba = /usr/bin/systemctl start database@awsesomeapp %dba = /usr/bin/systemctl start database@anotherawsesomeapp %dba = /usr/bin/systemctl start database@yetanotherawsesomeapp %dba = /usr/bin/systemctl start database@wowyetanotherawsesomeapp # ... other "verbs" omitted for brevity 将来存在する可能性のあるインスタンスは対象外であり、dbaは $ sudo systemctl start database@omgwowyetanotherawsesomeapp とにかく、私は特定のシステムをいじるよりも、パッケージの点で多くのことを考えています。 別の関連する質問に対するこの驚くべき回答に示されているように、これにsudoグロブを使用することは、最終的に安全ではないことに注意してください。 %dba ALL = /usr/bin/systemctl start database@[a-z]* # UNSAFE! 許可します $ sudo systemctl start database@awsesomeapp …

12 sudo  systemd  not-root-user 

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

12 arch-linux  systemd  logs  systemd-journald 

Arch Linuxを実行しています。デバイスを挿入するとサービスを開始するudevルールがあります。この場合、3Gモデムが接続されているときに接続にダイヤルします。 KERNEL=="ttyUSB*", SYMLINK=="gsmmodem", TAG+="systemd", ENV{SYSTEMD_WANTS}="netcfg@wvdial.service" ただし、デバイスが削除された場合、systemdはサービスを停止しません。そのため、再度接続すると、すでに実行されているため、サービスは開始されません。 サービスを停止するためにデバイスが削除されたときに実行される一致するudevルールが必要です。 更新 以下の答えを使用すると、私が今持っているのは次のudevルールです KERNEL=="ttyUSB*", SYMLINK=="gsmmodem", TAG+="systemd", ENV{SYSTEMD_WANTS}="vodafone.service" 次のサービスファイルを使用します（これは基本的にnetcfgサービスファイルからコピーして貼り付けました： [Unit] Description=Netcfg networking service for Vodafone Dongle Before=network.target Wants=network.target BindsTo=dev-gsmmodem.device After=dev-gsmmodem.device [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/netcfg check-iface wvdial ExecStop=-/usr/bin/netcfg down wvdial KillMode=none [Install] WantedBy=multi-user.target netcfg-wvdialAURからダイヤルを使用しています。

12 linux  udev  systemd 

manページで述べたように、 systemctl --now enable servicename サービスを有効にして開始する必要があります。 しかし、多くの異なるディストリビューションのもとでは、私にはうまくいきません。 出力は次のとおりです。 systemctl is-enabled 有効になります systemctl is-active サービスに対してまだ非アクティブです。 このスイッチは何に適していますか？ 私は次のような他の組み合わせを試しました： systemctl enable --now servicename そして： systemctl enable servicename --now しかし、まだ同じです。systemctl start servicename前のコマンド（つまり、enableパーツ）が正常に実行された場合でも、毎回手動で実行する必要があります。 systemdサービスの豊富なアプリケーションが、ユニットファイルのどこかに機能を実装することをサポートするべきでしょうか。多くの有名なサービスが従わないもの、それは私がその完全に役に立たないスイッチだと思った。私はそれについて考えていると思います。

12 systemd  startup  services  systemctl 

実行するservice apache startと、ログファイルに次のエントリが表示されます。 [mpm_event:notice] [pid 1906:tid XXX] AH00489: Apache/2.4.23 (Unix) OpenSSL/1.0.2g PHP/7.0.9 configured -- resuming normal operations [core:notice] [pid 1906:tid XXX] AH00094: Command line: '/usr/sbin/httpd' [mpm_event:notice] [pid 1906:tid XXX] AH00492: caught SIGWINCH, shutting down gracefully そしてサービスapacheが開始されませんか？インターネットでSIGWINCH[ Window size change]の意味を見つけることができますが、この場合はあまり役に立ちません。 ファイル/etc/systemd/system/apache.service： [Unit] Description=The Apache Webserver [FaF Compiled] After=network.target nss-lookup.target time-sync.target Before=getty@tty1.service …

12 systemd  apache-httpd  services  signals  suse 

私のArchボックスには、ネットワークブリッジがありました。目標は、ブリッジを削除し、ブリッジされていないネットワークアダプターのみを使用することでした。これを行うために、以下のすべての* .netdevおよび* .network構成ファイルを削除し/etc/systemd/network、それらを1つの単純なファイルに置き換えました。 /etc/systemd/network/lan.network -------------------------------- [Match] eno* [Network] DHCP=ipv4 私は、使用してネットワークサービスを再起動しsystemctl restart systemd-networkd、これはただで私を残してと仮定して、loおよびeno*インタフェース。残念ながら、これは効果がありませんでした。をざっと見てみるとip link、ブリッジインターフェースがアクティブでアクティブであることがわかりました。 この特定のケースでの稼働時間は重要ではないため、問題を解決したマシンを再起動しただけです。それでも、このような場合には再起動は必要ないのではないかと思います。私は何を逃したのですか？

12 systemd  systemd-networkd 

私は（自分で作成した）サービスを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 

私がしたいリロード（再起動しないで！）イベント時にサービスのグループ。 私は私のSSL証明書を更新した場合、私は、用途はそれらを再ロードするすべてのサービスをしたい（nginxとpostfix心に来ます）。また、特定のサーバー上のどのサービスがSSL証明書を使用するかを覚えておきません。それらが構成されたときにそれらをグループ化するのに十分でなければなりません。 一方.serviceで、パッケージで提供されるファイルの変更は避けたいと思います。更新中に手動での介入が必要になるためです。 どうすればそれを達成できますか？ リクエストに応じてサービスのグループを停止するオプションがありますが、これによりサービスに 1、2秒、またはそれ以上アクセスできなくなり、修正されるまで停止したままになる場合があります。それを買う余裕はない。

12 systemd 

Azureで作成されたLinux Ubuntu VM（14.04 LTS）で再現可能な問題があります。 systemdスクリプトを使用してパッケージをインストールした後、システムは新しいssh接続を無限に拒否します。 システムが起動しています。 xxx.xxx.xxx.xxxによって接続が閉じられました ただし、アクティブなSSH接続は維持されます。/etc/nologinシステムにファイルがありません。 私が目にする唯一のオプションは、問題を解決するハードリセットです。しかし、どうすればそれを回避できますか？ これが私が使用しているスクリプトです： #!/bin/bash # Script input arguments user=$1 server=$2 # Tell the shell to quote your variables to be eval-safe! printf -v user_q '%q' "$user" printf -v server_q '%q' "$server" # SECONDS=0 address="$user_q"@"$server_q" function run { ssh "$address" /bin/bash "$@" } run …

12 linux  ssh  systemd 

（コンテナー内の）サービスの再起動数を制限しようとしました。OSのバージョンはcentos-release-7-5で、サービスファイルは次のようになります（読みやすいように一部のパラメーターを削除しました）。他のいくつかの投稿が指摘しているように、これはかなり単純なはずです（Post of Server Faultの再起動制限1、Post of Stack Overflowの再起動制限2）。しかし、StartLimitBurstとStartLimitIntervalSecは私にとっては機能しません。 私はいくつかの方法でテストしました：（1）サービスPIDをチェックし、「kill -9 ****」でサービスを数回強制終了します。サービスは常に20秒後に再起動されます！（2）また、サービスファイルをめちゃくちゃにして、コンテナが実行されないようにしました。それでも機能しません。サービスファイルは再起動し続けるだけです。 何か案が？ [Unit] Description=Hello Fluentd After=docker.service Requires=docker.service StartLimitBurst=2 StartLimitIntervalSec=150s [Service] EnvironmentFile=/etc/environment ExecStartPre=-/usr/bin/docker stop "fluentd" ExecStartPre=-/usr/bin/docker rm -f "fluentd" ExecStart=/usr/bin/docker run fluentd ExecStop=/usr/bin/docker stop "fluentd" Restart=always RestartSec=20s SuccessExitStatus=143 [Install] WantedBy=multi-user.target

12 linux  systemd 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 DebianとXubuntuについて議論しているオンラインフォーラムにアクセスして、署名欄にこの行を追加するユーザーを見ました： ... systemdなしで... この行は誇りを持って示されています（私には思えます）。 ウィキペディアから： systemdは、Linuxコンピューターのオペレーティングシステム用の中央管理および構成プラットフォームとして設計された、システム管理デーモン、ライブラリ、およびユーティリティのスイートです。 だからsystemd悪いことのように思えないのに、なぜ人々はそれを使わないという誇りを持って書くのですか？ することができますsystemdあなたのために危険な、または単に悪いですか？

11 systemd  init 

問題 この質問は10億回も寄せられたようですが、ログインキーリングのロックを自動的に解除することはできません。 バックグラウンド これらの行に沿って自動的にログイン、chvt、startx をi3wmに実行すると、変更されたi3lockが起動します。ログインしたとき（またはおそらくi3lockのロックを解除したとき）にgnomeのログインキーリングが自動的にロック解除されるようにしたいのですが、オンラインで見つけたどの手順も正常に実装できませんでした。 調査結果 アーチウィキは、私が試みたが、やることができなかったこのことについて全体のことがあります。私はまた、同様の指示が役に立たない他のさまざまな質問/回答を見回しました。 私が気付いた奇妙なことの1つは、を介してログインキーリングのロックを解除できないことですecho $LOGINPASSWORD | gnome-keyring-daemon --unlock。journalctl報告書 Jul 07 20:08:16 ERIS gnome-keyring-daemon[26585]: failed to unlock login keyring on startup タツノオトシゴを開いて手動でロックを解除すると、ログインパスワードが変更されたことが報告され、古いパスワードの入力を求められます。journalctlレポート Jul 07 20:08:43 ERIS gnome-keyring-daemon[26585]: fixed login keyring password to match login password その上で、パスワードでキーリングのロックを再度解除することができません（幸い、事前にバックアップを作成しました）。 追加情報 ここにいくつかの関連/etc/pam.d/ファイルがありますが、ここでは機密性の高いものはないはずですLOL（簡潔にするためにコメントを削除し、順序は変更していません。この.xinitrcビットも試しましたが、何もしなかったことに注意してください）。/etc/pam.d/i3lockにpam_gnome_keyring.soあるものを除いて、手動で追加したのはビットだけです。デフォルトでは、または他のパッケージのために、すでに他に何かがありました。 /etc/pam.d/login auth optional pam_faildelay.so delay=3000000 auth [success=ok new_authtok_reqd=ok ignore=ignore …

11 ubuntu  systemd  pam  i3  gnome-keyring 

BunsenLabs GNU / Linux（Debianベース）の奇妙な動作に遭遇しました。 OSをオフにできないことがあります。sudo poweroffGUI を使用するかGUI を使用するかは関係ありません。 これは私が実行した後に得られるものですsudo poweroff： Failed to start poweroff.target: Transaction is destructive 回避策はありますか？なぜそれが起こっているのですか？ これが私の内容です/lib/udev/rules.d/70-power-switch.rules： ACTION=="remove", GOTO="power_switch_end" SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="acpi", TAG+="power-switch" SUBSYSTEM=="input", KERNEL=="event*", KERNELS=="thinkpad_acpi", TAG+="power-switch" LABEL="power_switch_end"

11 systemd  udev  shutdown  bunsenlabs 

ショートバージョン：Fedoraシステムで監査メッセージ（dmesg）を無効にする方法は？ Fedoraシステムは、「監査：成功」メッセージをdmesgに記録し続けます-そのような極端な方法で、dmesgはこれらのメッセージで満たされるため（dmesg | grep -v audit空）、使用できなくなります。これらのメッセージは、毎日の内部プロセスが成功したことをユーザーに明らかに伝えたいので、完全に役に立たないものです（何かをデバッグするときに興味深いかもしれませんが、この場合は単なるノイズです）。 コマンドラインインターフェース（X以外のttyにCtrl+ Alt+で切り替える場合F2）でも、これらの監査メッセージが常に散らかっているため使用できなくなり、実際にユーザーが実行したコマンドの出力を読み取ることができなくなりました。たとえば、ユーザー名（ログイン）を入力すると、監査メッセージが出力されます（何かが正常にフォーマット/印刷されたことをユーザーに通知しているようです）。 監査：タイプ= 1131監査（1446913801.945：10129）：pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = fprintd comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname =？addr =？ターミナル=？res =成功 ' これらのメッセージのほとんどは「成功」を示しているようですが、このキーワードを含まない多くの監査メッセージもあります。Chromiumを実行すると、次の数百がトリガーされます。 監査：タイプ= 1326監査（1446932349.568：10307）：auid = 500 uid …

11 linux  fedora  systemd  networkmanager  audit