[Bug 1943163] Re: systemd.mount constantly unmounts an in use drive!
JXT
1943163 at bugs.launchpad.net
Fri Sep 10 06:02:51 UTC 2021
** Description changed:
systemd.mount constantly unmounts an in use sshfs drive!
Sep 09 11:20:01 $HOSTNAME systemd[4613]: pathtomount.mount: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit UNIT has successfully entered the 'dead' state.
Sep 09 11:20:01 $HOSTNAME systemd[1]: pathtomount.mount: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit pathtomount.mount has successfully entered the 'dead' state.
Change my kernel and the issue *seems* to have subsided. Coincidence or
swapping kernels reconfigured whatever was causing the issue. Did not
change kernel expecting to fix this, just so happened after I did this
stopped happening. Judging by the time stamps (that 01 seconds)
something was misbehaving with cron.
This only seemed to affect the fuse mounts which correlates with other
reports elsewhere I found but no real fixes and me changing kernels and
rebuilding some things were just happenstance. i.e. magically fixed
yields no answers. I installed a snap app around the time it started
misbehaving but again could be pointless coincidence. I just noticed in
the logs snap was playing with mounts for sandboxing.
+
+ Just occurred to me that I think I've seen this before. When 20.04 came
+ out I updated my roommates laptop with it. It's old, just plays movies
+ off the network and the hard drive died so I just did an install to a
+ little flash drive. She'd be watching something and it would do that
+ little buffer stutter like you just yanked the drive out mid audio/video
+ playback and crash. Eventually I just moved the machine back to 18.04
+ because there was no rhyme or reason to why it was doing that. I spent a
+ month hunting thermal trip issues, power saving, you name it but not
+ systemd. I never found anything in the logs but I was looking for
+ power/thermal/shutdown stuff not something idiotic unmounting the
+ rootfs!
+
+ While I fear my angry bits are seen as trolling there is a distinct fall
+ off from 18.04. Every release past 19 has been riddled with massive
+ problems across several machines. Another friend I upgraded to 20.04,
+ couldn't print. Worked fine in 18.04. Found a solution after months of
+ printing from an 18.04 vm.
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: systemd 247.3-3ubuntu3.4
ProcVersionSignature: Ubuntu 5.11.0-34.36-generic 5.11.22
Uname: Linux 5.11.0-34-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu65.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: XFCE
Date: Thu Sep 9 10:05:11 2021
EcryptfsInUse: Yes
MachineType: Micro-Star International Co., Ltd MS-7C02
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-34-generic root=UUID=8e862394-d94b-4c1a-81be-8cef6143bedd ro quiet splash vt.handoff=7
SourcePackage: systemd
SystemdDelta:
[EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf
[EXTENDED] /usr/lib/systemd/system/systemd-localed.service → /usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf
[EXTENDED] /usr/lib/systemd/system/user at .service → /usr/lib/systemd/system/user at .service.d/timeout.conf
3 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/22/2021
dmi.bios.release: 5.17
dmi.bios.vendor: American Megatrends International, LLC.
dmi.bios.version: 1.H5
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: B450 TOMAHAWK (MS-7C02)
dmi.board.vendor: Micro-Star International Co., Ltd
dmi.board.version: 1.0
dmi.chassis.asset.tag: To be filled by O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Micro-Star International Co., Ltd
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr1.H5:bd04/22/2021:br5.17:svnMicro-StarInternationalCo.,Ltd:pnMS-7C02:pvr1.0:skuTobefilledbyO.E.M.:rvnMicro-StarInternationalCo.,Ltd:rnB450TOMAHAWK(MS-7C02):rvr1.0:cvnMicro-StarInternationalCo.,Ltd:ct3:cvr1.0:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: MS-7C02
dmi.product.sku: To be filled by O.E.M.
dmi.product.version: 1.0
dmi.sys.vendor: Micro-Star International Co., Ltd
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1943163
Title:
systemd.mount constantly unmounts an in use drive!
Status in systemd package in Ubuntu:
New
Bug description:
systemd.mount constantly unmounts an in use sshfs drive!
Sep 09 11:20:01 $HOSTNAME systemd[4613]: pathtomount.mount: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit UNIT has successfully entered the 'dead' state.
Sep 09 11:20:01 $HOSTNAME systemd[1]: pathtomount.mount: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit pathtomount.mount has successfully entered the 'dead' state.
Change my kernel and the issue *seems* to have subsided. Coincidence
or swapping kernels reconfigured whatever was causing the issue. Did
not change kernel expecting to fix this, just so happened after I did
this stopped happening. Judging by the time stamps (that 01 seconds)
something was misbehaving with cron.
This only seemed to affect the fuse mounts which correlates with other
reports elsewhere I found but no real fixes and me changing kernels
and rebuilding some things were just happenstance. i.e. magically
fixed yields no answers. I installed a snap app around the time it
started misbehaving but again could be pointless coincidence. I just
noticed in the logs snap was playing with mounts for sandboxing.
Just occurred to me that I think I've seen this before. When 20.04
came out I updated my roommates laptop with it. It's old, just plays
movies off the network and the hard drive died so I just did an
install to a little flash drive. She'd be watching something and it
would do that little buffer stutter like you just yanked the drive out
mid audio/video playback and crash. Eventually I just moved the
machine back to 18.04 because there was no rhyme or reason to why it
was doing that. I spent a month hunting thermal trip issues, power
saving, you name it but not systemd. I never found anything in the
logs but I was looking for power/thermal/shutdown stuff not something
idiotic unmounting the rootfs!
While I fear my angry bits are seen as trolling there is a distinct
fall off from 18.04. Every release past 19 has been riddled with
massive problems across several machines. Another friend I upgraded to
20.04, couldn't print. Worked fine in 18.04. Found a solution after
months of printing from an 18.04 vm.
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: systemd 247.3-3ubuntu3.4
ProcVersionSignature: Ubuntu 5.11.0-34.36-generic 5.11.22
Uname: Linux 5.11.0-34-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu65.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: XFCE
Date: Thu Sep 9 10:05:11 2021
EcryptfsInUse: Yes
MachineType: Micro-Star International Co., Ltd MS-7C02
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-34-generic root=UUID=8e862394-d94b-4c1a-81be-8cef6143bedd ro quiet splash vt.handoff=7
SourcePackage: systemd
SystemdDelta:
[EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf
[EXTENDED] /usr/lib/systemd/system/systemd-localed.service → /usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf
[EXTENDED] /usr/lib/systemd/system/user at .service → /usr/lib/systemd/system/user at .service.d/timeout.conf
3 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/22/2021
dmi.bios.release: 5.17
dmi.bios.vendor: American Megatrends International, LLC.
dmi.bios.version: 1.H5
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: B450 TOMAHAWK (MS-7C02)
dmi.board.vendor: Micro-Star International Co., Ltd
dmi.board.version: 1.0
dmi.chassis.asset.tag: To be filled by O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Micro-Star International Co., Ltd
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr1.H5:bd04/22/2021:br5.17:svnMicro-StarInternationalCo.,Ltd:pnMS-7C02:pvr1.0:skuTobefilledbyO.E.M.:rvnMicro-StarInternationalCo.,Ltd:rnB450TOMAHAWK(MS-7C02):rvr1.0:cvnMicro-StarInternationalCo.,Ltd:ct3:cvr1.0:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: MS-7C02
dmi.product.sku: To be filled by O.E.M.
dmi.product.version: 1.0
dmi.sys.vendor: Micro-Star International Co., Ltd
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1943163/+subscriptions
More information about the foundations-bugs
mailing list