web-dev-qa-db-ja.com

upstartはまだanacronの確実な代替品ですか？

スタートアップFAQ 言います：

Upstartはcron、atd、またはanacronを置き換えますか？

はい。 Upstartで計画されている機能は、特定のスケジュールされた時間、定期的なスケジュールされた時間、または特定の時間間隔でイベントを生成する機能です。

しかし、ページの下部には、2009年に作成されたと書かれています。これらの計画された機能はまだ導入されており、anacronの代わりにupstartを使用するのが実用的ですか？

また、upstartはユーザーごとのタスクをすぐに処理できます（たとえば、anacronとは異なります）。

upstartanacron
4
Geoffrey Irving

Upstart 1.10以降（Ubuntu 13.10で使用）：

現在のドキュメントのアップスタートは http://upstart.ubuntu.com/cookbook にあります

Cronおよびanacron機能は、Upstartにはまだ実装されていません。

参照： http://upstart.ubuntu.com/cookbook/#run-a-job-periodically

11.26ジョブの定期的な実行

これは現在、Upstartで直接処理することはできません。ただし、現在取り組んでいる「一時的なイベント」機能はこれに対処します。

一時的なイベントが利用可能になるまでは、cron（8）または次のようなものを使用する必要があります。

 # /etc/init/timer.conf

 instance $JOB_TO_RUN

 script   for var in SLEEP JOB_TO_RUN   do
     eval val=\${$var}
     if [ -z "$val" ]
     then
       logger -t $0 "ERROR: variable $var not specified"
       exit 1
     fi   done

   eval _sleep=\${SLEEP}   eval _job=\${JOB_TO_RUN}

   while [ 1 ]   do
     stop  $_job || true
     sleep $_sleep
     start $_job || true   done end script

ユーザーごとのタスクは、1）ユーザーとしてジョブを実行する[Upstartが行う]または2）システムイベントの代わりにユーザーレベルのイベントを発行およびリッスンする[Upstartも行う]のいずれかを参照できます。

ユーザーとしてジョブを実行する方法は http://upstart.ubuntu.com/cookbook/#run-a-job-as-a-different-user で説明されています

11.43.2ユーザーの変更

一部のデーモンはスーパーユーザーとして実行を開始し、内部で特権レベルを他の（特権の低い）ユーザーにドロップするように調整します。ただし、一部のデーモンはこれを行う必要がありません。ルート権限を必要としないため、非ルートユーザーとして呼び出すことができます。

「システムジョブ」をどのように実行しますが、それを非rootユーザーとして実行しますか？ Upstart 1.4以降、Upstartには、setuidおよびsetgidスタンザを使用して、指定されたユーザーとしてシステムジョブを実行する機能があります。

ただし、Upstart 1.4を使用していない場合、必要な目標を簡単に達成できます。使用できる方法はいくつかあります。 DebianおよびUbuntuシステムに推奨される方法は、次のようなヘルパーユーティリティstart-stop-daemon（8）を使用することです。

 exec start-stop-daemon --start -c myuser --exec command

Start-stop-daemon（8）を使用する利点は、コマンドが実行されるユーザーとグループを単に変更することです。これは、su（1）がPAMセッションを開いたままにできるようにするために分岐する必要があるため、su（1）よりも利点があります。したがって、start-stop-daemon（8）は単にuid/gidを変更した後に指定されたコマンド。

認識すべき別の潜在的な問題は、start-stop-daemonが、開始するプロセスにPAM（「プラグ可能認証モジュール」）の制限を課さないことです。そのような制限は、適切なUpstartスタンザを使用して設定できます。PAMのlimit.conf（5）で制限を指定することはできません。

もちろん、PAMの制限を設けたい場合があります。その場合は、su（1）またはSudo（8）を使用する必要があります。両方ともPAMライブラリにリンクされています。

一般的なアドバイスは、PAMの制限が実際にはシステムサービスに適していないため、su（1）またはSudo（8）を使用しないことです。たとえば、PAMはsu（1）またはSudo（8）が呼び出されるたびにwtmp（5）エントリを作成し、これらのレコードはシステムサービスに適していません。

Su（1）またはSudo（8）を使用する場合、以下の例でその方法を示します。

Su（1）を使用：

 exec su -s /bin/sh -c command $user

上記を次のように簡略化できますが、ユーザー "$ user"が/ bin/falseとして指定されたシェルを持つシステムアカウントである場合、ジョブは指定されたコマンドを実行しないため、お勧めできません。/bin/falseに「1」を返します：

 exec su -c command $user

ユーザー "$ user"が/ bin/falseとして指定されたシェルを持つシステムアカウントである場合、ジョブはサイレントに失敗します。

シェルが生成されることによって引き起こされるfork（2）を回避するには、代わりに以下を指定できます。

 exec su -s /bin/sh -c 'exec "$0" "$@"' $user -- /path/to/command
 --arg1=foo -b wibble

この手法は、ジョブがexpectを使用するサービスジョブである場合に特に役立ちます。

Sudo（8）を使用した基本的な例：

 exec Sudo -u $user command

ユーザーレベルのジョブ（「セッションジョブ」と呼ばれる）は http://upstart.ubuntu.com/cookbook/#session-job で説明されています。

4.2.3セッションジョブ

Upstart v1.7以降

セッションジョブは、古いユーザージョブに似ています。古いユーザージョブとは異なり、セッションジョブはPID 1として実行されているUpstartによって管理されません-ユーザー自身のセッション初期化によって管理されます。

UpstartがPID 1として実行される場合とは異なり、セッション初期化は複数のディレクトリからジョブ構成ファイルを読み取ることができます。ジョブが読み込まれるディレクトリのリストは、次のとおりです（順番）。

 $XDG_CONFIG_HOME/upstart/ (or $HOME/.config/upstart/ if $XDG_CONFIG_HOME not set).
 $HOME/.init/ (deprecated - supported for legacy User Jobs).
 $XDG_CONFIG_DIRS
 /usr/share/upstart/sessions/

上記のディレクトリ名のいずれかが削除されると、各ジョブの名前がベース名になります。たとえば、ジョブ構成ファイルが$ HOME/.config/upstart/hello/world.confとして存在する場合、その名前は「hello/world」になりますが、ジョブ構成ファイルが/ usr/share/upstart/sessions /として存在する場合foo/bar.conf、その名前は「foo/bar」になります。

Upstartは、検出した最初の有効なジョブ（またはオーバーライドファイル）を受け入れるだけで、名前の衝突を解決します。たとえば、次の2つのファイルが存在する場合：

 $HOME/.init/foo.conf $HOME/.config/upstart/foo.conf

最初の$ HOME/.init/foo.confのみが使用されます。一方、次のファイルが存在する場合：

 $HOME/.init/foo.conf $HOME/.config/upstart/foo.conf
 $HOME/.config/upstart/foo.override

Upstartは最初に$ HOME/.init/foo.confを読み取り、次に$ HOME/.config/upstart/foo.overrideの変更を適用します。

2
user535733