会社のシステムで、週次で各自/会社全体の実績/行動予定の周知、月次で会社の月間業績周知などをメールで流しています。

今までは、外部サーバの付属でついてきたcronサービスで該当サーバ上のDBのデータで色々と動かしていたものの、それを「スマホ撮影の写真を勝手に振り分けて社内システムに保管する！」により、DBが外部サーバから自社サーバへ移動したために、cronも再構築することとなった。

タスクを実行しても動かない？！

Synolodyでは、コントロールパネルの中に、タスクスケジュールが実装されていて、そこにユーザー指定のスクリプトを指定するだけ。

というわけで、「php /volume1/~」などと記載して該当画面から「実行」を押下しても動きやしない。

ブラウザから該当のphpを叩くと、メールが送付される。

うーむ…。

サポートに連絡すると、phpじゃなくて、php56だよ！という指示をもらい、タスクスケジュールに「php56 /volume1/~」としても動かない。

うーむ…。

試行錯誤の結果、telnetでログインして該当のphpファイルをphpコマンドで実行してみると、エラーが色々と表示される。

初めからこっちで試すべきでしたね。

ちなみに、telnetでphp56コマンドで実行してもそんなコマンド無いよ！と言われるので、php56の謎は深まるばかり。

エラー内容により、設定ファイルは、ブラウザからの場合は該当phpからの相対パスなものの、コマンドとして実行する場合は、OSとしての絶対パスが必要、ということでphpファイルを変更して、tenleでログインして該当のphpファイルをphpコマンドで実行すると無事にメールが送付できた。

でも、まだ動かない！？

telnetから実行して動いたので、Synologyのコントロールパネルから試しに起動しても動かない？！

どうなってるのか…。

ここでタスクスケジュールから、コマンドを再度、「php56 /volume1/~」で実行すると無事に起動。

なぜ、telnetで実行できないphp56コマンドが、synologyのタスクスケジュールからは実行できるのか…。

しかも、違うスクリプトはタスクスケジュールで「php /volume1/~」と設定し動いているものもある始末。

まとめ

Synologyのタスクスケジュールでphpファイル実行する場合は…

• php内のパス表記はWEBベースの相対パスではなく、OSベースの絶対パスを記載
  • openbase_dirをあれこれすると動きそうだったけど断念。動けば正義。
• メール送付（mb_send_mailなのかなぁ）を実行する場合は、「php /volume1/~」ではなく、「php56 /volume1/~」で実行する（？）

というわけで、事なきを得ました。（と、思っておきます。）

後日記載

と、思ったらやっぱりタスクで動きませんでした。

今度は、タスクスケジュールに「php /volume1/~」で記載し、「実行」すると無事に動く始末。

何故だ…、謎は深まるばかりです。