web-dev-qa-db-ja.com

通常のユーザー（root以外）に初期化とシャットダウンの自動実行機能を提供する

私はDebianWheezy 7.4.0ディストリビューションを実行している、実験的/テスト用のLinuxボックスをホストしています。さまざまなユーザーがsshを介して自分のアカウントにマシンにログインし、必要に応じて開発ツールを実行し、プログラムをバックグラウンドでサービスとして実行したままにすることができます。

これはあらゆる種類の目的のテストマシンであるため、多くの場合、マシン全体を再起動する必要があり、ユーザーは再度ログインして、実行中のユーザースペースのものを再起動する必要があります。それを自動化したいと思います。基本的に、マシンの起動直後（他のすべてが初期化された後）に起動する手段と、システムのシャットダウン時に起動する手段（時間制限なし、基本的にすべてのシャットダウンまでシャットダウンを停止する）をユーザーに提供したいと思います。ユーザープロセスが完了しました）。

これまでに試したこと：
/etc/init.d /の下の「スケルトン」テンプレートファイルにある原則に従って、init bashスクリプトを作成しました（スケルトンテンプレートのソースコード： https：// Gist。 github.com/ivankovacevic/9917139 ）

私のコードはここにあります： https://github.com/ivankovacevic/userspaceServices

基本的に、スクリプトはユーザーのホームディレクトリを調べ、.startUp、.shutDown、または.statusという名前の対応するサブディレクトリで実行可能ファイルを探します。現在進行中のイベントに応じて、スクリプトはsuを使用して、ユーザーが自分でスクリプトを開始したかのように実行されます。

私が現在このアプローチで直面している問題は、システムの起動後に奇妙なプロセスがハングしたままになり、スクリプトが他のユーザーのすべてのプロセスを開始することです。プロセスリストでは次のように表示されます。

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
root      3053     1  0  1024   620   1 17:42 ?        00:00:00 startpar -f -- userspaceServices

そのプロセスが何であるかはわかりません。そのためのmanページには-f引数が記載されていません。だから私は無知ですが、init.dの他のスクリプト/サービスが起動後にそのようなプロセスをハングさせたままにすることはないので、私は何か間違ったことをしているに違いありません。

だから私は私が持っているこのソリューションをデバッグするのを手伝ってくれる人を探しています（これも私の意見では少し複雑に思えます）。または、これをまったく異なる方法で実装する方法を教えてください。

[〜＃〜]更新[〜＃〜]
startparの問題について別の質問を開始しました： rc.localからプロセスを開始するとstartparプロセスがハングしたままになりますまたはinit.d

UPDATE 2
元の解決策で問題が解決しました。前述の質問でstartparを確認してください。 GitHubのコードも、それを反映するように修正されています。

UPDATE 3-crontabの使用方法
Jennyが提案したように、通常のユーザーはcrontabを使用して起動時にタスクが1回実行されるようにスケジュールできます。必要なのがシャットダウンではなく起動時にユーザータスクを開始することだけであれば、これが最も簡単な方法だと思います。ただし、ユーザーが進行中のサービスのようなタスクを起動するときに、cronプロセスを親として「ハング」させたままにしておくことができるという欠点があります。まず、それがどのように機能するかを説明しましょう。

通常のユーザー自身が電話する必要があります：

crontab -e

（-e asedit）これにより、ユーザーのcrontabファイルを使用してデフォルトのコンソールテキストエディタが開きます。起動時に実行するタスクを追加するには、ユーザーはファイルの最後に1行追加する必要があります。

@reboot /path/to/the/executable/file

ここで、ユーザーがそれを実行し、そのファイルが何かを直線的に完了して終了する単純なスクリプトではなく、たとえば再起動後、プロセスリストで次のようなもので終了するようなウォッチドッグである場合。

    1  2661 root       20   0 20380   860   660 S  0.0  0.0  0:00.00 ├─ /usr/sbin/cron
 2661  2701 root       20   0 33072  1152   868 S  0.0  0.0  0:00.00 │  └─ /USR/SBIN/CRON
 2701  2944 someuser   20   0  4180   580   484 S  0.0  0.0  0:00.00 │     └─ /bin/sh -c ./watchdog
 2944  2945 someuser   20   0 10752  1204  1016 S  0.0  0.0  0:00.00 │        └─ /bin/bash ./watchdog
 2945  2946 someuser   20   0 23696  4460  2064 S  0.0  0.1  0:00.01 │           └─ /usr/bin/python ./some_program.py

これを回避するには、ユーザーがcrontabエントリを次のように変更する必要があります。

@reboot /path/to/the/executable/file >/dev/null 2>&1 &

ファイル記述子のリダイレクトはオプションですが、クリーンに保つことをお勧めします。理由を調べたい場合は、それらを見てみてください。

ls -l /proc/pid_of_started_process/fd
linuxbashbootuser-managementinit.d
7
Ivan Kovacevic

私はあなたの解決策が少し複雑に見えることに同意するので、「これをまったく異なる方法で実装する方法を教えてください」と言います:-)

  1. このための標準的な解決策は、puppetなどの構成管理システムを使用し、ユーザーがサーバーのpuppet構成に自分のものを追加できるようにすることです。次に、Puppetは開始スクリプトをプッシュして、関連するランレベルに追加します。

  2. より迅速な方法は、彼らに/etc/rc.d/rc.localへのsudoeditアクセスを許可し、そこに彼らのものを追加することです。

  3. または、開始したい開始スクリプトを配置するディレクトリを各ユーザーに提供し、cronジョブでそれらのスクリプトを/etc/init.dにコピーし、適切な場所にsu $USER -cを挿入して、chkconfigを実行します。

  4. または、それぞれに開始スクリプトを配置するディレクトリを指定し、/etc/rc.d/rc.localの最後にいくつかの行を追加して、それらのディレクトリを調べ、それらの各スクリプトでeditedsu $USER -c 'script start'を実行します。 。

編集して追加： 5.crontabを使用して実行するジョブをスケジュールできるようにします@reboot

8
Jenny D