bobrofon
commented
2 years ago OK, what I have figured out so far:
- Fortunately, I can reproduce this problem on my Xiaomi Mi A1 with LinageOS 18.1.
- This problem can be reproduced from a command line without easysshfs application (you can just run
sshfs -o 'ssh_command=ssh' host:/remote/path /local/pathandumount /local/pathfrom shell). It means the problem is not related to APK itself, embedded busybox or libsu. - Additional
umountoptions like-lor-fdon't change anything. Also, you can use thebusybox/toyboxversion ofumountwith the same result. So it is not the problem withumountimplementation. - Reproducibility of this problem is not 100%. Sometimes, after unmounting the directory, sshfs and ssh processes terminate and sometimes they don't. I don't see a clear pattern in this behavior. When I try to connect to sshfs with
straceto see what is happening on unmounting, the problem stops reproducing and sshfs terminates every time, like it should. (Some kind of race condition?)
It looks like the problem is somewhere in sshfs/ssh binary executable files. Version 0.5.6 is the current open beta on Google Play. But it shouldn't be important because sshfs/ssh versions have not changed since 2021/02/14. TODO(@bobrofon): test executable files from previous versions to be sure. @kattjevfel when did you notice this behavior for the first time?
Steps to reproduce:
- Mount some directory
./sshfs -o 'ssh_command=./ssh,UserKnownHostsFile=/dev/null,StrictHostKeyChecking=no,IdentityFile=/sdcard/id_rsa' user@host:/ /mnt/runtime/default/emulated/0/mnt - Unmount this directory
umount /mnt/runtime/default/emulated/0/mnt - Check that it was unmounted
mount | grep sshfs // should be emptybut ssh/sshfs processes are still running.
ps -A | grep ssh root 25452 1 2500 2040 do_select 0 S ssh root 25453 1 8592 212 futex_wait_queue_me 0 S sshfsAlso, one of the sshfs threads should consume a full single CPU core.
top -H TID USER PR NI VIRT RES SHR S[%CPU] %MEM TIME+ THREAD PROCESS 25455 root 20 0 8.3M 216K 4.0K R 100 0.0 11:39.46 sshfs sshfs - (Optional) Kill ssh process. Simple
kill -INT -p $PIDwill be enough. The ssh process will die but it will not change anything.
The most suspicious part is the sshfs executable. The sshfs executable contains: sshfs itself, libfuse, uclibc. When this bug happens, sshfs process sticks with two threads: one thread consumes 100% CPU and another thread is waiting on futex (most likely it is waiting for the first thread to terminate). This is the status of signals of the thread consuming 100% CPU:
grep Sig /proc/25455/status
SigQ: 4/13124
SigPnd: 0000000000000000
SigBlk: 0000000080004007
SigIgn: 0000002000001000
SigCgt: 0000000180004003SIGHUP, SIGINT, SIGQUIT, SIGTERM are blocked. It looks like a worker thread of libfuse:
/* Disallow signal reception in worker threads */
sigemptyset(&newset);
sigaddset(&newset, SIGTERM);
sigaddset(&newset, SIGINT);
sigaddset(&newset, SIGHUP);
sigaddset(&newset, SIGQUIT);But right now I have no idea what this thread is doing.
The most suspicious parts are libfuse and uclibc (or something in the middle). Need further debugging.
kattjevfel
Everytime I close EasySSHFS when I'm done accessing my remote files, my phone starts getting really warm, and draining battery like mad. I've been dealing with this by just restarting my phone, but I finally looked into it and pulled up htop via adb, which shows 6
sshfsprocesses maxing out CPU cores:Running EasySSHFS 0.5.6 from Google Play, lineageos 18.1 (android 11) on a OnePlus 5T.