問題タブ [systemd]

CentOS 7 を最小限の構成 (OS + 開発ツール) でインストールしました。サービス用に 80 ポートを開こうとしていますhttpdが、iptables サービスに何か問題があります...何が問題なのですか? 私は何を間違っていますか？

systemd のソケット アクティベーション機能を使用して、ポートを公開 (リッスン) する Web サーバーなどの個々の Docker コンテナーを起動できますか? アイデアは、コンテナーが実際に初めて必要になったときにのみコンテナーを開始することによってリソースを節約することです (そして、リソースを節約するためにアイドル状態になったときにコンテナーを再び停止する可能性があります)。

注: この質問は、ソケット アクティベーション (既にサポートされています)を使用して Docker デーモン自体を起動することに関するものではなく、個々のコンテナーをオンデマンドで起動することに関するものです。

私は Linux 用に開発しており、デーモンが強制終了されたときにディスクに書き込む必要があります。SIGTERMデーモンは、そのシグナルを受信したときにディスクをリッスンしてディスクに書き込むように構成できます。

また、ログイン マネージャーPrepareForShutdownが発行する D-Bus シグナルにも精通しています。リッスンすると、シャットダウンを禁止してシグナルをリッスンするよりもコードが単純になります。のもう 1 つの利点は、システムがシャットダウンしてもデーモンが丁寧に強制終了された場合を処理できることです。SIGTERMPrepareForShutdownSIGTERM

SIGTERMただし、シャットダウン時にカーネルによって送信されるシグナルに依存することがどれほど安全かはわかりません。シャットダウンSIGTERM時に、ディスクへの小さい (< 1 kB) 書き込みを実行するのに十分な時間があるすべてのプロセスに常に送信されますか?

私が懸念していることの 1 つは、一部のハードウェアではディスクに書き込むのに十分な時間があり、他のハードウェアではそうでない可能性があるため、テストが難しいように思われることです。信号についても同じことが言えますPrepareForShutdownが、少なくともディスク書き込みに十分な時間を許可することは、その信号の契約の一部です。SIGTERM私の質問は、すべてのプロセスがシャットダウン時に受け取るシグナルについても同じことが言えるかどうかです。

Fedora 19 で mono-service を使用して、mono アプリケーションをデーモンとして実行できます。

いくつかの環境変数を設定するには、まずスクリプトを実行する必要があります

その後、mono アプリケーションをデーモンとして実行できます。

アプリケーションを systemd 構成のサービスとして自動起動したいと考えています。私の試みは成功しませんでした

私の構成は

ユーザーはスクリプトを .bash_profile に追加しています

私が間違っていること、またはすべきことについての指針が求められます。

Node.js アプリを実行している systemd サービス ファイルがあります。サービスは正常に動作しているように見えますが、サービスを停止すると、サービスの使用systemctl stop trainが失敗した状態になります。

私のサービスファイルは次のようになります。

Node.js アプリが、systemd が失敗と見なすステータス コードを返していると思われます。可能であれば、Node.js アプリが別のステータス コードを返すようにする必要があるかどうかはわかりません。または、systemd サービス ファイルを何らかの方法で変更する必要がある場合。

それが役立つ場合は、デプロイ スクリプトがここにあります: https://github.com/JonathanPorta/ansible-train

実際の Node.js アプリはこちら: https://github.com/JonathanPorta/train

助けてくれてありがとう！

現在、2.6.39 Linux カーネルで systemd を使用して Tixi ボードの起動時間を確認しようとしています。そのために、gpio を設定して使用する bash スクリプトを呼び出すサービス ファイルを作成しました。問題は、システムで gpio の値を変更できないことです。正常にエクスポートして方向を変更できますが、値は変更できません。一部のフォーラムで提案されているように、ハードウェアで値が変更されたがファイルで更新されていないかどうかを確認するためにオシロスコープを接続しましたが、同じでした: 値は変更されません! また、カーネル、ビジーボックス、およびファイルシステムの構成がまったく同じであるシステム V を使用する場合、同じスクリプトが機能することも指摘しておく必要があります。

皮肉なことに、私はすでにシステムのルートになっているにもかかわらず、ファイルのアクセス許可を変更しても、その値を変更することはできません。カーネルからの操作不可というフィードバックもなく、むしろできたように見えますが、値を確認すると、以前と同じでした。

また、3.12（systemdに変更）を使用してRaspbianで実行しようとしましたが、実際には、ユーザースペースから通常の方法で実行できました。

私はすでにアイデアを使い果たしているので、何が問題なのか考えていただければ幸いです。

ありがとう

PS: これは、bash ラインで動作するはずのコードです。

それにもかかわらず、同じボードの同じコード行は、systemV を使用すると機能しますが、systemd を使用すると機能しません

RHEL7 で実行され、systemd によって開始される Linux プロセスがあります。プロセスが停止した場合、システムのシャットダウンまたは再起動が原因でプロセスが停止されているかどうかを知る必要があり、その 2 つを区別できる必要があります。

以前は、RHEL6 の init の下で、init スクリプトの呼び出しに使用されたパス名を調べることでこれを行うことができ、それに応じてプロセスに別のシグナルを送信しました。

これは systemd では機能しません...私の init スクリプトは適切なタイミングで呼び出されますが、$0 は常に同じです (/etc/init.d/scriptname)。

システムのシャットダウンまたは再起動が原因で呼び出されているかどうかを systemd で知る方法はありますか? init スクリプトを削除して、代わりに systemd ターゲットとして構成できることをうれしく思いますが、ドキュメントからは、自分がやりたいことを行う方法がわかりません。

複数のシェルスクリプトを開始するサービスとして有効になっているシェルスクリプトがあります。

script1 は tmux ウィンドウでプログラムを開く必要があり、 を介してスクリプトを手動で開始すると問題なく動作./script1.shしますが、起動時にサービス開始スクリプトを介して開始すると、上記のエラーは発生しません。

なぜこうなった？

注: サーバーを管理したり、Linux を深いレベルで使用したりする実際の経験がないため、知識と理解はかなり限られています。本質的に、私はそれを翼にしています。

完全なコード例については、https ://github.com/Integralist/Vagrant-Examples/tree/master/nodejs を参照してください。

これは 2 つの部分からなる問題です。

1. 共有ディレクトリをマウントできない
2. systemd利用できないサービス

NodeJS アプリケーションを起動するサービスを作成しようとしていますが、systemctlインストールした Ubuntu のバージョン ( https://vagrantcloud.com/ubuntu/trusty64 ) では利用できないようです。

これが私のものVagrantfileです：

以下は、ファイルsetup.shを作成するプロビジョニング スクリプトの内容です。.service

しかし、実行するvagrant upと、次のエラー出力が表示されます。

したがって、私の最初の問題は、共有フォルダーをマウントできないように見えることです。

また、もともと私のプロビジョニング スクリプト (our-node-app.serviceファイルを作成した後) では、次のようになります。

これをプロビジョニング スクリプトに追加して実行するvagrant provision --provision-with shellと、次の出力が得られます。

systemctlこれは、コマンドが使用できないという問題を発見した場所です。

また、プロビジョニングスクリプトを変更して、代わりに...

...私は使うだろう...

これは、Ubuntu がサポートしていないことをどこかで読んだことがsystemdあり、その代わりに、upstartすべてのサービスを起動するために呼び出されたものを使用していたためです。当時は、他のコマンドを使用して、スクリプト自体を同じに保つことができると想定していました (そうではないようです)。

しかし、その変更は、私のサービスが認識されなかったことを示すだけでした:

その後、結局、 Ubuntu がこのフォーマットに移行することを発見しsystemdました。しかし、これは 2014 年 2 月に発表されたので、最新の Ubuntu は今頃には切り替えられていると思っていたでしょう (または、それは私が馬鹿であり、評価していないだけなのでしょうか)。そのような変更にかかる時間)。

このUpstart形式を使用する必要があると考えて、これを読み始めましたがsystemd、悲しいことに、スクリプトをUpstart形式に変換する方法を見つけることができませんでした.

これは私に質問を残します: ここに他の誰かがこの問題を抱えていましたか? もしそうなら、彼らはどのようにそれを解決しましたsystemdか?

systemdスクリプトを Upstart 形式に変換する方法に関するアドバイス (または適切なリソース) はありますか?

この件に関する助けをいただければ幸いです。冒頭で述べたように、私はシステム/サーバーの運用担当者ではないので、ここで説明します。

ありがとう。

アップデート

これを見つけたのですがsystemd、init.dとの違いを誤解していたようですupstart。とを改善systemdした新しいシステムも同様です。init.dupstart

systemdにリンクされている記事では、一緒にインストールしupstartてから に切り替える方法について説明してsystemdいますが、VM をマウントしようとしてもエラーが発生しますか?

レポコードを更新しました。

AとBの2つのサービスがあります。

A は、開始時に etcd に値を設定します。たとえば、環境ファイルから取得したパブリック IP アドレスです。

B は、起動時にその値と、独自の IP アドレスを必要とします。したがって、次のようなものがいいでしょう：

しかし、etcd 変数はそのような systemd 環境変数として存在しないため、明らかに不可能です。/usr/bin/bash -c 'run stuff'代わりに、自分で何らかの操作を行うことができますが、ExecStart特に systemd を展開する必要が$COREOS_PUBLIC_IPV4あり、新しい bash シェルを展開する必要があるため、厄介です$(etcdctl get /A_ADDR)。また、コードの匂いがして、何か重要なものが欠けていると思わせてくれます。

etcd からExecStart宣言に値を取得する「正しい」方法を教えてもらえますか?

- アップデート

だから私は稼働しています

しかし、それはかなり醜いです。何かを見逃していないなんて、まだ信じられない..