☰

@reboot cronジョブで「screen」を実行する

tag-icon • tag-icon cron gnu-screen
@reboot cronジョブで「screen」を実行する

起動時に画面からスクリプトを実行したいです。

これはうまくいきません：

@reboot pi screen -d -m /home/pi/db_update.py

ただし、ユーザー pi でこのコマンドを手動で実行すると、次のように動作します。

screen -d -m /home/pi/db_update.py

私が何を見逃しているのか知っていますか？

答え1

ユーザーとして実行し、@reboot pi ...代わりに以下を追加する必要があります。/etc/crontabcrontab -epi

@reboot /usr/bin/screen -d -m /home/pi/db_update.py

screenへのフルパスを使用し（単にそれなしで動作することを確認するために）、/home / piが暗号化されたファイルシステムにないことを確認してください（完了）。このコマンドは、cronデーモンが起動したときやユーザーがログインした後にのみアクセスできるものには依存しません。

ログインして接続するのに十分な時間を許可するために何かを追加するかdb_update.py（実際に実行されていることを確認するためにファイルに書き込む/var/tmp）、time.sleep（600）をPythonプログラムの最後に置くこともできます。

Lubuntu 13.04、Python 2.7.4でテストされており、エントリは次のとおりです。

@reboot screen -d -m /home/anthon/countdown.py

そしてcountdown.py：

#!/usr/bin/env python
import time
for x in range(600,0,-1):
    print x
    time.sleep(1)

（そしてchmod 755 countdown.py）

答え2

起動時に画面を何かに接続する必要があるのですが、少し異なるユースケースがあります。 2つのヘッドレスサーバーがあり、そのうちの1つにシリアル出力のみがあります。シリアルケーブルを介して別のヘッドレスサーバーに接続し、画面を使用してシリアル接続を介して対話する必要があります。また、シリアルセッションを表示しないときに生成されたすべての出力がキャプチャされることを確認する必要があります。

私はrootのcrontabにこれを持っています

@reboot    /usr/bin/screen -d -m -c .screenrc -L /dev/ttyS0

セキュリティ更新プログラムが適用されると、設定された時間にサーバーが再起動されます。必要に応じて表示されるように、特に名前の付いたログファイルが必要です。私のファイル.screenrcにはこのエントリがあります。

logfile "/root/.screen_%H_%Y%m%d_%c.txt"

したがって、次の画面セッションが開始されると、ログファイルは/home/root/.screen_$HOSTNAME_$YYYYMMDD_$h:$mm.txt。

答え3

これは回避策かもしれませんが、スクリーンセッションを呼び出すシェルスクリプトを実行して問題を解決しました。

[dude@server ~]$ crontab -l | grep sh
@reboot /home/dude/.autoscreen/start.sh
[dude@server ~]$ cat /home/dude/.autoscreen/start.sh
#!/bin/bash
cd ~
screen -S myname -d -m custom_script

答え4

起動時に実行される画面で何が起こっているのかを調べる簡単な方法がいくつかあります。

  • 始めましたか？再起動後、次の行の後に1行を返す必要がgrep CRON /var/log/syslogあります。CMD(CRON) INFO (Running @reboot jobs)

  • 起動しても画面を見たときに画面が消えた場合は、コマンドを終了してください。これをデバッグする方法があります。たとえば、次のようになります。

    • その後、実行を続けるようにシェルを実行すると、説明されているように出力を確認できます。https://unix.stackexchange.com/a/47279/103306-screen ... -- sh -c "your command; exec sh"
    • たとえば、script(1) でコマンドを実行し、screen ... -- script -f yourcommand.boot.log -c "your command"ログファイルを確認します。

FATAL私の場合、起動は完了せず、エラーメッセージを表示するローカルのPostgreSQLデータベースに接続しようとするスクリプトでした。cronつまり、すべてが正常ですが、screenシステム起動シーケンス中に組み合わせが速すぎます。

また、グローバルcrontabファイル（）からユーザーファイルに切り替える必要がないことにも注意してください。/etc/crontabたとえば、コマンドを使用して作成するときに中間点があります。/etc/cron/local-pi-whathaveyouこれにより、確認する人には明らかです/etcが、権限のないユーザーはそのまま残ります。

関連情報