Usb Debug

[frostschutz]

When the reader is connected to the computer, this hack will

- display a happy face if the Kobo umounted the filesystems properly.
- display a sad face if it's still mounted even though it should not be.

If you see a sad face, you might have filesystem corruption and/or still running processes doing the wrong thing.

While the USB is connected it will keep checking state for about 5 minutes, so if some process is slow to free resources you will see a sad face first and it turns into a happy face. (But if the filesystem was mounted/used while it was still a sad face, there might still be corruption).

A possible cause for the sad face will be stored in /tmp/UsbDebug.log

After making this I found a bug in one of my own mods

This is mainly to debug other mods that may behave incorrectly during a USB connection.

I should also point out that this is by no means a complete check. It only considers obvious mounts; processes with open files or PWD; and libraries linked in by running programs. It does not cover loop devices, bind mounts, and more obscure ways to keep the filesystem busy.

Update:

Added a umount hook so it detects whether non-lazy umount would have worked or not.

The debug info is now copied to .addons/usbdebug/

Hack can be uninstalled by creating .addons/usbdebug/uninstall

Update: now also resolves offending fd names

Update 20160918: fix for GloHD/KA1

[NiLuJe]

I can't remember: doesn't Kobo ship an lsof binary? That would be my tool of choice for this kind of checks .

[frostschutz]

If you want to use lsof you'd have to use it before the lazy umount. It doesn't work afterwards since all processes using a lazily umounted filesystem are locked into virtual paths that don't exist.

I guess I could hook into umount in addition to what it's currently doing, so it can do some things before it just umount -l

[NiLuJe]

@frostschutz: Hmm, good point .

[frostschutz]

I'll improve it, with a umount hook that tries regular umount before lazy umount. If regular umount fails we know it is busy somehow, so that's something to fall back to even if my other checks can not find all reasons as to why it is busy.

Unfortunately the kernel does not make it easy to track filesystems that it is still using in read-write mode but not bound to any real VFS path. lazy umount is really really bad idea

[frostschutz]

Updated it; it now puts the info in /mnt/onboard/.usbdebug/

and also can be uninstalled if you create /mnt/onboard/.usbdebug/uninstall

sample output

umount failure /mnt/onboard Thu Aug 6 23:41:31 CEST 2015

/proc/869/cwd 4096 8 41ed 0 0 b303 346 3 0 0 1438732800 1438794482 1438794482 4096

init(1)-+-adobehost-launc(832)---adobehost(833)---{QProcessManage}(844)
        |-autoshelf.sh(2455)-+-cat(2459)
        |                    `-dd(2460)
        |-dbus-daemon(524)
        |-dbus-daemon(523)
        |-fickel-launcher(917)---fickel(918)
        |-getty(529)
        |-hindenburg(525)
        |-inetd(531)
        |-nickel(526)-+-sh(2431)---usb(2432)---sleep(2453)
        |             |-{FifoHardwareSt}(815)
        |             |-{QEvdevTouchScr}(828)
        |             |-{QProcessManage}(813)
        |             |-{QThread}(824)
        |             |-{QThread}(825)
        |             |-{QThread}(829)
        |             |-{QThread}(830)
        |             |-{Qt HTTP thread}(925)
        |             |-{Qt bearer thre}(826)
        |             |-{nickel}(928)
        |             `-{nickel}(930)
        |-screensaver.sh(702)-+-grep(858)
        |                     |-logread(857)
        |                     `-screensaver.sh(860)
        |-sickel(879)
        |-swapper(208)
        |-syslogd(821)
        |-udevd(495)
        |-usbdebug.sh(2457)---pstree(2768)
        `-webportal.sh(717)---httpd(869)

so it failed to umount, due to process 869 (which blocks /mnt/onboard by using it as a current working directory [cwd] and in the pstree you can see 869 is httpd so the culprit in this case is my webportal mod (which I still have to fix)

[Lucas Malor]

It's more an educational tool, I guess

[frostschutz]

It's hard to debug such issues since everything seems like it should work — but then you get occasional data corruption or your mod stops working correctly after USB connection because suddenly its file handles are in data limbo…

Educational, certainly, for me anyway. I was not aware of the pitfalls of lazy umounting before. I've been using Linux for a long time but you still learn new things.

[frostschutz]

When connecting USB while reading KEPUB, nickel still has open file handles to the .kepub file at the time it umounts. It frees them a few seconds later... so this is a "sad face turns into happy face" case.

umount failure /mnt/onboard Wed Aug 12 16:45:10 UTC 2015
/proc/1315/fd/32 2831262 5536 81ed 0 0 b303 73 1 0 0 1439337600 1439394562 1439394563 4096
/proc/1316/fd/32 2831262 5536 81ed 0 0 b303 73 1 0 0 1439337600 1439394562 1439394563 4096
/proc/1337/fd/32 2831262 5536 81ed 0 0 b303 73 1 0 0 1439337600 1439394562 1439394563 4096
/proc/516/fd/32 2831262 5536 81ed 0 0 b303 73 1 0 0 1439337600 1439394562 1439394563 4096
lr-x------    1 root     root            64 Aug 12 16:45 /proc/1315/fd/32 -> /.kobo/kepub/816d01e8-6501-43ec-9985-3dd7bdc7c55b
lr-x------    1 root     root            64 Aug 12 16:45 /proc/1316/fd/32 -> /.kobo/kepub/816d01e8-6501-43ec-9985-3dd7bdc7c55b
lr-x------    1 root     root            64 Aug 12 16:45 /proc/1337/fd/32 -> /.kobo/kepub/816d01e8-6501-43ec-9985-3dd7bdc7c55b
lr-x------    1 root     root            64 Aug 12 16:45 /proc/516/fd/32 -> /.kobo/kepub/816d01e8-6501-43ec-9985-3dd7bdc7c55b
init(1)-+-dbus-daemon(514)
        |-dbus-daemon(513)
        |-fickel-launcher(866)---fickel(867)
        |-getty(519)
        |-hindenburg(515)
        |-nickel(516)-+-sh(1315)---usb(1316)---sleep(1337)
        |             |-{FifoHardwareSt}(788)
        |             |-{QEvdevTouchScr}(803)
        |             |-{QProcessManage}(786)
        |             |-{QThread}(799)
        |             |-{QThread}(800)
        |             |-{QThread}(804)
        |             |-{Qt HTTP thread}(874)
        |             |-{Qt bearer thre}(801)
        |             |-{Thread (pooled}(1291)
        |             |-{nickel}(1277)
        |             `-{nickel}(1278)
        |-sickel-launcher(797)---sickel(798)
        |-swapper(208)
        |-syslogd(795)
        |-udevd(491)
        `-usbdebug.sh(1339)---pstree(1579)

The paths say /.kobo/kepub/thingy because that's what lazy umount does, if it can't umount properly it bends /mnt/onboard/ into a virtual / that is still hooked to the read-write filesystem.

It's probably not a problem in practice, since nickel frees it in the end (and UsbDebug runs quite early, it caught nickel's usb script sleeping so it might be a second before it loaded the storage module.

[frostschutz]

Updated it to also work with GloHD/KA1 (same udev rule as my other mods).
Also moved .usbdebug to .addons/usbdebug.

I found a way to do a more reliable check (using inotify umount which is called only when it's really umounted, not for lazy umounting) but I'm too lazy to implement, there's probably no demand for it.