2

I'm trying to unmount a harddisk and have several tmux sessions open.

$ sudo umount /mnt/PIHDD
umount: /mnt/PIHDD: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)


$ lsof /mnt/PIHDD/
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
tmux    1415   pi   36r   DIR    8,1    20480    5 /mnt/PIHDD

$ ps 1415
  PID TTY      STAT   TIME COMMAND
 1415 ?        Ss    17:26 tmux

How can I tell which tmux session to look in, or whatever else the reason is? I assumed some session contains a window where the current directory is on that drive.

I manually looked through all the panes in all the sessions but could not find the offender.

https://superuser.com/a/212913/291007 seems helpful, but cat /proc/1415/environ does not contain ^TMUX= at all. It does however contain ^@_=/usr/bin/tmux^@.
This answer does generate the expected output but does not contain the PID 1415.

According to lsof -p 1415, that process has currently open every directory that I have open in tmux - not just those of one session. That means the thread with PID 1415 is actually tmux itself. It's worth noting though that lsof only lists the mount point dir /mnt/PIHDD, not any file within it.

Something interesting is that ls /proc/1415/fd shows the relevant mount point in a different color than the other drives:
enter image description here

Also perhaps of relevance: The drive mounted to /mnt/PIHDD is NTFS-formatted. The drive at /mnt/oceanPortal is EXT-4.

Why is tmux using my hard drive and how do I stop that safely?

Additional information that could be helpful:

$ gdb -p 1415
(gdb) info proc
process 1415
cmdline = 'tmux'
cwd = '/home/pi'
exe = '/usr/bin/tmux'

I have since I initially asked the question rebooted my raspi, which this was running on, to see whether restarting tmux would re-acquire that file descriptor. Now the tmux process, which has a new PID, does no longer have /mnt/PIHDD in /proc/{pid}/fd.
That means I can not verify any given explanations. On the other hand, if somebody has the same issue and is able to restart tmux, give it a try!

It is possible that closing the file descriptor would have worked without issues. But I would still like a knowledgeable confirmation for that, and an explanation why tmux had that fd.


Irrelevant information that may help a future person in my shoes:

  • do not try attaching gdb to tmux from within tmux. If you do, open a new terminal/ssh-connection and do kill -9 for the pid of gdb which you get from ps -ax | grep gdb.
5
  • Related but I didn't get it to work: unix.stackexchange.com/a/309662/66736
    – lucidbrot
    Nov 9, 2019 at 9:35
  • have you tried changing the working dir of the session? :attach -c /some/dir . Might be worth checking. From: A of Q Nov 10, 2019 at 10:41
  • @AlexStragies If I understand correctly, this is about the default working dir, right? None of my sessions are currently cd'd into that drive and the default working dir is currently ~ which is also not on that drive. (pwd gives /home/pi)
    – lucidbrot
    Nov 10, 2019 at 18:12
  • Doing :attach -c /some/dir in just one session did not help. Would I need to do this in all of them?
    – lucidbrot
    Nov 10, 2019 at 18:16
  • @AlexStragies Please consider also my edited information. I don't know if that is helpful or a red herring though
    – lucidbrot
    Nov 10, 2019 at 18:35

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.