実行可能ファイルをサービスとして実行するにはどうすればよいですか？
Ubuntu 18.04では、次の方法でいくつかのサービスを開始または停止できます
Sudo service cron start/stop
いくつかのサービスをリストできます
service --status-all
出力は、/etc/init.d/の下のファイルと一致します。
サービスを管理するにはいくつかの方法があると聞きました：system V init、systemd、upstart、..。どちらを使用していますか？ man serviceは、システムV initであることを示しています。しかし、Linuxはinitをsystemdに置き換えていると聞きました。 Ubuntuでは、initではなくsystemdを使用しますか？
任意の実行可能ファイル（ELFまたはシェルスクリプト）をサービスにするにはどうすればよいですか？
https://stackoverflow.com/a/19235243/156458 のように、setsidによって実行可能ファイルを明示的にデーモン化する必要がありますか？
以下の投稿のいずれかに該当しますか？
ありがとう。
Ubuntu 18.04では、[...]
サービスを管理するにはいくつかの方法があると聞きました：system V init、systemd、upstart、..。どちらを使用していますか？
あなたはsystemdを使用しています、それはUbuntu 18.04に同梱されているinitです。 （Ubuntu 16.04、Fedora、openSUSE、Arch Linux、RHEL 7、CentOS 7、CoreOS、およびDebian 9のデフォルトでもあります。）
Systemdを実行していることを確認する1つの良い方法は、systemctlコマンドを実行することです。それが利用可能で、実行時に出力が生成される場合は、systemdを実行しています。
Ubuntu 18.04では、次の方法でいくつかのサービスを開始または停止できます
Sudo service cron start/stopいくつかのサービスをリストできます
service --status-all
一部のsystemdディストリビューションに同梱されているserviceコマンドは、主に下位互換性のために存在することに注意してください。代わりにsystemctlを使用してサービスを管理する必要があります。
例えば：
$ Sudo systemctl start cron
$ Sudo systemctl stop cron
$ systemctl status cron
そして、あなたはシンプルですべてのユニットのステータスを見つけることができます
$ systemctl
出力は、
/etc/init.d/の下のファイルと一致します。
Systemdのネイティブ単位は/etc/systemd/system/と/usr/lib/systemd/system/に格納されるため、systemctlの場合は必ずしもそうではありません。
systemdには、古いSysV initスクリプトとの互換性が含まれています（ systemd-sysv-generator を使用して、initスクリプトからコマンドを呼び出すsystemdネイティブサービスユニットを作成します）。したがって、/etc/init.d/、おそらくsystemdにも表示されます。
Ubuntuでは、initではなくsystemdを使用しますか？
この質問は不明確です。
initという用語は通常、システムの起動時に最初に実行されるプロセスを指し、プロセスはPID 1で実行されます。systemdはPID 1で実行されるため、定義上、systemd is init（など）それ以前は新興企業であり、SysV initも同様でした。）
「SysV initの代わりにsystemdを使用する必要がありますか？」と質問された場合は、Ubuntu 18.04を使用しているため、SysV initの代わりにsystemdを使用するalreadyです。 （そして、上記で指摘したように、最近選択するほとんどのディストリビューションには、おそらくsystemdが初期化として含まれています。）
ここで、「initスクリプトの代わりにsystemd nitsを使用する必要がありますか？」間違いなく両方のオプションが機能する場所をここで選択できるため、その質問はより関連性があります。
ここでの推奨は、ネイティブの操作モードであるsystemdユニットを使用してサービスを管理することです。 initスクリプトを作成すると、単に間接層が追加されます（とにかくジェネレーターがsystemdユニットを作成するためです）。さらに、systemdユニットの記述は、適切にデーモン化とスクラブを心配する必要がないため、initスクリプトの記述よりも簡単です。 systemdがすべてを実行するので、実行前の環境。
任意の実行可能ファイル（ELFまたはシェルスクリプト）をサービスにするにはどうすればよいですか？
systemdサービスユニット を作成します。
Manページの例を参照してください。最も単純な例は、サービスユニットの作成がいかに簡単かを示しています。
[Unit]
Description=Foo
[Service]
ExecStart=/usr/sbin/foo-daemon
[Install]
WantedBy=multi-user.target
このユニットを/etc/systemd/system/foo.serviceに保存し、systemdをリロードしてこのユニットファイルを次のように読み取ります。
$ Sudo systemctl daemon-reload
次のコマンドでサービスを開始します。
$ Sudo systemctl start foo.service
そして、起動時にそれを有効にします：
$ Sudo systemctl enable foo.service
次の方法でサービスのステータスを確認できます。
$ systemctl status foo.service
もちろん、systemdはサービスを管理するために多くのことを実行できます。そのため、一般的なsystemdユニットはこれよりも長くなります（ただし、それほど複雑ではありません）。/usr/lib/systemd/system/*.serviceでUbuntuに付属するユニットを参照して何が典型的で何が期待できるかについてのより良い絵。
https://stackoverflow.com/a/19235243/156458 のように、
setsidによって実行可能ファイルを明示的にデーモン化する必要がありますか？
番号！バックグラウンドで実行しないでください。プロセスグループやセッションなどについて心配する必要はありません。systemdがすべてを処理します。フォアグラウンドで実行するコードを書くだけで、残りはsystemdが処理します。
（バックグラウンドで実行されるサービスがある場合、systemd canType=forkingを使用して管理しますが、フォアグラウンドで実行する方がはるかに簡単なので、開始している場合はそれを行ってください新しいサービス。）
以下の投稿のいずれかに該当しますか？
これは「Spring Boot」を使用するアプリケーションに関するものですJavaフレームワーク。Javaコードを記述してそのフレームワークを使用しているのでない限り、関係ありません。 Javaコードを書いています。代わりに、サービスをフォアグラウンドで実行してみてください。
問題は新興企業に関するものであり、答えはSysV initスクリプトに関するものです。 SysV initスクリプトはsystemdで動作しますが、前述のようにsystemdユニットを直接作成することをお勧めします。
だから、いいえ、どちらも関連性がないと思います。
代わりにsystemdサービスユニットの詳細を学ぶことをお勧めします。
このサイトはそのための優れたリソースでもあるので、サービス用に独自のsystemdユニットの作成を検討する際は、このサイトについてさらに質問を投稿してください。
システムのネイティブデーモンサービスマネージャーは何ですか？
mostのlinux initは、他のすべてのサービスとプロセスが生成される場所です。
ネイティブデーモンサービスマネージャーはman init。