matsuand です。 いろいろお話をあげて頂いていますので、内容を伺いながら 作業を進めますが、話が技術論にのみ傾いていて、何を為すこと が本来的であるかの話が、抜けているように感じます。 今の私の結論からすると、cron では以下のスクリプト /home/groups/l/li/linuxjm/jm.git/admin/cron/webupdate.sh を実行するのですが、crontab -e にて、sg コマンドを使って sg linuxjm /home/groups/l/li/linuxjm/jm.git/admin/cron/webupdate.sh というコマンド行にすれば、万事解決するように捉えています。 (まだ実行確認はしていません。これが最も理に叶った対処に 感じています・・ 自信はありません。sg コマンドも、今回初めて 知ったものなので、これ以外の方法論は持ち合わせていません。) これはちなみに ribbon さんが [JM:03577] において > 解決法はいくつかあります。 > > 1) 起動するプロセスの gid が linuxjm になるようにする。 > 2) 起動するプロセスの uid が 各ファイルの uid と同じになるようにする。 > 3) 各ファイル/ディレクトリの uid を、起動するプロセスの uid と同じにする。 > 4) rsync で omit-dir-times を指定する。 の、まさに 1) を実現する方法です。 ちなみに 2), 3) は、対処が大層多くなるため、作業負荷があります。 4) は、意外にも実効性があります。根本解決になっていませんが。 ----- 今回のサーバーエラー発生がそもそもなぜ発生したかと言えば、 それまで cron ジョブが amotoki アカウントで実行されていて、 元木さんに対する責任負担を除く目的で、matsuand アカウント での実行に移転したところから発生したものです。それまで amotoki アカウントによりプロセス実行や、生成ファイル類の パーミッションがうまく噛み合っていたところに、matsuand アカウントでの cron 実行に切り替えたことで、ほころびが 出てしまったというものです。 グループ ID が適合しないことからくるエラーであることが 分かってきたわけですが、ここでエラー解消のために考える べきなのは、エラー解消すればそれで良い、というものでは ないと思います。そもそも matsuand アカウントへの移行から 発生した本件は、また次に例えば ribbon アカウントへ移行 した時に、全く同じ不具合が出て、また右往左往するようで あってはならないわけで、そのためには管理者の引き継ぎ文書 をしっかり作らねば、という話も出てきますが、最小限の 設定で、あるいは細々としたことを覚えていなくても、あるいは 引き継ぎがうまく出来なかったとしても、本件に関しては、 エラーなく引き継げることができれば、それが効果最大であり、 目指すべき対処のあり方かと思います。 その意味で言うと、冒頭に示した sg コマンド利用による cron ジョブ実行は、crontab -e を誰が定義しても、 その作業以外に chown とか chmod とかしなくても、 動作してくれるはずです。引き継ぎ文書には、 crontab を現状と同じく定義すべし、 と書けばそれで終わりです。 いかがでしょうか。 つまりプログラム設計レベルで考えるのではなく、 そもそもの方針論、つまりシステム方式設計を考えるべき 話かと感じています。
Fork