かまたま日記3

プログラミングメイン、たまに日常

TOEIC 224回 結果

Listening:365 (315), Reading:330 (370), Total: 695 (685) *1

久しぶり(9ヶ月ぶり)のTOEIC, Listeningが上がったけどReadingが下がったので全体的には微増。700超えられなかった。。

過去ログ

*1:括弧の中は前回(217回)の得点

PostgreSQLでMySQLのshow processlistみたいなのを出す

pg_stat_activity というテーブルに入っているようです。 datname でデータベース単位で絞り込めます。

$ echo '\pset pager off \\ select pid, usename, datname, application_name, client_addr, client_hostname, state, query from pg_stat_activity where datname = '\''some_database'\'';' | psql postgres
Pager usage is off.
  pid  |   usename |    datname    |                       application_name                       | client_addr  | client_hostname | state |                                     query
-------+-----------+---------------+--------------------------------------------------------------+--------------+-----------------+-------+--------------------------------------------------------------------------------
 16082 | some_user | some_database | unicorn worker[0] -E production -p 5000 -c config/unicorn.rb | xx.xx.xxx.xx |                 | idle  | SELECT COUNT(*) FROM "some_table" WHERE "some_table"."type" IN ('SomeType')
 16326 | some_user | some_database | unicorn worker[1] -E production -p 5000 -c config/unicorn.rb | xx.xx.xxx.xx |                 | idle  | SELECT COUNT(*) FROM "some_table"
(2 rows)

NGINXのupstream keepaliveをtcpdumpで確認する

TL;DR

UpstreamサーバとNGINXサーバの負荷軽減のために、 upstream keepaliveを導入したときに、実際Keepaliveしてるかをtcpdumpで確認した時の仕方のメモです

登場人物

  • 10.21.2.25: Upstreamサーバ, sinatraアプリが5000でlistenしている
  • 10.21.1.43: NGINXサーバ

nginx.conf

upstream test_server {
  keepalive 5;
  server 10.21.2.25:5000;
}

server {
  listen 80;
  server_name kamatama41.example.net;

  location / {
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_pass http://test_server;
  }
}

動作確認

$ curl -H 'Host: kamatama41.example.net' http://localhost
Powered by Deis
Release unknown on ip-10-21-2-25

tcpdumpで調べてみる

上記のcurlコマンドを打ちながら別のウインドウで見ます。 最初に開いた 56996 ポートがずっと使われてることがわかります。

$ sudo tcpdump -n | grep '10.21.2.25'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
06:03:13.938970 IP 10.21.1.43.56996 > 10.21.2.25.5000: Flags [S], seq 434416119, win 26883, options [mss 8961,sackOK,TS val 903841576 ecr 0,nop,wscale 7], length 0
06:03:13.939291 IP 10.21.2.25.5000 > 10.21.1.43.56996: Flags [S.], seq 3534912600, ack 434416120, win 26847, options [mss 8961,sackOK,TS val 61090501 ecr 903841576,nop,wscale 7], length 0
06:03:13.939306 IP 10.21.1.43.56996 > 10.21.2.25.5000: Flags [.], ack 1, win 211, options [nop,nop,TS val 903841576 ecr 61090501], length 0
06:03:13.939328 IP 10.21.1.43.56996 > 10.21.2.25.5000: Flags [P.], seq 1:76, ack 1, win 211, options [nop,nop,TS val 903841576 ecr 61090501], length 75
06:03:13.939553 IP 10.21.2.25.5000 > 10.21.1.43.56996: Flags [.], ack 76, win 210, options [nop,nop,TS val 61090501 ecr 903841576], length 0
06:03:13.940954 IP 10.21.2.25.5000 > 10.21.1.43.56996: Flags [P.], seq 1:223, ack 76, win 210, options [nop,nop,TS val 61090501 ecr 903841576], length 222
06:03:13.940958 IP 10.21.1.43.56996 > 10.21.2.25.5000: Flags [.], ack 223, win 219, options [nop,nop,TS val 903841576 ecr 61090501], length 0
06:03:17.044635 IP 10.21.1.43.56996 > 10.21.2.25.5000: Flags [P.], seq 76:151, ack 223, win 219, options [nop,nop,TS val 903842352 ecr 61090501], length 75
06:03:17.046437 IP 10.21.2.25.5000 > 10.21.1.43.56996: Flags [P.], seq 223:445, ack 151, win 210, options [nop,nop,TS val 61091278 ecr 903842352], length 222
06:03:17.046452 IP 10.21.1.43.56996 > 10.21.2.25.5000: Flags [.], ack 445, win 227, options [nop,nop,TS val 903842353 ecr 61091278], length 0
06:03:21.081645 IP 10.21.1.43.56996 > 10.21.2.25.5000: Flags [P.], seq 151:226, ack 445, win 227, options [nop,nop,TS val 903843361 ecr 61091278], length 75
06:03:21.083652 IP 10.21.2.25.5000 > 10.21.1.43.56996: Flags [P.], seq 445:667, ack 226, win 210, options [nop,nop,TS val 61092287 ecr 903843361], length 222
06:03:21.083665 IP 10.21.1.43.56996 > 10.21.2.25.5000: Flags [.], ack 667, win 236, options [nop,nop,TS val 903843362 ecr 61092287], length 0

CoreOSもろもろメモ

色々ログを見たい場合

journalctl使う、詳しい使い方とかはこちらを参考に。 yomon.hatenablog.com

(例)

$ journalctl -u docker --no-pager

docker.service.d をカスタマイズしている状況をみる

/etc/systemd/system/docker.service.d の中に色々ファイルが入っている

coreos.com

$ ls /etc/systemd/system/docker.service.d
10-require-flannel.conf  50-insecure-registry.conf

Fleet関係

Unitファイルを読み込む/起動

$ fleetctl load myunit.service
$ fleetctl start myunit.service

読み込んだUnitのチェック

$ fleetctl list-units | grep myunit.service
myunit.service                      0c2af091.../10.11.2.129 active      running
myunit.service                      36d6af16.../10.11.2.61  active      running
myunit.service                      599307fe.../10.11.2.126 active      running
myunit.service                      c7918571.../10.11.2.22  active      running

Unitを削除する

$ fleetctl destroy myunit.service

Unitログをtailで見る (on サービスがスケジュールされてるホスト)

$ journalctl -fx -u myunit.service

Ubuntu × JRubyでSSLError: certificate verify failed

昨日から急に自社のJenkinsサーバ(Ubuntu)で実行しているEmbulkのタスクが以下のようなエラーを吐いて失敗するようになりました。

 at RUBY.block in call(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/faraday-0.9.2/lib/faraday/adapter/net_http.rb:43)
    at RUBY.with_net_http_connection(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/faraday-0.9.2/lib/faraday/adapter/net_http.rb:87)
    at RUBY.call(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/faraday-0.9.2/lib/faraday/adapter/net_http.rb:32)
    at RUBY.call(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/faraday-0.9.2/lib/faraday/request/url_encoded.rb:15)
    at RUBY.build_response(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/faraday-0.9.2/lib/faraday/rack_builder.rb:139)
    at RUBY.run_request(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/faraday-0.9.2/lib/faraday/connection.rb:377)
    at RUBY.post(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/faraday-0.9.2/lib/faraday/connection.rb:177)
    at RUBY.fetch_access_token(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/signet-0.7.3/lib/signet/oauth_2/client.rb:960)
    at RUBY.fetch_access_token!(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/signet-0.7.3/lib/signet/oauth_2/client.rb:998)
    at RUBY.fetch_access_token!(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/googleauth-0.5.1/lib/googleauth/signet.rb:69)
    at RUBY.apply!(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/googleauth-0.5.1/lib/googleauth/signet.rb:45)
    at RUBY.apply!(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/googleauth-0.5.1/lib/googleauth/service_account.rb:93)
    at RUBY.apply_request_options(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/google-api-client-0.12.0/lib/google/apis/core/http_command.rb:313)
    at RUBY.execute_once(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/google-api-client-0.12.0/lib/google/apis/core/http_command.rb:289)
    at RUBY.block in execute(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/google-api-client-0.12.0/lib/google/apis/core/http_command.rb:104)
    at RUBY.block in retriable(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/retriable-3.0.2/lib/retriable.rb:53)
    at org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:305)
    at RUBY.retriable(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/retriable-3.0.2/lib/retriable.rb:49)
    at RUBY.block in execute(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/google-api-client-0.12.0/lib/google/apis/core/http_command.rb:101)
    at RUBY.block in retriable(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/retriable-3.0.2/lib/retriable.rb:53)
    at org.jruby.RubyFixnum.times(org/jruby/RubyFixnum.java:305)
    at RUBY.retriable(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/retriable-3.0.2/lib/retriable.rb:49)
    at RUBY.execute(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/google-api-client-0.12.0/lib/google/apis/core/http_command.rb:93)
    at RUBY.execute_or_queue_command(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/google-api-client-0.12.0/lib/google/apis/core/base_service.rb:360)
    at RUBY.get_dataset(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/google-api-client-0.12.0/generated/google/apis/bigquery_v2/service.rb:134)
    at RUBY.block in get_dataset(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/embulk-output-bigquery-0.4.5/lib/embulk/output/bigquery/bigquery_client.rb:369)
    at RUBY.with_network_retry(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/embulk-output-bigquery-0.4.5/lib/embulk/output/bigquery/google_client.rb:81)
    at RUBY.get_dataset(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/embulk-output-bigquery-0.4.5/lib/embulk/output/bigquery/bigquery_client.rb:369)
    at RUBY.auto_create(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/embulk-output-bigquery-0.4.5/lib/embulk/output/bigquery.rb:288)
    at RUBY.transaction(/jenkins/workspace/some-jenkins-job/vendor/bundle/jruby/2.3.0/gems/embulk-output-bigquery-0.4.5/lib/embulk/output/bigquery.rb:343)
    at RUBY.transaction(uri:classloader:/embulk/output_plugin.rb:64)
    at RUBY.run(uri:classloader:/embulk/runner.rb:84)
    at RUBY.run(uri:classloader:/embulk/command/embulk_run.rb:307)
    at RUBY.<main>(uri:classloader:/embulk/command/embulk_main.rb:2)
    at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:956)
    at jenkins.home.$_dot_embulk.bin.embulk.embulk.command.embulk_bundle.<main>(file:/jenkins/home/.embulk/bin/embulk!/embulk/command/embulk_bundle.rb:30)

Error: org.jruby.exceptions.RaiseException: (SSLError) certificate verify failed

embulk-output-bigqueryでBigQuery APIにアクセスする際のエラーのようですが、全然心当たりがありません。というのをTwitterでつぶやいたらTreasureData社の方に拾ってもらって同じような現象の方の話を教えてもらいました、神。。!

その後色々調べる感じ、Ebmulkが使ってるJRuby (or Java)のレイヤーで起こる特有のエラーっぽいと言うことが分かりました。

続きを読む

Ubuntuでgitがアップデートされてるか確認する

先日Gitの脆弱性が発表されて、自分たちのサーバでいろいろ対応した時のメモです。バージョンはUbuntu14.04。

バージョン確認

$ dpkg -l git
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                                           Version                              Architecture                         Description
+++-==============================================================-====================================-====================================-=================================================================================================================================
ii  git                                                            1:1.9.1-1ubuntu0.6                   amd64                                fast, scalable, distributed revision control system

自動アップグレードの設定確認

Ubuntuでは unattended-upgrades というパッケージで自動アップグレードができるようになるようです。 設定内容は /etc/apt/apt.conf.d/20auto-upgrades で確認します。

Ubuntu 16.04: 自動アップデート / アップグレードの設定をする - Narrow Escape

$ cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

自動アップグレードの実施確認

自動アップグレードの履歴は /var/log/apt/history.log に出力されてるので、内容を確認します。 こんな感じのログが出てるはず。

Start-Date: 2017-08-11  06:27:58
Upgrade: git-man:amd64 (1.9.1-1ubuntu0.5, 1.9.1-1ubuntu0.6), git:amd64 (1.9.1-1ubuntu0.5, 1.9.1-1ubuntu0.6)
End-Date: 2017-08-11  06:28:29

携帯をP10 liteに変えた

2014年の4月くらいからNexus 5を愛用してたんですが、2016年10月にセキュリティパッチの提供も終了してしまい、さらに以前修理したにもかかわらず、また最近液晶を割ってしまい、そろそろ変えないとと思っていました。

とりあえず、色々考えた結果、HuaweiのP10 liteにした次第です。

普通のP10と迷いましたが、高かったのとliteでもNexus 5より高スペックだったのでまあ良いかなと思い決断しました。

使い始めて1週間位経ちますが、Nexus 5と比べても全然サクサクなので不満はありません。あといちばん良かったのが指紋認証の機能で、いちいちPINを入れる手間が省けたのが一番良かったです。アプリを開くたびに結構長くて複雑なパスワード入れないといけない1Passwordのアプリも対応してて感動でした。最近の機種にはデフォルトで付いてるものなのかもしれませんが、3年ぶりに買い替えた身としてはかなり驚いた次第です。