MySQL 5.7のmysqld --initializeと鶏卵問題
MySQLのデータディレクトリの初期化にはこれまで mysql_install_db が使われてきましたが、MySQL 5.7からは mysqld --initialize を使うことが推奨されています。
mysqld --initialize は datadir 配下にファイルやサブディレクトリがあるとエラー終了します。
# mysqld --initialize --user=mysql 2016-10-04T11:39:01.313174Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting. 2016-10-04T11:39:01.313222Z 0 [ERROR] Aborting
なので datadir をスッカラカンにして再度実行してみます。my.cnf はこんな内容で、datadir の下に tmpdir、InnoDBのデータとログのディレクトリがある構成です。
datadir = /data/mysql tmpdir = /data/mysql/tmp innodb_data_home_dir = ibdata innodb_log_group_home_dir = iblog
# rm -fr /data/mysql/* # mysqld --initialize --user=mysql # echo $? 1 # cat /data/mysql/mysqld.err mysqld: Can't create/write to file '/data/mysql/tmp/ibSY07SU' (Errcode: 2 - No such file or directory) 2016-10-04T11:41:18.876953Z 0 [ERROR] InnoDB: Unable to create temporary file; errno: 2 2016-10-04T11:41:18.876965Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error 2016-10-04T11:41:18.876971Z 0 [ERROR] Plugin 'InnoDB' init function returned error. 2016-10-04T11:41:18.876975Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2016-10-04T11:41:18.876980Z 0 [ERROR] Failed to initialize plugins. 2016-10-04T11:41:18.876983Z 0 [ERROR] Aborting
/data/mysql/tmp が存在しないので /data/mysql/tmp/ibSY07SU が作れずエラー終了しています。
InnoDBのデータ、ログディレクトリについても同様で、自動ではサブディレクトリを作ってくれません。
[ERROR] InnoDB: Operating system error number 2 in a file operation. [ERROR] InnoDB: The error means the system cannot find the path specified. [ERROR] InnoDB: If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them. [ERROR] InnoDB: File ibdata/ibdata1: 'create' returned OS error 71. Cannot continue operation [ERROR] InnoDB: Cannot continue operation.
[ERROR] InnoDB: Operating system error number 2 in a file operation. [ERROR] InnoDB: The error means the system cannot find the path specified. [ERROR] InnoDB: If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them. [ERROR] InnoDB: File iblog/ib_logfile101: 'create' returned OS error 71. [ERROR] InnoDB: Cannot create iblog/ib_logfile101 [ERROR] InnoDB: InnoDB Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again. [ERROR] Plugin 'InnoDB' init function returned error. [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. [ERROR] Failed to initialize plugins. [ERROR] Aborting
というわけで、初期化にはサブディレクトリが必要なわけですが、サブディレクトリがあると mysqld --initialize はエラー終了します。
_人人人人人人人人人人人人人人人人人人_
> どうすりゃいいねん!!!!!!! <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄
途方に暮れそうになりましたが、ドキュメントにちゃんと書いてありました。
As of MySQL 5.7.11, an existing data directory is permitted to be nonempty if every entry either has a name that begins with a period (.) or is named using an --ignore-db-dir option.
https://dev.mysql.com/doc/refman/5.7/en/data-directory-initialization-mysqld.html
というわけで、予め必要なサブディレクトリを作っておいて、必要なだけ --ignore-db-dir で繰り返しそれを指定すればOKです。
# rm -fr /data/mysql/* # install -d -o mysql -g mysql -m 750 /data/mysql/{tmp,ibdata,iblog} # mysqld --initialize --user=mysql --ignore-db-dir=tmp --ignore-db-dir=ibdata --ignore-db-dir=iblog # echo $? 0
追記 2023-03-06
--ignore-db-dir は 5.7 で deprecated だったのですが、8.0 で廃止されて使えなくなりました。
8.0 ではどうすればいいのでしょうか。。。
LXD 2.0でlive migrationしてみる
- Ubuntu 16.04
- LXD 2.0.0
基本的には
に書いてある通りなんで、これの補足という形になります。
まず、live migrationを行う(ホストh1にあるコンテナc1をホストh2にlive migrationする場合)のにこのようなコマンドを実行すると
hirose31@h1$ lxc move c1 h2:
「error: Error transferring container data: websocket: bad handshake」というエラーで失敗し、以下のようにlocalの場合でもremote名を添えて実行すれば成功しました。
hirose31@h1$ lxc move h1:c1 h2:
従って、予め自ホストの分もremoteの登録が必要でした。
hirose31@h1$ lxc remote add h1 192.168.33.21 hirose31@h1$ lxc remote add h2 192.168.33.22 hirose31@h2$ lxc remote add h1 192.168.33.21 hirose31@h2$ lxc remote add h2 192.168.33.22
次にハマったのは、lxc moveするとこのようなエラーで失敗した点です。
hirose31@h1$ lxc move h1:c1 h2: error: Error transferring container data: checkpoint failed: (00.093894) Error (sockets.c:129): Diag module missing (-2) (00.173958) Error (sockets.c:339): Sockets (family 16, proto 0) are not collected (00.173977) Error (cr-dump.c:1303): Dump files (pid: 8476) failed with -1 (00.178203) Error (cr-dump.c:1600): Dumping FAILED.
エラーメッセージを見て、てっきりエラーの原因を表示するためのGo(LXDのlxcコマンドはGoで書かれています)のソケット関連のdiagnostic(診断)ライブラリが足りてないのかな?と思い、いろいろ調べたのですが、結局原因はGoは関係なく、netlink_diag.koというkernel moduleがなかったためでした。思い込みはよくないですね!
Ubuntu 16.04ではnetlink_diag.koは別パッケージに収録されているのでそれをインストールします。
sudo apt-get install linux-image-extra-$(uname -r)
これでlive migrationが成功しました!
ちなみにですけど、netlink_diag.koがないとstateful stop/start やstateful snapshotsも失敗します。
他に気をつける点は、ググるとひっかかる古い情報ではprofileを変更してたりしますが、デフォルトのdefault profileだけで動きました。むしろ、下手にいじると動かない場合がありました。
LXDの感想
システムコンテナとしてDockerを使い、CentOS 6とUbuntu 14.04を動かそうとしたときはいろいろハマった(gettyがCPU食いつぶすとかudevadm settleでbootが止まるとかとか)んですが、LXDでは images.linuxcontainers.org のイメージを使った限りではすんなりCentOS 6やUbuntu 16.04が動かせていまのところはだいぶ好印象です。
LXDはOpenStackとの連携もできるようですし、より軽量なKVMの代替としてよい選択肢になるんじゃないかと思います。
追記 2017-02-10
live migration元と先とでlxdのバージョンが違うと(例えば2.0.5と2.0.8)このようなエラーで失敗する。
move: error: Bad key: volatile.idmap.base
バージョンを揃えれば成功する。apt-get install lxd でコンテナは稼働したままバージョンを上げられた。
www.twitch.tvの名前が引けない、もしくはチェックサムが0x0000のUDPパケットの件のまとめ
先に原因を書いておくと、
チェックサムが 0x0000 のUDPパケットが戻ってくると、自分の環境では「どこか」で再計算された誤ったチェックサムが付与され、チェックサムが合わないのでユーザーランドに届く前に破棄されていました。
以下、詳しく。
ことの始まりは、自宅でtwitchでSplatoon(先日ようやくSになりました!)の動画配信を見ようとしたのですがアクセスできないのに気づいたことでした。
ブラウザに表示されるエラーメッセージからして名前が引けないようなので、digで試してみたら引けませんでした。(10.6.25.2は宅内のキャッシュサーバー(djbdns))
$ dig www.twitch.tv @10.6.25.2 (しばらくだんまり) ; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> www.twitch.tv @10.6.25.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37843 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.twitch.tv. IN A ;; Query time: 54 msec ;; SERVER: 10.6.25.2#53(10.6.25.2) ;; WHEN: Wed Jan 27 12:13:35 JST 2016 ;; MSG SIZE rcvd: 31
引ける環境でtwitch.tvのネームサーバーを調べて問い合わせてみても引けない。
### 引ける環境 $ dig -t ns twitch.tv ; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> -t ns twitch.tv ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5068 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 12 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;twitch.tv. IN NS ;; ANSWER SECTION: twitch.tv. 10781 IN NS ns1.p18.dynect.net. twitch.tv. 10781 IN NS a3.verisigndns.com. twitch.tv. 10781 IN NS a2.verisigndns.com. twitch.tv. 10781 IN NS ns3.p18.dynect.net. twitch.tv. 10781 IN NS ns2.p18.dynect.net. twitch.tv. 10781 IN NS a1.verisigndns.com. ;; ADDITIONAL SECTION: ns1.p18.dynect.net. 9110 IN A 208.78.70.18 ns1.p18.dynect.net. 281 IN AAAA 2001:500:90:1::18 a3.verisigndns.com. 3571 IN A 69.36.145.33 a3.verisigndns.com. 1940 IN AAAA 2001:502:cbe4::33 a2.verisigndns.com. 3573 IN A 209.112.114.33 a2.verisigndns.com. 3581 IN AAAA 2620:74:19::33 ns3.p18.dynect.net. 10186 IN A 208.78.71.18 ns3.p18.dynect.net. 281 IN AAAA 2001:500:94:1::18 ns2.p18.dynect.net. 17914 IN A 204.13.250.18 a1.verisigndns.com. 2571 IN A 209.112.113.33 a1.verisigndns.com. 3499 IN AAAA 2001:500:7967::2:33 ;; Query time: 1 msec ;; SERVER: 172.24.64.100#53(172.24.64.100) ;; WHEN: Wed Jan 27 12:31:30 JST 2016 ;; MSG SIZE rcvd: 408
$ dig www.twitch.tv @209.112.113.33 (しばらくだんまり) ; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> www.twitch.tv @209.112.113.33 ;; global options: +cmd ;; connection timed out; no servers could be reached
ぬーんと思っていたらアドバイスもらったので、
@hirose31 strace かけてユーザランドに渡ってるか見ればユーザランド以外は信じられそう
— Yusuke MURAMATSU (@muranet) January 18, 2016
tcpdumpしながらstraceでdigを実行してみる。
# tcpdump -nlSxX -i any host 209.112.113.33 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 12:51:30.078313 IP 10.6.25.39.39302 > 209.112.113.33.53: 58570+ [1au] A? www.twi tch.tv. (42) 0x0000: 4500 0046 77c5 0000 4011 9d23 0a06 1927 E..Fw...@..#...' 0x0010: d170 7121 9986 0035 0032 be51 e4ca 0120 .pq!...5.2.Q.... 0x0020: 0001 0000 0000 0001 0377 7777 0674 7769 .........www.twi 0x0030: 7463 6802 7476 0000 0100 0100 0029 1000 tch.tv.......).. 0x0040: 0000 0000 0000 ...... 12:51:30.090812 IP 209.112.113.33.53 > 10.6.25.39.39302: 58570*- 1/0/1 CNAME ssl .cdn.twitch.tv.c.footprint.net. (89) 0x0000: 4500 0075 01ca 0000 3711 1bf0 d170 7121 E..u....7....pq! 0x0010: 0a06 1927 0035 9986 0061 f393 e4ca 8500 ...'.5...a...... 0x0020: 0001 0001 0000 0001 0377 7777 0674 7769 .........www.twi 0x0030: 7463 6802 7476 0000 0100 01c0 0c00 0500 tch.tv.......... 0x0040: 0100 0000 0f00 2303 7373 6c03 6364 6e06 ......#.ssl.cdn. 0x0050: 7477 6974 6368 0274 7601 6309 666f 6f74 twitch.tv.c.foot 0x0060: 7072 696e 7403 6e65 7400 0000 2910 0000 print.net...)... 0x0070: 0000 0000 00 ..... ...
$ strace -f -s 100 dig www.twitch.tv @209.112.113.33 [pid 1162] sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("209.112.113.33")}, msg_iov(1)=[{"Oh\1 \0\1\0\0\0\0\0\1\3www\6twitch\2tv\0\0\1\0\1\0\0)\20\0\0\0\0\0\0\0", 42}], msg_controllen=0, msg_flags=0}, 0 <unfinished ...> ... [pid 1162] recvmsg(20, 0x7fb7f1ca5c90, 0) = -1 EAGAIN (Resource temporarily unavailable) ... [pid 1162] sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("209.112.113.33")}, msg_iov(1)=[{"Oh\1 \0\1\0\0\0\0\0\1\3www\6twitch\2tv\0\0\1\0\1\0\0)\20\0\0\0\0\0\0\0", 42}], msg_controllen=0, msg_flags=0}, 0) = 42 ... [pid 1162] recvmsg(20, 0x7fb7f1ca5c90, 0) = -1 EAGAIN (Resource temporarily unavailable) ...
なんと、ユーザーランド(digコマンド)には応答が届いてないけど、kernelにはUDPパケットが届いてるご様子。
うーんなんでユーザーランドに届かないんだろう。。。と思っていたらまたアドバイスが。
@hirose31 レスポンスの UDP checksum がこいつだけ 0x0000 だ
— Yusuke MURAMATSU (@muranet) January 18, 2016
@muranet @hirose31 私も tv のNSのreplyにUDP checksum 無いことを確認しました。Verisgnに「チェックサムついてないけどどうした? 引けなくなったって言ってる人もいるけど」の旨問い合わせてみました。返答が来るかどうか。
— dais (@hdais) January 18, 2016
確かに、引ける環境ではチェックサムが 0x0000 になっているけど、引けない環境では 0xf393 になっている。
### 引ける環境 04:09:08.940710 IP 209.112.113.33.53 > 10.0.0.211.35082: 12580*- 1/0/1 CNAME ssl.cdn.twitch.tv.c.footprint.net. (89) 0x0000: 4500 0075 bc5c 0000 3a11 76b7 d170 7121 E..u.\..:.v..pq! 0x0010: 0a00 00d3 0035 890a 0061 0000 3124 8500 .....5...a..1$.. 0x0020: 0001 0001 0000 0001 0377 7777 0674 7769 .........www.twi 0x0030: 7463 6802 7476 0000 0100 01c0 0c00 0500 tch.tv.......... 0x0040: 0100 0000 0f00 2303 7373 6c03 6364 6e06 ......#.ssl.cdn. 0x0050: 7477 6974 6368 0274 7601 6309 666f 6f74 twitch.tv.c.foot 0x0060: 7072 696e 7403 6e65 7400 0000 2910 0000 print.net...)... 0x0070: 0000 0000 00 ..... ### 引けない環境 12:51:30.090812 IP 209.112.113.33.53 > 10.6.25.39.39302: 58570*- 1/0/1 CNAME ssl .cdn.twitch.tv.c.footprint.net. (89) 0x0000: 4500 0075 01ca 0000 3711 1bf0 d170 7121 E..u....7....pq! 0x0010: 0a06 1927 0035 9986 0061 f393 e4ca 8500 ...'.5...a...... 0x0020: 0001 0001 0000 0001 0377 7777 0674 7769 .........www.twi 0x0030: 7463 6802 7476 0000 0100 01c0 0c00 0500 tch.tv.......... 0x0040: 0100 0000 0f00 2303 7373 6c03 6364 6e06 ......#.ssl.cdn. 0x0050: 7477 6974 6368 0274 7601 6309 666f 6f74 twitch.tv.c.foot 0x0060: 7072 696e 7403 6e65 7400 0000 2910 0000 print.net...)... 0x0070: 0000 0000 00 .....
引けない環境のを Wireshark でみてみると、incorrectと表示されています。
0x0000 のチェックサムは、(それをパブリックなネットワークで使うかはさておき)仕様的には妥当な値ではあります。
An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care).
https://tools.ietf.org/html/rfc768
余談ですが、チェックサムについてこれがおもしろかったです。
というわけで、恐らく、自分の環境の「どこか」でUDPのチェックサムの再計算をしていて、その計算ロジックが間違っているんじゃないかと思っています。
「どこか」はNATしている民生用のBUFFALOのブロードバンドルーターが怪しいんじゃないかと思っていて問い合わせ中です。続報があればここに書き足します。
補足
0x0000なチェックサムのUDPパケットを返すのは a1.verisigndns.com [209.112.113.33] だけではなく、
- twitch.tvドメインのネームサーバーの a2.verisigndns.com, a3.verisigndns.com
- nic.tvドメインのネームサーバー全て(a4.nstld.com 等)
- tvドメインのネームサーバー全て(a5.nstld.com 等)
も0x0000なチェックサムを返していました。(2016-01-27現在)
twitch.tvドメインのネームサーバーは ns1.p18.dynect.net 等はチェックサムつきのパケットを返すので、当座は
echo 208.78.70.18 > dnscache/root/servers/twitch.tv
して凌ぐことにしました。。
続報
Verisign
@muranet @hirose31 Verisignから、「認識しており、数週間のうちに必要なアクションをする」という返事は来てました。
— dais (@hdais) January 27, 2016
ふろく
- https://github.com/hirose31/udp-checksum-pcap
- tcpdumpで採取したパケットキャプチャ
DHCPでIPアドレスとかは設定するけどresolv.confはいぢられたくない場合
DHCPでIPアドレスとかは設定するけど /ec/resolv.conf は生成・変更されたくない場合のメモ。
Ubuntu
以下、14.04と15.04で確認。
手短に言うと、
- /etc/resolv.conf をsymlinkではなく実ファイルにした上で、
- 以下の内容で /etc/dhcp/dhclient-enter-hooks.d/disable-make_resolv_conf を作る
make_resolv_conf() { :; }
細かく書くと、こんな感じになってる。
- dhclientが/sbin/dhclient-scriptを折りにふれ実行する
- dhclient-script は resolv.conf を生成するためにシェル関数 make_resolv_conf を呼ぶ
- dhclient-script にはフックポイントがあり、以下の場所にあるファイルを . (source) でロードしてくれる。つまり、ここで同名で シェル関数 make_resolv_conf を上書き定義すれば、resolv.conf 生成の処理を制御できる
- resolvconf パッケージがインストールされていると /etc/dhcp/dhclient-enter-hooks.d/resolvconf というファイルが存在するはず
- /etc/dhcp/dhclient-enter-hooks.d/resolvconf は、デフォルトの make_resolv_conf を上書いて /sbin/resolvconf を使って /etc/resolv.conf を生成するようにしている
- ただし、/etc/resolv.conf が symlink ではない場合は make_resolv_conf の上書きはしない
CentOS 6.5
NetworkManagerを無効化した上で、ifcfg-IF に PEERDNS=no を書く。
chkconfig NetworkManager off service NetworkManager stop vi /etc/sysconfig/network-scripts/ifcfg-eth0 # PEERDNS=no と書く
CentOSでもh2oでOCSP Staplingしたい
h2o/1.5.2です。
(たいていそうだと思いますが)中間CAから発行されたサーバー証明書の場合は、h2oではcertificate-fileで指定するファイルの内容を
- サーバー証明書
- 中間CAの証明書
という順序でcatで結合したものにします。順序があるので注意してください。参考: スマートフォン等、携帯端末の一部のみ「証明書が信頼できない」と警告が表示されます | Symantec
さて、h2oは起動時にOCSPレスポンダからレスポンスを得て、それのverifyが成功すればOCSP Staplingを有効にします。
具体的には、share/h2o/fetch-ocsp-response の中でopensslコマンドを使ってこの様にしています。
# certificate-fileで指定されたサーバー証明書からOCSPレスポンダのURIを得る openssl x509 -in $certificate_file -noout -ocsp_uri # certificate-fileから中間CAの証明書を得て($intermediate_file)、OCSPレスポンダにリクエストしてレスポンスを保存する openssl ocsp -issuer $intermediate_file -cert $certificate_file -url $ocsp_uri -header Host $ocsp_host -noverify -respout resp.der # OCSPレスポンスのverify。3つのうちどれかが通ればよい。 # 「for comodo」らしい openssl ocsp -respin resp.der -VAfile $intermediate_file # OpenSSL >= 1.0.2 で実装されたオプションを使用 openssl ocsp -respin resp.der -partial_chain -trusted_first -CAfile $intermediate_file # OpenSSL <= 1.0.1 だとこれになる openssl ocsp -respin resp.der -CAfile $intermediate_file
CentOS 6のOpenSSLは1.0.1なので、最後の3つめの方法でverifyすることになります。
さてさて、opensslはローカルにあるファイルからroot CA群の証明書(trust anchors)を得るのですが、オプションによって探す場所が変わります。
- -CAfile が指定されていない場合
- -CAfile が指定されている場合
先ほどCentOS 6の場合は
openssl ocsp -respin resp.der -CAfile $intermediate_file
でverifyすると書きました。
resp.derのissuerは中間CAです。中間CAの証明書は-CAfileで指定しているのでパスします。
が、中間CA証明書のissuer (=root CA) の証明書は見つけることができないので、エラーとなってしまいます。これがCentOS 6でOCSP Staplingが有効にならない原因です。
ちなみに、-CAfileで指定するファイルの内容を、中間CA+root CAの証明書、にすればパスします。
ちなみにちなみに、Ubuntu 14.04では(パスが /usr/lib/ssl/certs/
で、CentOS 6でOCSP Staplingを有効にするにはどうすればいいか?なのですが、自分のサーバー証明書のroot CAの証明書を別途入手して、どこかに置いて /etc/pki/tls/certs/ の下にhash linkを作るのがいいのではないかと思います。
オマケ
hash linkを作るコマンドライン(ln)を吐く便利関数
cert_hashlink() { [ -r $1 ] || { echo "cannot read file: $1"; return 1; } echo "ln -snf $1 $(openssl x509 -noout -hash < $1).0" }
h2oでmrubyを有効にしてビルドするにはruby >= 1.9が必要
h2o/1.5.2です。
h2oでmrubyを有効にするには、
cmake -DWITH_MRUBY=ON .
とすればよいのですが、ビルドを完遂するにはruby >= 1.9が必要です。
なぜなら、deps/mruby-onig-regexp/mrbgem.rake にこういう処理
def run_command(env, command) STDOUT.sync = true Open3.popen2e(env, command) do |stdin, stdout, thread| print stdout.read fail "#{command} failed" if thread.value != 0 end end
があるのですが、Open3#popen2e が使えるのは 1.9 からだからです。
マルチスレッドでgetaddrinfo(3)するとたまに Temporary failure in name resolution (EAI_AGAIN) で失敗する件
マルチスレッドでgetaddrinfo(3)するとたまにTemporary failure in name resolution (EAI_AGAIN) で失敗します。
自分は↓な環境で確認しました。
こういうコードで再現します。(ruby 2.1.4で確認)
なお、便宜的にrubyで再現コードを書いていますが、該当環境であれば言語問わずマルチスレッド+getaddrinfo(3)の組み合わせで発現する問題です。
対処法は、
のrpmをCentOS 6 Updatesにあるバージョン 2.12-1.149.el6_6.9 のに上げればOKです。
ちなみに自分は、Chef実行時にたまにberksのAPIサーバーの名前が引けなくてコケてたのがこれで直りました。