deviceUnmount /dev/sdb6
Unmounting /dev/sdb6 (/media/sparc/BIGEXT4)
sudo udisksctl unmount -b /dev/sdb6
Unmounting /dev/sdb6 (/media/sparc/BIGEXT4) : udisksctl [FAIL] (1)
sudo umount /dev/sdb6
umount [FAIL] (32)
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
lsof: WARNING: can't stat() fuse file system /run/user/1000/doc
Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
gitstatus 26459 sparc mem REG 8,22 9739105 24391994 /media/sparc/BIGEXT4/apibkup/.git/objects/pack/pack-272899373ef0a5a893d156491b001f18da841353.pack
gitstatus 26459 sparc mem REG 8,22 257636 24391993 /media/sparc/BIGEXT4/apibkup/.git/objects/pack/pack-272899373ef0a5a893d156491b001f18da841353.idx
gitstatus 26459 sparc 4r REG 8,22 9739105 24391994 /media/sparc/BIGEXT4/apibkup/.git/objects/pack/pack-272899373ef0a5a893d156491b001f18da841353.pack
By default, gitstatusd keeps Git repositories open for one hour. There is a flag in gitstatusd to change this value but it's not exposed through p10k parameters. There are a few things that can be done:
/media/sparc/BIGEXT4/apibkup/... as its current directory less than one hour ago, you'll be able to unmount. For example, if your current shell is the one, type exec zsh. If you restart all interactive zsh shells, this will also work.If neither 1 nor 2 work for you, I can also add a parameter to p10k that you can use to change the default from 1h to something lower. (It's unlikely to be necessary; option (1) is most likely doable and not too much hassle.)
Closing due to the lack of activity. Please reopen if you are still affected by this issue.
I'm finding that gitstatusd periodically prevents unmounting of volumes that don't even have a git repo on them. If I have several terminal windows open, it's sometimes a bit hard to find which is preventing unmounting, and in other cases I've moved on and I'm using the terminal for another task, and would prefer not to exit it.
Would it be possible to expose the parameter to lower the default timeout?
I'm finding that gitstatusd periodically prevents unmounting of volumes that don't even have a git repo on them.
This is surprising. Can you debug this on your side? Try to find a way to reproduce this issue and figure out which files/directories are being held open by gitstatusd.
Would it be possible to expose the parameter to lower the default timeout?
Yes, although it won't help given what you've written above. This parameter only affects for how long git repos are held open.
This is surprising. Can you debug this on your side?
Hmm, I actually can't seem to reproduce this intentionally now! For reference, it's happened 2–3 times in the past. I mounted my ebook reader, messed around with Calibre and sqlite, and it wouldn't unmount until I exited the terminal. I'll keep an eye on it, and gather more data next time it happens.
I'll keep an eye on it, and gather more data next time it happens.
Sounds good. When it happens again, get a list of open files together with processes that hold file descriptors to them.
Okay, I think I can reproduce this reliably now.
1) Mount a volume
2) In the first terminal, cd to this volume
3) Open a second terminal window/tab/pane in the same directory (I use terminator, which automatically opens the same directory)
4) Close the first terminal
5) In the second terminal, cd away from the volume
6) Attempt to unmount, which fails because gitstatus has a file open!
Only when I close the second terminal can I unmount the volume. N.B. there are no git repos on any of the working directories involved.
Hopefully you can reproduce this, otherwise I'm happy to provide more information.
- Attempt to unmount, which fails because
gitstatushas a file open!
Which file?
The actual directory itself. e.g. if at 2, cd /run/media/protist/foo, then at 6:
$ lsof | grep /run/media/protist
zsh 289998 protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290028 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290029 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290030 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290031 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290032 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290033 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290034 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290035 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290036 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290037 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290038 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290039 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290040 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290041 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290042 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290043 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290044 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290045 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290046 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290047 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290048 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290049 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290050 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
gitstatus 290027 290051 gitstatus protist cwd DIR 8,49 4096 2 /run/media/protist/foo
Thanks! Fixed.
Brilliant! Thanks for the quick fix @romkatv. I tested master and can confirm that this is no longer an issue.
Thanks for the confirmation, @protist !