Bug 388360 - SystemD auto-mount of (squashfs) filesystem causes mount/unmount loop
Summary: SystemD auto-mount of (squashfs) filesystem causes mount/unmount loop
Status: REPORTED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on: 319998 369434
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-30 14:34 UTC by Marco Leise
Modified: 2024-07-09 13:15 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Leise 2017-12-30 14:34:30 UTC
I have an /usr/local/lib/systemd/system/usr-repos.automount containing the following lines:
·✂··································
[Unit]
Description=Mounts the Portage tree

[Install]
WantedBy=local-fs.target

[Automount]
Where=/usr/repos
TimeoutIdleSec=10
·✂··································
accompanied by an /etc/fstab line:
/usr/repos.sfs	/usr/repos	squashfs	noauto,noatime	0 0

Now whenever I browse to /usr using the "Details" view in Dolphin, /usr/repos gets mounted to calculate and display the number of elements inside. The "Loop Device" shows up in the places panel. So far so good. But when the 10 seconds run out and the filesystem gets unmounted by SystemD, the places entry is left behind. Then, immediately after the unmount, the filesystem gets mounted again creating another "Loop Device" entry. This process repeats a few times creating several dummy "Loop Device" displaying as unmounted. (Zombie "Loop Device" entries have been reported as 369434 and 319998.)

- Restarting Dolphin cleans up the places panel.
- The steps above reproduce the issue for me, but the mount/unmount loop can be triggered by other programs besides Dolphin AFAICT.

In the terminal output of krunner the mount/unmount can be followed as UDisks2 messages:
"/org/freedesktop/UDisks2/block_devices/loop0" lost interfaces: ("org.freedesktop.UDisks2.Filesystem")
"/org/freedesktop/UDisks2/block_devices/loop0" lost interfaces: ("org.freedesktop.UDisks2.Filesystem")
"/org/freedesktop/UDisks2/block_devices/loop0" has new interfaces: ("org.freedesktop.UDisks2.Filesystem")
"/org/freedesktop/UDisks2/block_devices/loop0" has new interfaces: ("org.freedesktop.UDisks2.Filesystem")
QFileInfo::absolutePath: Constructed with empty filename

Ideally, if some part of KDE still accesses the filesystem, the auto-unmount timer should be reset and the loop device kept mounted, instead of triggering a mount _right_ after the unmount.
Comment 1 Marco Leise 2017-12-30 15:03:30 UTC
Likely related: Okteta seemingly "hangs" right now. In GDB, I can see that
  KFilePlacesModel::Private::_k_itemChanged(QString const&) ()
is taking several seconds to complete and is called again and again...

The relevant snippet of the stack looks like this (sorry, no debug info for now):
#12 0x00000035cec6d70e in KFilePlacesModel::Private::_k_itemChanged(QString const&) () from /usr/lib64/libKF5KIOFileWidgets.so.5
#13 0x00000035cec7417d in ?? () from /usr/lib64/libKF5KIOFileWidgets.so.5
#14 0x00000035c7fded38 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQt5Core.so.5
#15 0x00000035cec63a48 in ?? () from /usr/lib64/libKF5KIOFileWidgets.so.5
#16 0x00000035cec63b3c in ?? () from /usr/lib64/libKF5KIOFileWidgets.so.5
#17 0x00000035c7fded38 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQt5Core.so.5
#18 0x00000035ce86e6c4 in Solid::StorageAccess::accessibilityChanged(bool, QString const&) () from /usr/lib64/libKF5Solid.so.5

QMetaObject::activate() in frame #17 is taking _very_ long to complete or hangs entirely.