| Summary: | SystemD auto-mount of (squashfs) filesystem causes mount/unmount loop | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Marco Leise <Marco.Leise> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | john.kizer, kde, kdelibs-bugs, lukas, simonandric5 |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | 319998, 369434 | ||
| Bug Blocks: | |||
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. Thank you for the bug report. Unfortunately we were not able to get to it yet. Can we ask you to please check if this is still an issue with the current versions of Plasma (6.2) and Frameworks (6.8)? (In reply to John Kizer from comment #2) > Thank you for the bug report. Unfortunately we were not able to get to it > yet. Can we ask you to please check if this is still an issue with the > current versions of Plasma (6.2) and Frameworks (6.8)? 7 years later, the laptop I was using still exists, but ever since I replaced the HDD with an SSD, I stopped compressing the many small files of the Portage tree into a Squash FS. The machine also developed CPU instabilities under load (from compiling so many Gentoo packages most likely) and a hinge broke out of the display frame. In other words, it is e-waste now. While I do have a virtual machine with Gentoo, it has no KDE or auto-mount set up and I've been using Windows 10 for the last years, so am wholly out of the loop (no pun intended). I apologize, but I don't want to invest the time on this bug and would find it acceptable if you closed it as not reproducible or similar. (In reply to Marco Leise from comment #3) > wholly out of the loop (no pun intended). I apologize, but I don't want to > invest the time on this bug and would find it acceptable if you closed it as > not reproducible or similar. Thanks for your understanding - and the pun might be unintentional, but it is a good one and is an appreciated smile! |
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.