トマトジュース

トマトジュースは健康にもダイエットにもよいということなので安直ながらのみ始めた。
娘もちびっ子には珍しくトマトジュースが飲めるっぽいので一緒にのんでいる。
健康でも開発でも何事も銀の弾丸はないので継続あるのみなのだ。

プログラマー vs 運動不足

きっかけ

プログラマーは、だいたい運動不足になりやすい仕事だ。

PCに向かって色々調べ物している時やプログラミングしている時が一番楽しい時なので、動かなければいけないという差し迫った状況にないと際限なくPCの前で座っている人も少なくない。

オフィスで仕事をしているプログラマーであれば出社が必須なので少なくとも通勤という名の運動ができるが、今風に在宅勤務するようなプログラマーというのは本当に運動をする機会がない。

私自身、この春から週に一度ずつ在宅勤務をしていたのだが最初の数回は朝時間になったらPCの前に座り、昼休憩以外はずっとPCの前から全く動かないという不健康極まりないありさまだったのだ。

しかし、いろいろな状況が重なって私は2015年9月から週に3回程度の在宅勤務になる予定だ。こうなると運動不足が今以上に深刻な問題になってくると思っている。

そして私は現在35歳。大学入学時に178センチ65キロ程度だったのが、大学卒業時には70キロを超え、中年になった今や83キロもあるのである。18キロ程度、生命活動に不要なことが明らかな肉があるということだ。会社の同僚にも「体脂肪率30%!体の30%が油!」と言われてしまうのだ。

これ以上、運動不足な人生を送って贅肉を増やしていくのはリスクしかない。在宅勤務が増えて加速度的に体重を増やしてしまうと、生産性は脂肪による死亡で0になる。つまり人生を変える時が来たのだ。

冴えた解決策

だいたいにおいて、一人の人間が合理性を追求して出した結論というのは異様に見えることがある。

fitdeskという商品はまさにそれであろう。

FitDesk X-2.0 ジャパンモデル(フィットデスクX-2.0 ジャパンモデル )エアロバイク、パソコン

私にとっては合理性の限りを追求するとこの製品のような結論に達するのはごく自然であることに感じられるのだが、世間様の評判を調べると「何たるネタ商品!」みたいな感じの扱いをされてしまっている。

と言うわけで、我が家にはfitdeskがある。これから、fitdeskに乗りながら本blogを書いていくという算段なのだ。実は昨日書いた記事もこれに乗って書かれている。 mitomasan.hatenablog.com

食事制限をするつもりはあまりないので、業務中にこの机にまたがっているだけでどれだけの効果があるか、気になるところである。

cronのクラスタリングサポート(CentOS7)

ある日、突如 cron に疑問を感じ man cron を実行してみた。 たまたま CentOS7 だったのだが、「CLUSTERING SUPPORT」なるセクションがありびっくりした。 cronでクラスタリングとな!

びっくりしたのはいいが、実際に何をやってくれるのかはさっぱりわからなかったので和訳してみることにした。

以下、和訳。間違いがあればすいません。

*1

クラスタリングサポート

In this version of Cron it is possible to use a network-mounted shared /var/spool/cron across a cluster of hosts and specify that only one of the hosts should run the crontab jobs in this directory at any one time. This is done by starting Cron with the -c option, and have the /var/spool/cron/.cron.hostname file contain just one line, which repre- sents the hostname of whichever host in the cluster should run the jobs. If this file does not exist, or the hostname in it does not match that returned by gethostname(2), then all crontab files in this directory are ignored. This has no effect on cron jobs specified in the /etc/crontab file or on files in the /etc/cron.d directory. These files are always run and considered host-specific.

本バージョンの cron はネットワークマウントされた共有の /var/spool/cron を クラスタのホストをまたがって、どの時点においても一つだけのホストが実行すべき ジョブを実行することができる。これは -c オプションを与えて cron を起動すれば 実現できる。そして、/var/spool/cron/.cron.hostname に一行だけあれば そこに属するクラスタのいずれかのホストがジョブを実行すべきジョブを実行する。 もし、このファイルがないか hostname が gethostname(2) にマッチしない場合、 このディレクトリにあるすべての crontab ファイルが無視される。これは、/etc/crontab や /etc/cron.d 以下を対象とした cron の動作に影響を与えない。それらのファイルは 常に特定のホスト上で実行される。

Rather than editing /var/spool/cron/.cron.hostname directly, use the -n option of crontab(1) to specify the host.

/var/spool/cron/.cron.hostname を直接編集するよりは、crontab(1) の -n オプションを用いてホストに特化した設定を編集するほうがよい。

You should ensure that all hosts in a cluster, and the file server from which they mount the shared crontab directory, have closely synchro- nised clocks, e.g., using ntpd(8), otherwise the results will be very unpredictable.

あなたはクラスタのすべてのホストに対して以下のことを保証すべきである - crontab directory がファイルサーバーをマウントしていること - しっかりと時刻が同期されていること そうでなければ、結果がどうなるかは予測不能である。

Using cluster sharing automatically disables inotify support, because inotify cannot be relied on with network-mounted shared file systems.

クラスタシェアリングは自動で inotify(7) サポートを無効化する。 なぜならば inotify(7) はネットワーク共有されたファイルシステムを中継しないからである。

CAVEATS

All crontab files have to be regular files or symlinks to regular files, they must not be executable or writable for anyone else but the owner. This requirement can be overridden by using the -p option on the crond command line. If inotify support is in use, changes in the symlinked crontabs are not automatically noticed by the cron daemon. The cron daemon must receive a SIGHUP signal to reload the crontabs. This is a limitation of the inotify API.

全ての crontab ファイルは普通のファイルか、そのシンボリックリンクである。 それらは実行可能であったりオーナー以外の誰にでも編集可能であってはいけない。 この要求は crond のコマンドラインを -p オプションで上書きすることができる。 もし inotify サポートを使っている場合、シンボリックリンクされた crontab はデーモンにその変更を自動で通知しない。 これは ionotify API の制限である。

The syslog output will be used instead of mail, when sendmail is not installed.

sendmail が install されていない場合、syslogの出力は代わりに mail コマンドが利用される。

和訳してみてわかったこと

どうやら、/var/spool/cron を複数台にネットワークマウントすることにより、マウントされたサーバーをクラスタとみなしてその中の一台だけがジョブを実行するということができるようだ。

ただし、注釈にあるようにしっかりと時刻が同期されていなければ何が起きるかわからないという大変怖い事が書いてある。 ソースを読み込んで起きうる現象を把握しておかなければ到底プロダクションに投入できるものではない気がする。

私は最近 cron について非常に不安を感じているので、cron の動作をきちんと確認したいと思っている。この記事はその前フリでもある。

*1:@kitora_naoki に和訳の変なところの指摘をもらって修正しました!