jmacs-ts
2021年10月25日 21時08分
お世話になります。
armadillo-x1を使用中、/dev/mmcblk2p2 の空き容量 820MB に対し、100MBのデータをscpコマンドで送信したところ、容量が0となる現象が発生しています。
送信したデータサイズも100MBのままで、削除しても空き容量が確保されませんが、再起動を行うことで、空き容量が復旧します。
現状では再現性は100%となるのですが、考えられる原因や対処方法について、何かご教授頂けないでしょうか。
よろしくお願いいたします。
コメント
jmacs-ts
> 入江です。
>
> 以下のコマンドの実行結果を送っていただけますでしょうか。
>
> * mount
> * df -h
>
> また、scpのコピー先のディレクトリ(Armadillo)を絶対パスで教えていただけ
> ますでしょうか。
>
> 以上、よろしくお願いいたします。
>
ご連絡ありがとうございます。
コマンド実行結果を下記致します。
* mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=86035,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=203808k,mode=755)
/dev/mmcblk2p2 on / type ext4 (rw,relatime,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mtdblock1 on /opt/license type squashfs (ro,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=101900k,mode=700,uid=1000,gid=1000)
*df -h
Filesystem Size Used Avail Use% Mounted on
udev 10M 0 10M 0% /dev
tmpfs 200M 24M 176M 12% /run
/dev/mmcblk2p2 3.3G 3.3G 0 100% /
tmpfs 498M 0 498M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 498M 0 498M 0% /sys/fs/cgroup
/dev/mtdblock1 128K 128K 0 100% /opt/license
tmpfs 100M 0 100M 0% /run/user/1000
at_takuma.fukuda
福田です。
確認結果の送付ありがとうございます。
ルートファイルシステムの書き込み保護機能が有効になっている可能性なども考慮しておりましたが、
こちらの可能性が排除されたことを確認いたしました。
入江からご質問させていただいております、下記事項についてもお教えいただけませんでしょうか？
> また、scpのコピー先のディレクトリ(Armadillo)を絶対パスで教えていただけ
> ますでしょうか。
またこの現象については再現性100%とのことですが、
現状、問題が発生しているのは1台のみでしょうか？
あるいは複数のArmadillo-X1で同様の現象が発生していらっしゃる状態でしょうか？
また、現在問題が発生しているArmadillo-X1については、リモートで動作を確認されている状況でしょうか？
あるいは手元で動作を確認されていらっしゃいますでしょうか？
質問ばかりになってしまって申し訳ございませんが、どうぞよろしくお願いいたします。
jmacs-ts
> 福田です。
>
> 確認結果の送付ありがとうございます。
> ルートファイルシステムの書き込み保護機能が有効になっている可能性なども考慮しておりましたが、
> こちらの可能性が排除されたことを確認いたしました。
>
> 入江からご質問させていただいております、下記事項についてもお教えいただけませんでしょうか？
> > また、scpのコピー先のディレクトリ(Armadillo)を絶対パスで教えていただけ
> > ますでしょうか。
>
>
> またこの現象については再現性100%とのことですが、
> 現状、問題が発生しているのは1台のみでしょうか？
> あるいは複数のArmadillo-X1で同様の現象が発生していらっしゃる状態でしょうか？
>
> また、現在問題が発生しているArmadillo-X1については、リモートで動作を確認されている状況でしょうか？
> あるいは手元で動作を確認されていらっしゃいますでしょうか？
>
> 質問ばかりになってしまって申し訳ございませんが、どうぞよろしくお願いいたします。
お世話になります。
コピー先パスについて記載が漏れており失礼しました。内容を下記致しますので、ご確認ください。
コピー先パス：/home/atmark/
また、現象については 1 台のみで発生しており、リモートではなく手元にある状態で検証しています。
以上、ご確認宜しくお願い申し上げます。
at_takuma.fukuda
jmacs-ts
> ご回答ありがとうございます。
>
> scpコマンドにてファイル送信を行って空き容量が0となった状態で、
> 以下のコマンドを実行した後の結果を教えていただけませんでしょうか？
>
> du -h /home/atmark/
> ls -l /home/atmark
>
> また、scpにて送信したファイル名についても差し支えなければ教えていただけませんでしょうか？
ご確認ありがとうございます。
コマンドの実行結果とファイル名を下記致します。ご確認よろしくお願いします。
送信ファイル名：dummy_100M
du -h /home/atmark/
101M /home/atmark/
$ ls -l /home/atmark
-rw-r--r-- 1 atmark atmark 104857600 Oct 22 18:43 dummy_100M
-rwxr-xr-x 1 atmark atmark 1292 Jan 13 2021 netsetup.sh
-rwxr-xr-x 1 atmark atmark 1289 Oct 20 09:27 netsetup_debug.sh
at_takuma.fukuda
jmacs-ts
> ありがとうございます。
> ファイルの容量そのものが巨大になっているのではない事が確認出来ました。
>
> 次はファイル送信によってどのディレクトリの容量が変化しているかを確認出来ればと思います。
> 以下の手順をお試しいただき、それぞれの実行結果をお教えいただけませんでしょうか？
>
> ①再起動直後の残容量が0で無い状態で以下のコマンドを実行する
> du -hc -d 1 /
>
> ②①の状態からscpによるファイル転送を行って残容量が0になった状態で以下のコマンドを実行する
> du -hc -d 1 /
ご確認ありがとうございます。
実行結果を下記致します。ご確認よろしくお願いします。
① 実行結果
718M /usr
0 /sys
5.2M /sbin
5.0M /bin
4.0K /mnt
32K /home
3.2M /run
4.5K /opt
4.0K /boot
1.7M /root
3.9M /etc
4.0K /srv
0 /dev
4.0K /media
261M /var
31M /lib
du: cannot access '/proc/1849/task/1849/fd/3': No such file or directory
du: cannot access '/proc/1849/task/1849/fdinfo/3': No such file or directory
du: cannot access '/proc/1849/fd/4': No such file or directory
du: cannot access '/proc/1849/fdinfo/4': No such file or directory
0 /proc
32K /tmp
1.1G /
1.1G total
② 実行結果
718M /usr
0 /sys
5.2M /sbin
5.0M /bin
4.0K /mnt
101M /home
3.2M /run
4.5K /opt
4.0K /boot
1.7M /root
3.9M /etc
4.0K /srv
0 /dev
4.0K /media
261M /var
31M /lib
du: cannot access '/proc/1897/task/1897/fd/3': No such file or directory
du: cannot access '/proc/1897/task/1897/fdinfo/3': No such file or directory
du: cannot access '/proc/1897/fd/4': No such file or directory
du: cannot access '/proc/1897/fdinfo/4': No such file or directory
0 /proc
32K /tmp
1.2G /
1.2G total
at_takuma.fukuda
jmacs-ts
> ご確認ありがとうございます。
> /home/のみが100M増加していて、全体の容量も100Mだけ増加している状態である事を確認出来ました。
>
> 何らかのプロセスによってファイル容量が誤認されている状態に無いかを確認するため、
> 以下を実行いただけますでしょうか？
> lsof / | sort -k7 -nr | head -20
>
> lsofコマンドが実行出来無い場合は、Armadillo-X1をインターネットに接続して以下でインストールを行ってください。
> apt install lsof
ご確認ありがとうございます。
実行結果を下記致します。ご確認よろしくお願いします。
NetworkMa 889 root mem REG 179,26 25675096 6775 /usr/lib/arm-linux-gnueabihf/libicudata.so.57.1
rsyslogd 751 root 6w REG 179,26 12275712 14982 /var/log/syslog
rsyslogd 751 root 10w REG 179,26 10403840 18021 /var/log/daemon.log
systemd-u 291 root mem REG 179,26 8440991 6894 /lib/udev/hwdb.bin
systemd-u 291 root 6r REG 179,26 8440991 6894 /lib/udev/hwdb.bin
python3 1808 root txt REG 179,26 3283992 12301 /usr/bin/python3.5
rsyslogd 751 root 9w REG 179,26 1769472 18062 /var/log/messages
NetworkMa 889 root mem REG 179,26 1689296 6776 /usr/lib/arm-linux-gnueabihf/libicui18n.so.57.1
python3 1808 root mem REG 179,26 1521112 4105 /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1
lighttpd 1441 www-data mem REG 179,26 1521112 4105 /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1
NetworkMa 889 root txt REG 179,26 1505952 2401 /usr/sbin/NetworkManager
wpa_suppl 1450 root txt REG 179,26 1372200 5126 /sbin/wpa_supplicant
systemd-t 402 systemd-timesync mem REG 179,26 1367664 5620 /lib/systemd/libsystemd-shared-232.so
systemd-l 864 root mem REG 179,26 1367664 5620 /lib/systemd/libsystemd-shared-232.so
systemd-j 274 root mem REG 179,26 1367664 5620 /lib/systemd/libsystemd-shared-232.so
systemd 1823 atmark mem REG 179,26 1367664 5620 /lib/systemd/libsystemd-shared-232.so
systemd 1 root mem REG 179,26 1367664 5620 /lib/systemd/libsystemd-shared-232.so
(sd-pam 1826 atmark mem REG 179,26 1367664 5620 /lib/systemd/libsystemd-shared-232.so
ModemMana 865 root mem REG 179,26 1231864 18355 /usr/lib/arm-linux-gnueabihf/libqmi-glib.so.5.1.0
wpa_suppl 1450 root mem REG 179,26 1202628 11275 /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.2
at_takuma.fukuda
jmacs-ts
at_takuma.fukuda
確認ありがとうございます。
初期化した状態でのご確認をいただいたのは、
ハードウェアや弊社配布のソフトウェアに問題が潜在していないかを確認する目的でございました。
初期化した状態では現象が再現しないとの事ですので、
ユーザ様にて追加されたアプリケーションや変更された設定などの影響とみられます。
こちらではどのような操作を行われていたかについては把握する事が出来ませんので、
何が影響を与えているかについては、ご自身で切り分けを実施いただきたく存じます。
切り分けにあたって何か参考となる情報をお伝え出来ればよいのですが、
ここまでご確認いただいた情報からはきっかけとなるようなものは発見されませんでした。
悪しからずご容赦くださいませ。
at_dominique.m…
at_akihito.irie
2021年10月26日 9時42分
入江です。
以下のコマンドの実行結果を送っていただけますでしょうか。
*
mount*
df -hまた、scpのコピー先のディレクトリ(Armadillo)を絶対パスで教えていただけ
ますでしょうか。
以上、よろしくお願いいたします。