僕自身はcgroup自体今知りました、cpulimitの方が簡単...aosho22時44分もしかしてcpu.sharesってniceと同じように相対的な優先度を指定するだけで、絶対的なCPU使用率を制限するものではないんでしょうか。100にした無限ループプロセスと、制限かけていない無限ループプロセスを同時に動かしたら、使用率10%と90%になりました。aosho22時46分cpulimitはSIGCONTとSIGSTOPで実現しているようなので、オーバーヘッド的にはcgroupの方が小さいんでしょうけどねaosho22時47分cgcreateとか入れなくてもechoだけで設定はできるみたい。絶対的な上限はcfs_quota_usとcfs_period_usですかね。了解ですstatuscakeの通知が来ないkusakata18時53分メンテナンスは恙無く終了しました。下記を実行してみてください。関係なさそうだけど念のため。一時的な間に合わせですがSigLevel=Neverを設定してみてはどうでしょうraa012119時36分おっと、もうインスタンスを殺してしまいました...kusakata20時4分oh...syui21時54分たまに遭遇しますよね。pacman-key関連のエラー--refreshしても何故か解消されなかったこともあるのですが、なんか色々やってたらいつの間にか直ったことがありました。atnanasi22時0分shutterが起動しなくなったのですが私だけでしょうか?パッケージキャッシュを消して入れなおしてもアイコンが破損していると言われて起動出来なくなりました。私ならまずは、ログから数日中にアップデートしたパッケージをリストアップして、shutterの依存パッケージと照合した上で、該当するものをダウングレードしてみる気がします。朝早いですが和文PR送っておきました今回は翻訳量少なめですsyui6時48分そういえば、これ昨日アップデートした時ありましたね。みたいな実行をするとアップデートできた感じでした。channel.kusakata9時15分おはようございます。いつもありがとうございます。syui12時29分dockerイメージはarchアップデートし続けると肥大化することがわかりました。よって、一旦最初のイメージにリセットした後、archアップデートしていく方式に変更しました。一応これでも最新イメージが保たれますが、この方式への変更によって初期イメージが古くなっていくにつれアップデートできなくなる確率が高まることが予想されます(archは古くなったイメージでアップデートがこけやすくなるため)。一応、監視してこけた場合に都度対応する予定です。私以外がやる場合は、単にリポジトリを変更(tag:日付)などにした後、pushしてもらえれば、travisが回りイメージがアップデートされると思います。docker-arch-testのdockerfileを参考にしてpushしてもらうかです。PRありがとうございます。確認できるのでもしよろしければ、のぞいてみてください。-Sccは入れておいたほう良いかもですね。取り込んで様子を見てみますね。PRでCIを動かす件、変更しました。ご指摘ありがとうございます。imageを使い続けるとどうしても肥大化してしまうみたいなんですよね。今回、tag:startからtag:latestを生成したので、一旦サイズがリセットされて減っていますが、多分、tag:latestからlatestを生成する方式だとやはりサイズは増えていってしまう気がします。今回の件で一旦サイズをリセットできましたし、しばらくもう一度様子を見てみますね。:slightly_smiling_face:syui16時46分ですね。tag:startを定期的に生成する仕組みを作ってもこの問題は解決できます。できればこれは透明性を担保するためにも公開された形で手順を自動化したいなーという感じで思っていて、しかし具体的な方法についてはまだ考案中です。aruneko9916時49分arch公式のimage制作方法は、アップデートを重ねていく方法ではなくて、一定時間ごとにまっさらなArch環境を作り直してそれをimageとして公開しているようなんですよね。aruneko9916時50分この方法だと、常に最小限のサイズで新しいImageを提供することができます。syui16時56分そうですね。作った時点のものは最新なので。製作方法を自動化したい感じですね。Dockerができれば、できそうですね!syui16時58分ですね。hubやtravisなどのサービス上で回したいというか、その上でimage生成を実行したい感じです。現在、アップデートをサービス上で回してますが、それをimage生成に切り替えるみたいな。dockerが動けば、travis上のdockerコマンドを使ってなんとか行けるかもしれないという期待がaruneko9917時29分Travis上で「/var/run/docker.sock」がコンテナ側にマウントできればいけるかもです。http://qiita.com/sugiyasu-qr/items/85a1bedb6458d4573407#%E6%96%B9%E6%B3%95-%E3%83%9B%E3%82%B9%E3%83%88%E3%83%9E%E3%82%B7%E3%83%B3%E4%B8%8A%E3%81%AE-docker-daemon-%E3%82%92%E5%85%B1%E6%9C%89%E3%81%99%E3%82%8Bsyui17時31分なるほど、試してみるか値ありそうですねsyui17時31分ありがとうございますsyui18時10分いけました。つければよかったらしい...。syui18時12分いや、だめか。止まるsyui18時16分https://github.com/jprjr/docker-archlinux/issues/1syui18時19分このあたり結構、既視感が...。作った時にも割りと止まりまくったりしたので(dockerが提供するスクリプト)、スクリプト書き直してたりしてましたねsyui18時23分いけたっぽいaruneko9918時37分おぉっsyui18時48分2回スクリプトを実行しないと、今のところ上手くいかないみたいです。難しそうな感じでビルドが失敗しますね。現在、一応、こちらのリポジトリで試しています。ローカルでは通るのですが、travisで失敗する感じです。/var/tmp...aruneko9919時50分うーむsyui19時54分このあたり参考になりそうなのかなあ。直接の原因はこれっぽいsyui19時59分ですね。syui20時1分ちょっと落ちます。ローカルではこんな感じでいけました。/mkimage-arch-jp.sh"syui20時4分スクリプトを2回実行してるけど、こちらはスクリプトのほうの修正が必要かもです(本来的には)1月17日aruneko990時13分インストールが1回失敗する現象ですが、procps-ngのインストール中に以下のようなエラーを吐いて止まっていることが確認されました。/var/tmp/rootfs-archlinux-RuhkhYgBEmaruneko990時35分Travis上ではなぜかこの現象は起こらない模様...aruneko991時1分と、いうわけでビルドが通るようになりました。aruneko991時4分Dockerfileなどのブラッシュアップは追々ということで。syui4時36分おお、ありがとうございます。他のもこちらの方式に移行していきたいですね。dockerでのimage作成方式に移行してみました。dockerで作成したイメージをfromに指定すると、travisでのイメージ作成スクリプト実行中にエラーが出てしまう模様syui6時47分なので、現在のところtag:startなどをfromに指定していますaruneko997時58分エラーの原因ですが、単に存在するディレクトリに対してmkdirしていたことが原因だったので、とりあえずtestリポジトリの方で直しておきました。aruneko997時58分それに伴ってこの手順で作成したイメージを使って再度イメージを作り直す手順に書き換えてあります。aruneko997時59分しかし、再びprocがマウントできない問題が発生したので、2回実行する方式に戻してあります...aruneko997時59分1回目のpacstrap中になぜかprocがマウントできない問題が解決できれば、1回だけで済むはずなのですが...aruneko998時0分testではない方のリポジトリはsyuiさんにtestリポジトリを確認していただいてからにしようとおもいます。面白い結果が得られました。#78(master)は1回目に失敗したので、2回目回したら成功しましたので、最終的なステータスが「成功」になってしまってる...。PRを送ってみました。testの方にももしかしたら利用できるかもしれません。PRの方、問題なさそうならMergeのほうお願いしてよろしいでしょうか?https://github.com/ArchLinuxJP/docker-archlinux/pull/5aruneko9918時37分ありがとうございます。確認しましたのでマージしてみます。今ビルドログを追っていましたが、やはりprocがマウントできずに落ちてしまいました...syui18時42分ですね。syui18時43分travisを回して見ないとわからないのも辛いsyui18時47分もしかしたらPR形式がダメなのかもしれないです。logでPRした時、一度失敗してるのですが、2回目回したらいけたということがありました(slackに書いたやつはそれ)aruneko9918時48分ふむふむsyui18時49分その時もbranch:testは成功してるんですよね。buildしてみますねsyui18時55分ダメですね。一つの要因ぽいですね。原因はもしかして単にタイムアウト時間が短かっただけ...?aruneko9922時47分Travisはドイツのサービスのため、mkimageファイル内で日本のミラーサーバーを用いているせいでダウンロードに時間がかかり、タイムアウト時間を越えていたという仮説。1月18日syui4時35分ですね。syui4時57分http://twitter.com/Eisen_Fluegel/status/821438769031041024syui4時59分ちょっと確かめてみないと...。Imageを生成する仕組みを簡単にではありますが作ってみました。こんな感じで書けばOKです。etc...}に応じて使用されるスクリプトが異なります。使用されるスクリプトはこちらのリポジトリにまとめられています。Reqのほう、よろしくお願いします。channel1月20日syui10時59分Slackアプリからスレッド機能を使えるようになったみたいです。https://slackhq.com/threaded-messaging-comes-to-slack-417ffba054bdsyui11時1分ブラウザからだと動作しない感じなのかな。tacha13時43分チームによってあったりなかったりです。将来的に影響してきそうなことなので、言ってみたほうがいいかもしれませんね。バージョンがあがって、これまでの設定ファイルでは一部動かない機能があって、ローカルの設定ファイルをつくりなおすことになった。title表示がデフォルトになるとかいらない設定が一部変更されてた。すると、月曜日にめんくらうから次からやめとこう。これから使うようにしよう。kusanaginoturugi22時59分pacmaticを使ってみたら、放置してたpacnewが山程でてきてちょっとビビった。kusanaginoturugi23時26分それ、archのせいじゃないし。debianだって、/etcの下を書き換えてるし。channel1月26日fragment4時16分かなり大きいニュースが早朝から飛び込んできましたね。するようで、以下が予定になります。2月のISOがi686を対象としたインストールが可能な最後のISOになるようです。11月まではi686対象のパッケージの更新が行われ、それ以降は公式にはメンテナンスされないようです。(コミュニティによるサポートの可能性あり)[multilib]リポジトリは影響を受けないそうです。さん、再び早朝に送りつけてしまい申し訳ないですがPR送っておきます。いつもありがとうございます。