Arch Linux

プロセスのCPU使用率を制限したくてcgroupを試したのですが、wikiの通りやってみてもうまくいかず結局cpulimitコマンドを使ってしまいました

echo 100 > /sys/fs/cgroup/cpu/groupname/foo/cpu.shares

して無限ループプログラムを動かしてtopで見るとCPU使用率100％になってるんですが、何か間違ってるんでしょうか

一般ユーザで実行するプログラムに制限をかけるときは # cgcreate -a ユーザ名 -g memory,cpu:任意のcgroup名

そして、サブグループ作るときは、一般ユーザで $ cgcreate -g memory,cpu:先ほど作成したcgroup名/サブグループ名

無いとは思いますがサンプルそのままの場合、bashコマンドのみ、この制限がかかるかなと思います

$ cgexec -g memory,cpu:cgroup名/サブグループ名 プログラム名

僕自身はcgroup自体今知りました、cpulimitの方が簡単…

もしかしてcpu.sharesってniceと同じように相対的な優先度を指定するだけで、絶対的なCPU使用率を制限するものではないんでしょうか。cpu.shares = 100にした無限ループプロセスと、制限かけていない無限ループプロセスを同時に動かしたら、使用率10%と90%になりました。

cpulimitはSIGCONTとSIGSTOPで実現しているようなので、オーバーヘッド的にはcgroupの方が小さいんでしょうけどね

cgcreateとか入れなくてもechoだけで設定はできるみたい。この辺は面白いかも
http://www.usupi.org/sysad/228.html

絶対的な上限はcfs_quota_usとcfs_period_usですかね。でもtopで見てると13%と26%が交互に切り替わって安定しないｗ
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-cpu.html

あ、top -d 1で見ると20%で安定する！

なるほど

サーバーのアップグレート中なのでしばらく接続できません、ご迷惑おかけします

了解です
statuscakeの通知が来ない

メンテナンスは恙無く終了しました。何か問題があればお知らせください

@mitsu-ksgr has joined the channel

@terut has joined the channel

@xorphitus has joined the channel

AWS の EC2 で arch 使ってる人います？

pacman -Syu したら、 error: linux-ec2-lts: signature from "Steven Noonan <steven@uplinklabs.net>" is invalid って言われて

あ、それ答えわかりますが出先なのでちょっと待ってください

！

5分ほどで答えます

ネ申だ

@raa0121 下記を実行してみてください。

sudo pacman-key --refresh-keys

ありがとうございます！

だめでした…

gpg: assuming bad signature from key 7EACB44BA7B30DB9 due to an unknown critical bit
って言われますね…

んー

おーまいがー

ここに載ってた、 pacman-key -r A7B30DB9 も試しましたが、だめでした

ちょっと出先なので、かえっても解決してへんかったら一緒に調べますー

ありがとうございます

先ほどのエラーはりふれっしゅきーして起きたんですか？

ですね

関係なさそうだけど念のため。sudo pacman -Syyしました？

しました

なるほどーわたしのハマりどころ経験は万策尽きてるので帰ってから調べます

archlinux-keyring-20170104-1 が update にあったのでそれも先に入れました

ふむふむ

ec2 での archlinux はやめようかなぁ…

諦めたほうが早い気がしてきた

正直サーバーにArch Linuxは変態では

自宅鯖Archなので…

あれいーしーつーと言ってた気が

あ、移行先を作ってるのです

あ、なるほど

セントスでいい気もするけど、移行は確かに大変そうですね

CentOSはちょっと…

趣味では使いたくないっす

まぁそれはわかる

質問終わりましたし、らんだむ移動しますか

はい

手元のDocker ArchLinuxで以下のコマンドを実行したところ，鍵をインポートできたみたいですが，EC2に依存する問題なんでしょうか？

# pacman-key --keyserver pgp.mit.edu -r A7B30DB9

一時的な間に合わせですがSigLevel=Neverを設定してみてはどうでしょう

おっと、もうインスタンスを殺してしまいました…

oh...

たまに遭遇しますよね。pacman-key関連のエラー
--refreshしても何故か解消されなかったこともあるのですが、なんか色々やってたらいつの間にか直ったことがありました。initとか色々。

shutterが起動しなくなったのですが私だけでしょうか？
パッケージキャッシュを消して入れなおしてもアイコンが破損していると言われて起動出来なくなりました。

それが起こったのはarchアップデート時ですか、shutterアップデート時ですか？

shutterは11/14にアップデートされてそう

archアップデートの時ですね、起動出来なくなったのはここ数日の間なので

たしかにアイコンをsvgビューアで開こうとしても破損していると言われますね…

なるほど
依存パッケージのアップデートが原因かもしれませんね

もしくは本当にアイコンが壊れるというのが何かの時に起こって(アップデート、インストール時など)から、そのままという可能性

それはないですね、パッケージをミラーからダウンロードして展開しましたがやっぱり開けません

@atnanasi uploaded a file: gpicviewでずっこけた

ただウェブのsvgをpngに変換するツールだと表示出来るのでライブラリが原因？

私ならまずは、ログから数日中にアップデートしたパッケージをリストアップして、shutterの依存パッケージと照合した上で、該当するものをダウングレードしてみる気がします。

そうかもですね > ライブラリ

皆さんディスク暗号化は何使ってますか？

ディスクは暗号化するのが良さそうだけど、私はあまりしたことがないですね
https://wiki.archlinuxjp.org/index.php/ディスク暗号化

あれって外部ディスクにコピー、バックアップする際とか、git pushする際とかにも復号化が必要だったりするんですかね? (あまり詳しくない

とりあえずLUKS+Nautilusでは復号してマウントする形なので、一回キーを入れればファイル操作に関しては自由自在です

なるほどディスクマウント時に復号化の処理を入れとくと便利使えそうな感じなんですね

@tmknakagawa has joined the channel

X.Orgに関して次のパッケージはAUR移動になったらしいです
>xf86-input-joystick, xf86-input-acecad, xf86-video-apm, xf86-video-ark, xf86-video-chips, xf86-video-glint, xf86-video-i128, xf86-video-i740, xf86-video-mach64, xf86-video-neomagic, xf86-video-nv, xf86-video-r128, xf86-video-rendition, xf86-video-s3, xf86-video-s3virge, xf86-video-savage, xf86-video-siliconmotion, xf86-video-sis, xf86-video-tdfx, xf86-video-trident, xf86-video-tseng
詳細はこちらを
https://www.archlinuxjp.org/news/xorg-server-1191-is-now-in-extra/

原文
https://www.archlinux.org/news/xorg-server-1191-is-now-in-extra/

@kusakata さん、
朝早いですが和文PR送っておきました
今回は翻訳量少なめです

そういえば、これ昨日アップデートした時ありましたね。今回aur移動されたやつを削除しなければアップデートできませんみたいな表示が出て、面倒だったので pacman -Syu xorg-server みたいな実行をするとアップデートできた感じでした。

@kusakata pinned a message to this channel.

おはようございます。

@fragment いつもありがとうございます。マージしました。

dockerイメージはarchアップデートし続けると肥大化することがわかりました。
よって、一旦最初のイメージにリセットした後、archアップデートしていく方式に変更しました。
一応これでも最新イメージが保たれますが、この方式への変更によって初期イメージが古くなっていくにつれアップデートできなくなる確率が高まることが予想されます(archは古くなったイメージでアップデートがこけやすくなるため)。
一応、監視してこけた場合に都度対応する予定です。

私以外がやる場合は、単にリポジトリを変更(tag:日付)などにした後、pushしてもらえれば、travisが回りイメージがアップデートされると思います。
またはdocker-arch-testのdockerfileを参考にしてpushしてもらうかです。

Audaciousが動かないと思ったら破壊的変更が来てたみたいで https://www.reddit.com/r/archlinux/comments/5mphpu/psa_harfbuzz_update_infinality_breaking_system/

Infinalityは開発が止まっていて今は公式のfreetypeを使うことが推奨されているみたいですね https://gist.github.com/cryzed/e002e7057435f02cc7894b9e748c5671

お久しぶりです．Dockerイメージが重くなる件ですが，多分pacmanのキャッシュじゃないですか？
よく，別のディストリとかでやる手法なんですがpacman -Syuのあとにpacman -Scc実行してみたらいかがでしょうか

手元でpacman -Sccしないやつとするやつでは下記のような感じになりました．

REPOSITORY                      TAG                 IMAGE ID            CREATED             SIZE
arch-sc                         latest              882582d513f2        6 seconds ago       543.9 MB
arch                            latest              91d878c4c748        16 minutes ago      575.4 MB

あとPRでDockerのimageをpushするのは怖い（もし，悪意のあるユーザが危険なプログラムを噛ませたDockerfileを作成してPR投げるかも……）ので，これも修正したほうが良いかもです……

ということで，PR作成しましたのでご確認お願いします

あ，failした……，pacdiffってvimないとダメなんですね……，削除したのcommitしなおします……

@nomuken: お久しぶりです。 PRありがとうございます。
#repository で色々と確認できるのでもしよろしければ、のぞいてみてください。
やっぱりpacman -Sccは入れておいたほう良いかもですね。
ちょっと取り込んで様子を見てみますね。

@nomuken: PRでCIを動かす件、変更しました。ご指摘ありがとうございます。

git pushされた時に変更

@nomuken: このシステムって通常、毎回pacman -Syuしてそれをdocker pushする仕組みなんですが、dockerの仕組み上、そうして出来上がったlatest imageを使い続けるとどうしても肥大化してしまうみたいなんですよね。

今回、tag:startからtag:latestを生成したので、一旦サイズがリセットされて減っていますが、多分、tag:latestからlatestを生成する方式だとやはりサイズは増えていってしまう気がします。
でも、今回の件で一旦サイズをリセットできましたし、しばらくもう一度様子を見てみますね。

mergeありがとうございました！dockerのコンテナのサイズが累積的に大きくなっちゃうのはもう正直どうしようも無いです．最も良いのはある一定期間でtag:startを生成し直すほうが良いと思います．

例えばDockerの中で軽量であることを謳い文句にしているalpine linuxのDockerfileはこんな感じです．
https://github.com/gliderlabs/docker-alpine/blob/6a7732123b1e22c836e7ff538828ecf9eb0ebbb3/versions/library-3.1/Dockerfile

travisは使い慣れていないので微妙ですが，例えばjenkinsみたいなcrontabっぽいビルドが使えるなら一定期間に自動生成して走らせるように作ると良いかもというふうに考えます．

もし，これの自動化とか出来たらDockerのlibraryに入ると最高の最高になって嬉しいですね :slightly_smiling_face:

ですね。tag:startを定期的に生成する仕組みを作ってもこの問題は解決できます。
できればこれは透明性を担保するためにも公開された形で手順を自動化したいなーという感じで思っていて、しかし具体的な方法についてはまだ考案中です。

arch公式のimage制作方法は、アップデートを重ねていく方法ではなくて、一定時間ごとにまっさらなArch環境を作り直してそれをimageとして公開しているようなんですよね。

この方法だと、常に最小限のサイズで新しいImageを提供することができます。

そうですね。作った時点のものは最新なので。
なので、最終的にはImage 製作方法を自動化したい感じですね。

Docker(Arch) in Dockerができれば、できそうですね！

ですね。そこでdockerのarch image作成スクリプトが動けばたぶん行けます！

多分このスクリプトがよしなにやってくれるはず....
https://gist.github.com/aruneko/2227a46c6c27da4b2f94ba95f6d07b15

前にちょっと試してみたときは動かなかった気が

DOCKER_IMAGE_NAMEのあたりとか未設定なので...

ふむ、たぶん設定あたりはできてたはず(最初のイメージ作成したときに使ってるので)

とりあえず、お家帰ってから確認してみますねー

ローカルでの自動化はできるんですけど、docker hubやtravisなどのサービス上で回したいというか、その上でimage生成を実行したい感じです。

現在、アップデートをサービス上で回してますが、それをimage生成に切り替えるみたいな。

Docker in dockerが動けば、travis上のdockerコマンドを使ってなんとか行けるかもしれないという期待が

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%8B

なるほど、試してみるか値ありそうですね

ありがとうございます

いけました。 --privileged つければよかったらしい...。

いや、だめか。結構止まる

このあたり結構、既視感が...。そういえば、 docker-archlinux-min を作った時にも割りと止まりまくったりしたので(dockerが提供するスクリプト)、スクリプト書き直してたりしてましたね

いけたっぽい

おぉっ

2回スクリプトを実行しないと、今のところ上手くいかないみたいです。

@aruneko99 travisで /var/run/docker.sock が難しそうな感じでビルドが失敗しますね。

@aruneko99 現在、一応、こちらのリポジトリで試しています。ローカルでは通るのですが、travisで失敗する感じです。
https://github.com/ArchLinuxJP/docker-archlinux-test

うーむ

このあたり参考になりそうなのかなあ。

コンテナ内でのarch-chrootに失敗してる感じですよね

@aruneko99 さんのほうでtravisのlog確認できますか?

今見てますー

mount: mount point /var/tmp/rootfs-archlinux-l5cbWfMM61/dev/shm is a symbolic link to nowhere

直接の原因はこれっぽい

ですね。

ちょっと落ちます。
ローカルではこんな感じでいけました。
sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --privileged -it $DOCKER_REPO_TMP /bin/zsh -c "repeat 2 /mkimage-arch-jp.sh"

スクリプトを2回実行してるけど、こちらはスクリプトのほうの修正が必要かもです(本来的には)

インストールが1回失敗する現象ですが、procps-ngのインストール中に以下のようなエラーを吐いて止まっていることが確認されました。

> procps-ng-3.3.12-1-x86_64 299.5 KiB 598K/s 00:01 [#############################] 100%
> mount: proc is already mounted or /var/tmp/rootfs-archlinux-RuhkhYgBEm/proc busy------] 17%
> proc is already mounted on /proc
> proc is already mounted on /var/tmp/rootfs-archlinux-RuhkhYgBEm/proc
> ==> ERROR: failed to setup chroot /var/tmp/rootfs-archlinux-RuhkhYgBEm

Travis上ではなぜかこの現象は起こらない模様...

と、いうわけでビルドが通るようになりました。

Dockerfileなどのブラッシュアップは追々ということで。

おお、ありがとうございます。
他のもこちらの方式に移行していきたいですね。

助かります(かなり)

結構謎の失敗をすることがある

fromにtestイメージを使うと失敗するらしい?

直接がダメなのかもしれない

いけた
これでプロセスの透明性が上がり、サイズまで小さくなったので @aruneko99 さんには感謝しかない

一応、こちらのリポジトリをdocker in dockerでのimage作成方式に移行してみました。他のも順次、移行して行きたさ
https://github.com/ArchLinuxJP/docker-archlinux

ちょっとだけ現在わかっていることについて
どうやらdocker in dockerで作成したイメージをfromに指定すると、travisでのイメージ作成スクリプト実行中にエラーが出てしまう模様

なので、現在のところtag:startなどをfromに指定しています

エラーの原因ですが、単に存在するディレクトリに対してmkdirしていたことが原因だったので、とりあえずtestリポジトリの方で直しておきました。

それに伴ってこの手順で作成したイメージを使って再度イメージを作り直す手順に書き換えてあります。

しかし、再びprocがマウントできない問題が発生したので、2回実行する方式に戻してあります...

1回目のpacstrap中になぜかprocがマウントできない問題が解決できれば、1回だけで済むはずなのですが...

testではない方のリポジトリはsyuiさんにtestリポジトリを確認していただいてからにしようとおもいます。

なるほど
ありがとうございます

@aruneko99 ちょっと面白い結果が得られました。travisのbranchesを見てほしいのですが、内容(コード)は同じですが、branch:testではbuildに成功しており、branch:masterでは失敗しています(原因はprocがマウントできない問題、多分)

docker-archlinuxリポジトリの方でしたら、testは2回やって成功していて、masterは1回しかビルドしなくて失敗しているだけに見えますね...

@aruneko99 あー、すいません。#78(master)は1回目に失敗したので、2回目回したら成功しましたので、最終的なステータスが「成功」になってしまってる...。

なるほどなるほど

@aruneko99 PRを送ってみました。testの方にももしかしたら利用できるかもしれません。PRの方、問題なさそうならMergeのほうお願いしてよろしいでしょうか?
https://github.com/ArchLinuxJP/docker-archlinux/pull/5

ありがとうございます。確認しましたのでマージしてみます。

お願いします

今ビルドログを追っていましたが、やはりprocがマウントできずに落ちてしまいました...

ですね。なぞ

travisを回して見ないとわからないのも辛い

もしかしたらPR形式がダメなのかもしれないです。commit logでPRした時、一度失敗してるのですが、2回目回したらいけたということがありました(slackに書いたやつはそれ)

ふむふむ

その時もbranch:testは成功してるんですよね。

ということでもう一回、travisでrestart buildしてみますね

ダメですね。

なぜtestブランチではうまく行くのか...

わかりません...

@aruneko99 L362の /var/tmp/rootfs-archlinux-oSi1tmaBkE になりそう -> rootfs

えっっと

あ、間違えた

どうやら EXPECT_TIMEOUT も一つの要因ぽいですね。 -> mkarch-image.sh

EXPECT_TIMEOUT=2とかにしてみると、同じエラーが

ややこしいのがローカルでテストする際、すでに当該スクリプトをADDしているので再度、docker buildする必要がありそう

原因はもしかして単にタイムアウト時間が短かっただけ...?

Travisはドイツのサービスのため、mkimageファイル内で日本のミラーサーバーを用いているせいでダウンロードに時間がかかり、タイムアウト時間を越えていたという仮説。

ですね。

ちょっと確かめてみないと...。確か、標準イメージにはsudoはインストールされてなかった気がするけど、yaourtイメージでインストールされてた記憶

ArchのDocker Imageを生成する仕組みを簡単にではありますが作ってみました。 Dockefile はこんな感じで書けばOKです。

FROM archlinuxjp/docker-arch
RUN docker-arch base

$ sudo docker build -t test .
$ sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --privileged -it test /bin/bash /mkimage-arch-jp.sh
$ sudo docker images

RUN docker-arch はオプション{yaourt, min, etc...}に応じて使用されるスクリプトが異なります。使用されるスクリプトはこちらのリポジトリにまとめられています。何かありましたらIssuesやPull Reqのほう、よろしくお願いします。

https://github.com/ArchLinuxJP/docker-mkimage-arch/tree/master/mkimage-arch

新しいスクリプトの追加やオプションの追加も歓迎です

@clomsync has joined the channel

@sakakendo has joined the channel

Slackアプリからスレッド機能を使えるようになったみたいです。
https://slackhq.com/threaded-messaging-comes-to-slack-417ffba054bd

ブラウザからだと動作しない感じなのかな。

チームによってあったりなかったりです。初期からあるチームほどあるので順次対応なんじゃないでしょうか

なるほど

再起動で解決することもあるようです

Slackの

そういえば、mongodb って、依存がバージョン指定されてなくて、辛いんですが、こういうのどうすればいいんですかね？
https://www.archlinuxjp.org/packages/community/x86_64/mongodb/

間違ってるかもしれませんが、pkgbuildで depends=('foobar>=1.8.0') という感じで指定することができるかもしれないと思いました(そういう話じゃない可能性も...

そういう話なんですが

それをやらない？ って話をするのに

どうすればいいんですかね

メンテナに連絡を取るのがいいのかな？

ML なのかな

メンテナとコラボレータ は確認できた

なるほど
たぶんそう(メンテナ連絡)するのが確実だと思いますが、私はやったことがないのでわかりませんね、すいません

バグレポがあった

アカウントあったw

Mail送ったことありますが、返事来なかった

便利

カテゴリに Packeges: Extra/Core/Testing があるのに、Community がない…

なるほど、Community は分離されてたのか

んー でも Arch ってHead を追いかける主義なら、バージョン指定はいらないのかな…

動かなかったり不都合がでた場合、バージョン指定あると良さそう

古いバージョンを動かしたいときに

depends に指定があると楽なんですよね

なるほど

将来的に影響してきそうなことなので、言ってみたほうがいいかもしれませんね。

awesome のバージョンがあがって、これまでの設定ファイルでは一部動かない機能があって、ローカルの設定ファイルをつくりなおすことになった。title表示がデフォルトになるとかいらない設定が一部変更されてた。しかし、金曜日に帰る前に pacman -Syu すると、月曜日にめんくらうから次からやめとこう。

大変そう

Pacmaticとか使って警告させないと設定ファイルとかの変更気が付かない…

便利

pacmatic 使ってなかった。これから使うようにしよう。

pacmaticを使ってみたら、放置してたpacnewが山程でてきてちょっとビビった。

それ、archのせいじゃないし。debianだって、/etcの下を書き換えてるし。

ディストリ関係ないですよね…リリースログとかを見てないのが原因と思います

@keion has joined the channel

かなり大きいニュースが早朝から飛び込んできましたね。先行して流します。

i686のサポート を段階的に 廃止 するようで、以下が予定になります。
2月のISOがi686を対象としたインストールが可能な最後のISOになるようです。
11月まではi686対象のパッケージの更新が行われ、それ以降は公式にはメンテナンスされないようです。
(コミュニティによるサポートの可能性あり)
[multilib]リポジトリは影響を受けないそうです。

(和文)
https://www.archlinuxjp.org/news/phasing-out-i686-support/
(原文)
https://www.archlinux.org/news/phasing-out-i686-support/

@kusakata さん、再び早朝に送りつけてしまい申し訳ないですがPR送っておきます。
文量多めですがよろしくお願いします

(3月からISOのサイズ小さくなるのかな)

@kusakata pinned a message to this channel.

@fragment いつもありがとうございます。マージしました。

@tty170 has joined the channel

@brackss1 has joined the channel

よろしくお願いします

@brackss1 よろしくです。

@yuttoku has joined the channel

slackの2段階認証、通らない人いますか?

ブラウザで試してみた方

そもそも2段階認証が実装されたことを知らんかったな…

2FAを今設定するのはやめておいた方が良いかもですね
試してみたところ、なんか違うチームとかアカウントとかでも通らない感じがします
これは私だけの問題なのだろうか...

通った方もコメントもらえると助かります

すいません、通りました。お騒がせしました。

@fragment PRしておきました。
https://github.com/ArchLinuxJP/archcard-jp/pull/7

docker関連のリポジトリが複数あったのを1つのリポジトリに集約しました。
https://github.com/ArchLinuxJP/docker-arch

@syui さん、ありがとうございます。
mergeします。

また動かなくなるようなことがあれば、直接、raw(github)で読み込んだ方がいいかもしれませんね

直接読み込むと動かないぽいです ↑

どうやらgh-pagesではnode_modules以下をwebサーバーに置かなくなった変更ぽいものがあったのかもしれません

@fragment 何回も呼び出してしまってすいません。
https://github.com/ArchLinuxJP/archcard-jp/pull/8

@syui さん、再び離席してました…
そこが原因だったんですね。勉強になります。
PRありがとうございました。Mergeしました

@fragment いえ、ありがとうございます。

@masayukig has joined the channel