初めてお世話になります。
タイトルの通り、Archlinux kernel4.4.3-1とvsftpd: version 3.0.3にてファイルリストが32件以上取得できない問題が起こっており、
解決法が見当たらず困っております。
テスト環境
VMware-player7.1.3 build-3206955
Archlinux 4.4.3-1-ARCH
vsftpd: version 3.0.3
/etc/vsftpd.conf
sudo pacman -S vsftpd
vsftpd: version 3.0.3
/etc/vsftpd.conf
write_enable=YES
local_enable=YES
anon_upload_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
ascii_upload_enable=YES
ascii_download_enable=YES
listen=YES
上記環境にて下記の通り接続後、ファイルが32以上あるディレクトリへcdで移動しlsを打つと切断される。
ファイル数が31までの場合は切断されず、ファイルリストが表示される
(ディレクトリ名、ファイル名パーミッションなどは関係ないと思われる)
ftp -d
ftp> open 192.168.5.201
Connected to 192.168.5.201:21.
220 (vsFTPd 3.0.3)
Name (192.168.5.201:21:hoge):
---> USER hoge
331 Please specify the password.
Password:
---> PASS XXXX
230 Login successful.
---> SYST
215 UNIX Type: L8
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd test
---> CWD test
250 Directory successfully changed.
ftp> ls
---> PORT 192,168,7,1,252,219
200 PORT command successful. Consider using PASV.
---> LIST
150 Here comes the directory listing.
421 Service not available, remote server has closed connection
※vsftp.logではエラーを吐いていないため貼り付けておりません
問題の確認のためにvmwarepleyrで試しましたが、問題は実機で発覚しており、vmwareplayerが問題ではないことがわかっております。
上記説明の通り、ディレクトリ内ファイル31件までの振る舞いはなんとも無いため、いつの時点からかは不明。
また、2015/12/31の時点でのvmplayerのバックアップがあったので(4.2.5-1-ARCH)、そちらにvsftpd3.0.3をインストールし、同じvsftpd.confにて試したと
ころ、ディレクトリ内のファイルが100以上あってもlsコマンドで切断されることはなく、正常にリストを表示できることを確認し、
sudo pacman -Syu にてアップデートするとディレクトリ内のファイルが32になった時点でファイルリストの表示がされず切断される状態に
なったことから、カーネルとvsftpdの相性問題のようなきがするのですが、問題の切り分け、解決ができません。
問題の解決方法がございましたらご教授くださいますようお願いいたします。
2015/12/31の時点(4.2.5-1-ARCH)からのアップデートリストを念のため載せておきます。ほかに必要な情報がありましたら、申し付けてください。
2016/03/09
sudo pacman -Syu
パッケージ (196) alsa-plugins-1.1.0-3 archlinux-keyring-20160215-1
avahi-0.6.32-2 bind-tools-9.10.3.P3-3 binutils-2.26-3
boost-libs-1.60.0-2 ca-certificates-mozilla-3.22.1-1
cantarell-fonts-1:0.0.24-1 coreutils-8.25-1
cryptsetup-1.7.1-1 curl-7.47.1-2 dbus-glib-0.106-1
dcadec-0.2.0-1 device-mapper-2.02.144-1 dhcpcd-6.10.1-1
elfutils-0.165-1 ffmpeg-1:3.0-1 ffmpeg2.8-2.8.6-1
filezilla-3.16.0-1 findutils-4.6.0-1 firefox-44.0.2-2
flashplugin-11.2.202.569-1 flex-2.6.0-2 freetype2-2.6.3-1
fuse-2.9.5-1 gcc-5.3.0-5 gcc-libs-5.3.0-5
geoip-database-20160105-1 gettext-0.19.7-1 giflib-5.1.2-1
glib2-2.46.2-4 glibc-2.23-1 gmp-6.1.0-3 gnupg-2.1.11-1
gnutls-3.4.10-1 graphite-1:1.3.6-1 grep-2.23-1 gsm-1.0.14-1
gst-plugins-base-libs-1.6.3-1 gstreamer-1.6.3-1
gtk-update-icon-cache-3.18.8-1 gtk2-2.24.30-1 gtk3-3.18.8-1
gvfs-1.26.3-1 gvfs-smb-1.26.3-1 harfbuzz-1.2.3-1
harfbuzz-icu-1.2.3-1 hunspell-1.3.4-1 ibus-1.5.13-1
ibus-anthy-1.5.8-1 iputils-20150815.1c59920-3
iso-codes-3.66-1 krb5-1.13.2-3 ldns-1.6.17-4
lib32-elfutils-0.165-1 lib32-freetype2-2.6.3-1
lib32-gcc-libs-5.3.0-5 lib32-glibc-2.23-1
lib32-gnutls-3.4.9-1 lib32-harfbuzz-1.2.3-1
lib32-libcap-2.25-1 lib32-libdrm-2.4.67-1
lib32-libgcrypt-1.6.5-1 lib32-libpng-1.6.21-1
lib32-libpulse-8.0-1 lib32-libsndfile-1.0.26-1
lib32-llvm-libs-3.7.1-1 lib32-mesa-11.1.2-1
lib32-mesa-libgl-11.1.2-1 lib32-nettle-3.2-1
lib32-p11-kit-0.23.2-1 lib32-systemd-229-1
lib32-wayland-1.10.0-1 libass-0.13.2-1 libbsd-0.8.2-2
libburn-1.4.2.pl01-1 libcap-2.25-1 libcmis-0.5.1-1
libcups-2.1.3-1 libdatrie-0.2.10-1 libdrm-2.4.67-1
libebml-1.3.3-2 libelf-0.165-1 libetonyek-0.1.6-1
libevdev-1.4.6-1 libevent-2.0.22-2 libexttextcat-3.4.4-1
libfbclient-2.5.5.26952-1 libfilezilla-0.4.0.1-1
libgcrypt-1.6.5-1 libibus-1.5.13-1 libical-2.0.0-2
libimobiledevice-1.2.0-3 libixion-0.9.1-4 liblangtag-0.5.8-2
libldap-2.4.43-3 libmatroska-1.4.4-1 libmpcdec-1:0.1+r475-1
libnotify-0.7.6-2 libodfgen-0.1.6-1 liborcus-0.9.2-3
libpagemaker-0.0.3-1 libpng-1.6.21-1 libproxy-0.4.12-1
libpulse-8.0-3 libreoffice-fresh-5.1.0-2
libreoffice-fresh-ja-5.1.0-1 librevenge-0.0.4-1
librsvg-2:2.40.13-1 libsecret-0.18.4-1 libshout-1:2.4.1-2
libsndfile-1.0.26-1 libssh-0.7.3-1 libssh2-1.7.0-2
libsystemd-229-3 libthai-0.1.24-1 libvisio-0.1.5-1
libvpx-1.5.0-4 libwbclient-4.3.5-1 libwpd-0.10.1-1
libwps-0.4.3-1 libx264-2:148.20160103-1 libxslt-1.1.28-4
linux-4.4.3-1 linux-api-headers-4.4.1-1
linux-firmware-20160113.40e9ae8-1 llvm-libs-3.7.1-1
lvm2-2.02.144-1 make-4.1-3 man-pages-4.04-1 mdadm-3.4-1
mesa-11.1.2-1 mesa-libgl-11.1.2-1 mkinitcpio-19-1
mpfr-3.1.3.p5-1 nano-2.5.3-1 neon-0.30.1-2 nettle-3.2-1
nspr-4.12-1 nss-3.22.1-1 open-vm-tools-6:10.0.7-3
openssh-7.2p1-1 openssl-1.0.2.g-3 opus-1.1.2-1
orage-4.12.1-2 orc-0.4.25-1 package-query-1.8-1
pacman-5.0.1-2 pacman-mirrorlist-20160227-1 pango-1.39.0-1
pciutils-3.4.1-1 perl-uri-1.71-1 pixman-0.34.0-1
poppler-0.41.0-1 python-3.5.1-2 python-dbus-1.2.2-1
python-dbus-common-1.2.2-1 python2-2.7.11-2
python2-dbus-1.2.2-1 qt4-4.8.7-7 redland-1:1.0.17-3
ruby-2.3.0-2 s-nail-14.8.6-2 samba-4.3.5-1
smbclient-4.3.5-1 sqlite-3.11.1-1 systemd-229-3
systemd-sysvcompat-229-3 texinfo-6.1-1
thin-provisioning-tools-0.6.0-2 thunderbird-38.6.0-1
thunderbird-i18n-ja-38.6.0-1 ttf-dejavu-2.35-1
tzdata-2016a-1 udisks2-2.1.7-1 upower-0.99.4-2
v4l-utils-1.10.0-1 vim-7.4.1386-1 vim-runtime-7.4.1386-1
vlc-2.2.2-3 vte-common-0.42.4-1 wayland-1.10.0-1
wget-1.16.3-2 wine-1.9.5-1 winetricks-20160219-1 x265-1.9-1
xf86-input-evdev-2.10.1-3 xfsprogs-4.3.0-1
xkeyboard-config-2.17-2 xorg-server-1.18.1-3
xorg-server-common-1.18.1-3 xorg-xrandr-1.5.0-1
xorg-xrdb-1.1.0-2 xterm-323-1 yaourt-1.8-1 zip-3.0-7
奇妙な挙動ですね。
役に立つかわかりませんが、log_ftp_protocolを設定してデバッグ用のログを出力させてみるというのはどうでしょうか。
あるいは、カーネルが原因なのであれば、カーネルだけをダウングレードすることでそれをはっきりさせることができるかもしれません。
オフライン
返信ありがとうございます。
カーネルを戻そうと、/var/cache/pacman/pkgを覗いたところ、2016/12/31のバックアップの時点で
pacman -Scc で消していたようでありませんでした。
そこで、もう一度2015/12/31に巻き戻し、vsftpdをインストールし、動作に問題ないことを確認し(log_ftp_protocol=YES追加)
カーネルのみアップデートしたところ(4.2.5-1-ARCH→linux-4.4.3-1)
lsによるlist取得時も問題なく切断もされませんでした。
200近くあるアップデートから干渉しているアップデートを探さないといけなくなりました。┐(´∀｀)┌
取り合えず、カーネルと一緒に入れられるべきものからアップデート＆テストしていき、そのあとvsftpdとの依存関係にあるものを順番に
アップデートしてみようと思います。
何か情報がございましたら、提供をお願いいたします。
追記です。
/etc/vsftpd.confにlog_ftp_protocol=YESを追記し、testディレクトリにファイルを33置いた状態で接続したときの
vsftp.logを載せておきます。
(archlinuxの状態は2016/12/31の時点から今日までのアップデートをすべてあてたときの状態です)
host,clientともに192.168.5.201です。
Thu Mar 10 21:21:12 2016 [pid 2] CONNECT: Client "192.168.5.201"
Thu Mar 10 21:21:12 2016 [pid 2] FTP response: Client "192.168.5.201", "220 (vsFTPd 3.0.3)"
Thu Mar 10 21:21:14 2016 [pid 2] FTP command: Client "192.168.5.201", "USER hoge"
Thu Mar 10 21:21:14 2016 [pid 2] [hoge] FTP response: Client "192.168.5.201", "331 Please specify the password."
Thu Mar 10 21:21:16 2016 [pid 2] [hoge] FTP command: Client "192.168.5.201", "PASS <password>"
Thu Mar 10 21:21:16 2016 [pid 1] [hoge] OK LOGIN: Client "192.168.5.201"
Thu Mar 10 21:21:17 2016 [pid 3] [hoge] FTP response: Client "192.168.5.201", "230 Login successful."
Thu Mar 10 21:21:17 2016 [pid 3] [hoge] FTP command: Client "192.168.5.201", "SYST"
Thu Mar 10 21:21:17 2016 [pid 3] [hoge] FTP response: Client "192.168.5.201", "215 UNIX Type: L8"
Thu Mar 10 21:21:21 2016 [pid 3] [hoge] FTP command: Client "192.168.5.201", "CWD test"
Thu Mar 10 21:21:21 2016 [pid 3] [hoge] FTP response: Client "192.168.5.201", "250 Directory successfully changed."
Thu Mar 10 21:21:22 2016 [pid 3] [hoge] FTP command: Client "192.168.5.201", "PORT 192,168,5,201,186,98"
Thu Mar 10 21:21:22 2016 [pid 3] [hoge] FTP response: Client "192.168.5.201", "200 PORT command successful. Consider using PASV."
Thu Mar 10 21:21:22 2016 [pid 3] [hoge] FTP command: Client "192.168.5.201", "LIST"
Thu Mar 10 21:21:22 2016 [pid 3] [hoge] FTP response: Client "192.168.5.201", "150 Here comes the directory listing."
ここでLogは終わってますが、この時点でftpclient側では切断されたことになっています。
正常だと、この後ディレクトリ内のファイルリストが表示されます。
英語版の Arch フォーラムに同じようなエラーを seccomp_sandbox=NO で修正できるという情報を見つけました。
問題が報告されたのは2012年頃という古い情報で、その後、一度上流で解決したとなっていますが、
フォーラムのスレッドから参照されている Fedora のバグトラッカーには同じ問題がまた発生するという新しい報告があります。
同じ原因によるものかどうかは定かではありませんが、seccomp_sandbox=NO を設定することで解決できるようです。
https://bbs.archlinux.org/viewtopic.php?id=147074
https://bugzilla.redhat.com/show_bug.cgi?id=845980
オフライン
返信ありがとうございます。
お手数をおかけしました。早速以下の通り修正し、再起動してためしてみたところ
vsftpd: version 3.0.3
/etc/vsftpd.conf
sudo pacman -S vsftpd
vsftpd: version 3.0.3
/etc/vsftpd.conf
write_enable=YES
local_enable=YES
anon_upload_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
log_ftp_protocol=YES 追加
seccomp_sandbox=NO 追加
connect_from_port_20=YES
ascii_upload_enable=YES
ascii_download_enable=YES
listen=YES
sudo systemctl start vsftpd.service
sudo systemctl | grep vsftpd
● vsftpd.service loaded failed failed vsftpd daemon
とのことで正常にvsftpdが起動できず、ログインできませんでした。
で。
干渉しているパッケージ探しのほうですが、意外とあっさり見つかりましたので報告いたします。
glibc-2.23-1-x86_64
上記パッケージに更新すると、ディレクトリ内のファイル数が32以上になると切断される問題が起こります。
テストの手順
1)VMWarePlayerを2015/12/31まで巻き戻し、アップデートリストの上から順番に一つづつ更新
2)binutils-2.26-3を更新したところで、問題の現象がでたので、ここで再度2015/12/31まで巻き戻し
3)binutils-2.26-3のみを更新し、問題の現象になることを確認して、再度2015/12/31まで巻き戻し
4)binutils-2.26-3の依存関係にある「glibc-2.23-1-x86_64」のみを更新し、問題の現象になることを確認
5)再度2015/12/31に巻き戻し/etc/pacman.confに「IgnorePkg=glibc」を追記し、glibcを除いたすべてを更新
警告: glibc: パッケージの更新を無視 (2.22-3 => 2.23-1) ←2.22-3では問題が無い
依存関係を解決しています...
警告: パッケージ glibc-2.23-1 を無視
警告: "glibc>=2.23" を解決できません、"binutils" の依存
警告: パッケージ glibc-2.23-1 を無視
警告: "glibc>=2.23" を解決できません、"gcc-libs" の依存
警告: "gcc-libs=5.3.0-5" を解決できません、"gcc" の依存
警告: パッケージ glibc-2.23-1 を無視
警告: "glibc>=2.23" を解決できません、"binutils" の依存
警告: "binutils>=2.26" を解決できません、"gcc" の依存
警告: パッケージ glibc-2.23-1 を無視
警告: "glibc>=2.23" を解決できません、"gcc-libs" の依存
:: 依存関係を解決できないために以下のパッケージを更新できません:
依存関係にある「binutils」「gcc-libs」「gcc」は更新せず。
6)vsftpに接続し、32ファイル以上あるディレクトリに接続したところ、問題の現象が再現しないことを確認しました。
取り急ぎご報告ということで。
現在稼働中の環境にてどう対応するかは思案中。
どうやって問題を解決するか考えていたのですが、「glibc」のダウングレードは依存関係が多すぎてかなり骨が折れそう。
(というか現状、それぞれの古いパッケージが手元に無いため、現実的ではない)
それ以前に、そもそも「glibc」ってなに？ってことで調べてみるとカーネルと一緒に読み込まれるCライブラリだということでした。
(依存関係が多いのに納得)
というか、これはglibcの問題なのか、vsftpdの問題なのか？そもそも、他の人はglibcとvsftpdのバージョン問題のバージョンに
あわせるとやはり同じ状況になるのか？？？
解決方法云々の前にまだ情報が足らないということに気がつきました。＿|￣|○
開発者にこんな事象があるんですけど、修正おねがいできますか？といっても、現状報告者が一人だけじゃね＿|￣|○
どうしよう┐(´∀｀)┌
自分のPCに vsftpd をインストールして実際に試してみましたが、同じく接続が切れるのが確認できました。確かに問題は存在するようです。
しかしながら、上に書いた seccomp_sandbox=NO で問題が解決できる（ちゃんと全部ファイルリストが取得できる）のも確認しました。
sudo systemctl start vsftpd.service
sudo systemctl | grep vsftpd
● vsftpd.service loaded failed failed vsftpd daemon
とのことで正常にvsftpdが起動できず、ログインできませんでした。
上記について、underodig さんの結果とは違って、こちらでは正常に起動できるので腑に落ちません。
起動できない原因が他にないでしょうか。
正常に起動できることを確認できた設定ファイルは以下の通りです（デフォルトに seccomp_sandbox を追加しただけ）:
# Example config file /etc/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=YES
#
# Uncomment this to allow local users to log in.
#local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
#write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
#local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
#anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/vsftpd.log
#
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
#xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
#nopriv_user=ftpsecure
#
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
#async_abor_enable=YES
#
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that on some FTP servers, ASCII support allows a denial of service
# attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd
# predicted this attack and has always been safe, reporting the size of the
# raw file.
# ASCII mangling is a horrible feature of the protocol.
#ascii_upload_enable=YES
#ascii_download_enable=YES
#
# You may fully customise the login banner string:
#ftpd_banner=Welcome to blah FTP service.
#
# You may specify a file of disallowed anonymous e-mail addresses. Apparently
# useful for combatting certain DoS attacks.
#deny_email_enable=YES
# (default follows)
#banned_email_file=/etc/vsftpd.banned_emails
#
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
# (Warning! chroot'ing can be very dangerous. If using chroot, make sure that
# the user does not have write access to the top level directory within the
# chroot)
#chroot_local_user=YES
#chroot_list_enable=YES
# (default follows)
#chroot_list_file=/etc/vsftpd.chroot_list
#
# You may activate the "-R" option to the builtin ls. This is disabled by
# default to avoid remote users being able to cause excessive I/O on large
# sites. However, some broken FTP clients such as "ncftp" and "mirror" assume
# the presence of the "-R" option, so there is a strong case for enabling it.
#ls_recurse_enable=YES
#
# When "listen" directive is enabled, vsftpd runs in standalone mode and
# listens on IPv4 sockets. This directive cannot be used in conjunction
# with the listen_ipv6 directive.
listen=YES
#
# This directive enables listening on IPv6 sockets. To listen on IPv4 and IPv6
# sockets, you must run two copies of vsftpd with two configuration files.
# Make sure, that one of the listen options is commented !!
#listen_ipv6=YES
seccomp_sandbox=NOオフライン
確かに「seccomp_sandbox=NO」を追記することで、サービスを正常に起動することができ
なおかつ、問題もクリアできました。
コピーアンドペーストしたことで、コマンドのつづりに問題はないと過信していました。
おっしゃるとおり、vsftpd.confに追記したところにゴミがはいっていました。
誠に申し訳ございませんでした。
また、非常に助かりました。ありがとうございました。
また何か問題が起こったときにはよろしくお願いいたします。
あと、今回のような一件はどこか報告するような場所があるのでしょうか？
archlinuxに限らず、linuxそのものが素人なので、お手数ですがご指南お願いいたします。
ソフトウェアの問題の報告については ArchWiki に情報がまとまっているページが存在します:
https://wiki.archlinuxjp.org/index.php/ … 4%E3%83%B3
他の Linux ディストリビューションでは全てのソフトウェアのバグを一手に引き受けてディストリビューションの開発者が上流（ソフトウェアの開発元）と間を取り持ってくれるような場所があったりしますが、
Arch Linux では上流のソフトウェアは改造を加えずそのままユーザーに提供するのをモットーとしているので、
問題がはっきりとわかっている場合はソフトウェアの開発元が用意しているフォーラムやバグトラッキングシステム、あるいは開発者の連絡先に直接報告することを推奨しています。
問題を無事に回避することができたということで、お役にたてて幸いです。
オフライン
バグ報告のご指南ありがとうございました。
バグ報告ガイドライン読ませていただきます。
vsftpd開発者殿に報告いたしました。
vsftpd、glibcどちらの問題かはわからないので、起こっている現象の事実だけを報告いたしました。
kusakata様
解決の手引きありがとうございました。
また問題が起こったときには、よろしくお願いいたします。