この質問は厳密にはプログラミングに関連しているわけではありませんが、プログラマーにとっては確かに重要です。
単純なSMTPサーバーを作成しました。コンソールから実行すると、コマンドラインをブロックしていることを除けば、すべて問題ありません。
私はそれを介して実行できることを知っています
nohup ... &
またはscreen/tmuxなどを介して
しかし、問題は、バックグラウンドで実行されるプログラムをどのように実装する必要があるかということです。システム管理者がプログラムをセットアップしてプロセスを管理することは喜ばしいことです。
私よりもはるかに経験豊富なgolang-nutsの人は、フォークなどを使用せず、monitなどの形式の「ラッパー」を使用していると書いています。
ターゲットプラットフォームはDebianベースであり、ボックス上の他のすべてのものはinit.dベースです。
そのトピックまたはよく書かれたサンプルプロジェクトのソースのための良いリソースはありますか？
Nickが述べたように、 Supervisordは、私の経験でもうまく機能した素晴らしいオプションです。
Nickは、フォークの問題について言及しました。フォーク自体はうまく機能します。問題はフォークではなく、特権の削除です。Goランタイムがゴルーチンが多重化されているスレッドプールを開始する方法（GOMAXPROX> 1の場合）のため、setuidシステムコールはアクセス許可を削除する信頼できる方法ではありません。
代わりに、非特権ユーザーとしてプログラムを実行し、setcapユーティリティを使用して必要な権限を付与する必要があります。
たとえば、低いポート番号（80など）へのバインドを許可するには、実行可能ファイルでsetcapを1回実行する必要があります。sudo setcap 'cap_net_bind_service=+ep' /opt/yourGoBinary
setcapをインストールする必要があるかもしれません：sudo aptitude install libcap2-bin
これについては、しばらく前にブログ記事を書きました。デーモン化のアイデアは、他の多くのことを心配する必要があるため、私には間違っているように思えます (たとえば、失敗したときに何が起こるか? プロセスの再起動をどのように管理するか? ロギング、作業ディレクトリ、コア、システムの再起動をどのように処理するか)など)
それをすべてやろうとしなければ、物事ははるかに簡単になります。
Supervisord works really well for this in my experience.
You write your app to run on the command line, print stuff etc and supervisord takes care of all the daemonising, restarting if it goes wrong, rate limiting etc, etc
I believe that forking go programs into the background in the traditional unix way is difficult because the runtime starts some threads before it runs your main() routine
しかし、問題は、バックグラウンドで実行されるプログラムをどのように実装すればよいかということです。システム管理者がプログラムをセットアップしてプロセスを管理するのは楽しいことでしょうか?
ここでいくつかの考え。
ソフトウェアをインストールすることと、それを維持して実行することはまったく別の話です。もちろん、zip をダウンロードして解凍し、ファイルを適切なディレクトリに配置し (通常、パッケージはファイル システム全体に分散していることに注意してください)、デーモンを実行するシステム ユーザーを作成し、適切な権限を設定します。しかし、それは面倒で、エラーが発生しやすく (これにより、「バー! 動かない! 修正してください!」などのチケットが大量に流入することになります)、ソフトウェアが多数のシステムにインストールされる場合はほとんど実用的ではありません。
そのため、採用のハードルを下げるパッケージが必要です。通常、これらのパッケージのリポジトリを提供することはロケット科学ではなく、インストールや更新をはるかに簡単にします。「ダウンロード->配布->インストール/更新」と単一のコマンド/サーバーのような違いがあります
$ awesomePm update coolApplication
少なくとも RedHat および Debian ベースのシステム用のパッケージを提供してください。個人的には、CentOS (パッケージをほぼすべての RHEL 派生物と互換性があるようにする) と基本的な Debian を選びます。後者により、Ubuntu 用のパッケージを提供することも簡単になります。私はもう Debian やその派生物を使用していないので、それらが本当に互換性があるかどうかはよくわかりません。最後に.deb.
適切なドキュメントを提供します。何が、どこに、なぜインストールされているかを文書化します。関連するドキュメントへのリンクを提供します。依存関係へのマンページ参照で十分です。このようにして、最も経験の浅い管理者でもパッケージを構成できるようにします。
最も防御的で健全なデフォルトを使用します。
golang に関する特記事項: ほとんどのパッケージ ビルド ツールは、デフォルトでパッケージに含まれるバイナリを削除します。Go はそれをサポートしていないので、ここでは注意してください。
不完全なパッケージほど煩わしいものはありません。
可能な場合は syslog を使用し、その規則に従います。このようにして、ログはシステム管理者が期待する場所に配置され、古くなった場合は自動的に処理され、アプリケーションがディスクをいっぱいにするのを防ぎます. システム管理者がアプリケーションのログを特別に処理したい場合は、このように構成します。
アプリケーション経由でログをローテーションしないでください。それらをどうするかは、ユーザーの選択です (これはユーザーの SLA に関連している可能性があります)。ログをローテーションする方法を構成可能にしても、管理者はその構成方法を学ばなければならず、不要な冗長性が生じます。
ログ ファイルに書き込む必要がある場合は、ターゲット システムのロギング ポリシーに従い、ログ ローテーション構成ファイルを提供します。マシンのディスク容量が不足したからといって、アプリケーションがダウンタイムの原因になることは望ましくありませんか?
車輪の再発明ではなく、システム ツールを使用します。アプリケーションでメンテナンスを行う必要がある場合は、アプリケーション内でわざわざスケジューラを使用しないでください。メンテナンス専用のツールを作成し (モノリシック アプリケーションは '00 年代です)、利用しcronます。具体的には、対応するファイルを/etc/cron*ディレクトリの 1 つに追加します。
適切な初期化スクリプトを提供してください! このようにして、管理者はよく知られているツールを使用してsystemctl、アプリケーションの起動とシャットダウンを管理できます。ユーザーに対して、または起動時にシェルスクリプトを呼び出すためにsu使用する必要がある場合は、かなり面倒です。sudo -uこのスクリプトが呼び出されても@onboot、標準からの逸脱は迷惑です。起動方法が機能するからといって、それを使用する必要があるわけではありません。
SE-Linux プロファイルを追加するためのボーナス ポイント!
言うまでもありませんが、パッケージの設定ミスが頻繁に見られるので、パッケージをテストしてください。ターゲット OS の最小限のインストールから始めて、パッケージをインストールし、期待どおりに動作することを確認します。提供するすべての構成を確認してください。
パッケージを公式の Debian リポジトリに入れる予定がある場合は、ある程度の時間を計画する必要があります: Debian が安定している理由は、パッケージの要件が非常に厳しいためです。テストから不安定版を経て安定版への道。
便利だからという理由だけで既存のユーザーを使用しないでください。Web アプリケーションを作成する場合は、「apache」または「www」ユーザーを再利用しないでください。パッケージ専用のユーザーを作成し、このユーザーを適切なグループに追加します。
必要最小限のアクセス許可の原則に従います。バイナリワールドを実行可能にする理由はほとんどありません。アプリケーションが実行されない場合に SO でよく目にするのは、パーミッションを [0]777 に設定するという提案です。これにより、すべてのユーザーがファイルを変更できるようになります。実際には、バイナリを任意のユーザーが書き込み可能にする理由はほとんどありません。とにかく更新を行う root は、いつでも何でも書き込むことができます。したがって、権限は0550バイナリ用。この原則は、データ ディレクトリなどにも適用されます。ここに時間と労力を投資してください。アプリが攻撃を成功させるための媒体になりたくありませんか? 潜在的なセキュリティ リスクでさえ、あなたとあなたの評判に反撃する傾向があります。私がよく行うのは0600、アプリケーションのシステム ユーザーが書き込む必要があるファイル、0400読み取り専用ファイル、および0500バイナリに対して、すべてのデータ ファイルを に設定することです。次に、グループの権限がどうあるべきかを詳細に分析します。例: グループは、Web アプリケーションの個々のテンプレートを変更する場合がありますが、リソース ディレクトリ サブツリーのディレクトリ構造は変更しない可能性があります。
セキュリティに力を入れれば、信頼が高まります。パッケージは、採用するかどうかを決定する前に、セキュリティへの影響についてチェックされることが多いことに注意してください。
FHS（!!）を遵守してください！それでも、 の下で何でもできるからといって/opt/yourapplication、そうするのが常に良い考えであるとは限りません。むしろ、/usrおよび に/varそれぞれインストールします (起動時にアプリケーションが必要ないと仮定します)。
依存関係がある場合は、それらを定義します。パッケージが存在すると単純に仮定しないでください。
ローカル SMTP サーバーに依存している場合は、依存関係を宣言しないでくださいpostfix。おそらく、管理者は sendmail を好みます (理由は何であれ)。mail-transport-agentそのため、代わりに(Debian) またはmta(RH, iirc)への依存関係を定義してください。
これが私が優れたソフトウェアに期待することです。つまり、既存のソフトウェアとうまく統合し、冗長な構成を学ぶ必要なく簡単にインストール、保守、構成、および実行できるようにすることです。パッケージの SELinux プロファイルを見た場合、それは本当にベンダーにボーナスを与えます – プロファイルが非常にずさんでない限り、ベンダーがセキュリティを非常に真剣に考えていることを示しています.