Bug 541402 – sys-apps/systemd-219 immediately unmounts manually mounted directories: Unit ….mount is bound to inactive unit. Stopping, too.

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Dennis Schridde 2015-02-26 10:07:05 UTC]

$ grep gentoo /etc/fstab
/var/cache/portage/gentoo.sqfs              /var/cache/portage/gentoo squashfs defaults,noatime,nodev,noexec,nosuid,noauto                         0 0
$ sudo mount -vvv /var/cache/portage/gentoo
mount: /dev/loop0 mounted on /var/cache/portage/gentoo.
$ mount | grep gentoo
<no output>

Meanwhile journald logs:
sudo[14328]: USER : TTY=pts/3 ; PWD=/home/USER ; USER=root ; COMMAND=/bin/mount -vvv /var/cache/portage/gentoo
sudo[14328]: pam_unix(sudo:session): session opened for user root by (uid=0)
sudo[14328]: pam_unix(sudo:session): session closed for user root
systemd[1]: Unit var-cache-portage-gentoo.mount is bound to inactive unit. Stopping, too.
systemd[1]: Unmounting /var/cache/portage/gentoo...
systemd[1]: Unmounted /var/cache/portage/gentoo.

It seems as if systemd would immediately unmount manually mounted directories.

I can however trick it to not do that, by mounting a tmpfs in the same location prior to mounting the squashfs:
$ sudo mount -t tmpfs none /var/cache/portage/gentoo
$ sudo mount /var/cache/portage/gentoo.sqfs /var/cache/portage/gentoo
$ mount | grep gentoo
none on /var/cache/portage/gentoo type tmpfs (rw,relatime)
/var/cache/portage/gentoo.sqfs on /var/cache/portage/gentoo type squashfs (ro,relatime)

journald logs:
sudo[17270]: USER : TTY=pts/3 ; PWD=/home/USER ; USER=root ; COMMAND=/bin/mount -t tmpfs none /var/cache/portage/gentoo
sudo[17270]: pam_unix(sudo:session): session opened for user root by (uid=0)
sudo[17270]: pam_unix(sudo:session): session closed for user root
sudo[17283]: USER : TTY=pts/3 ; PWD=/home/USER ; USER=root ; COMMAND=/bin/mount /var/cache/portage/gentoo.sqfs /var/cache/portage/gentoo
sudo[17283]: pam_unix(sudo:session): session opened for user root by (uid=0)
sudo[17283]: pam_unix(sudo:session): session closed for user root

[Comment 1 Martin Väth 2015-02-27 06:17:34 UTC]

The problem is that "mount" triggers systemd apparently to start an internal unit, see also:
https://forums.gentoo.org/viewtopic-t-998456-highlight-.html

It seems to me that these attempts of systemd to take full control over all calls of "mount" is conceptually broken: This is nothing an init-system should interfere, to start with.

[Comment 2 Martin Väth 2015-02-27 06:29:15 UTC]

BTW, the fact that the "workaround" works is due to another conceptual brokenness of systemd: That mount-units *must* be named after path, and so systemd shoots itself into the foot when two mounts occur for the same path - systemd is not able to distinguish them internally.
In other words: Its intentional breakage of user mounts breaks due to its own bugs.

[Comment 3 Dennis Schridde 2015-03-02 12:27:40 UTC]

From what I read this not only affects loop mounts. Changing summary.

[Comment 4 Mike Gilbert 2015-03-03 00:51:26 UTC]

I saw some chatter about this on systemd-devel; I think upstream is aware of the issue.

[Comment 5 Pacho Ramos 2015-03-28 08:43:22 UTC]

*** Bug 544704 has been marked as a duplicate of this bug. ***

[Comment 6 Druggo Yang 2015-03-30 12:38:38 UTC]

hit a bug of systemd : https://bugs.freedesktop.org/show_bug.cgi?id=89383

downgrade or and you can find a patch there:
https://abf.io/openmandriva/systemd/blob/master/0001-Revert-core-mount-add-dependencies-to-dynamically-mo.patch

[Comment 7 Chris Smith 2015-03-30 20:40:25 UTC]

(In reply to Druggo Yang from comment #6)
> hit a bug of systemd : https://bugs.freedesktop.org/show_bug.cgi?id=89383
> 
> downgrade or and you can find a patch there:
> https://abf.io/openmandriva/systemd/blob/master/0001-Revert-core-mount-add-
> dependencies-to-dynamically-mo.patch

Patch works fine.

Unfortunately I had to create a local ebuild as the systemd ebuild has no epatch_user entry.

[Comment 8 Mike Gilbert 2015-03-30 20:46:32 UTC]

(In reply to Chris Smith from comment #7)
> Unfortunately I had to create a local ebuild as the systemd ebuild has no
> epatch_user entry.

Sure it does: It calls autotools-utils_src_prepare, which in turn calls epatch_user.

[Comment 9 Chris Smith 2015-03-30 20:52:57 UTC]

(In reply to Mike Gilbert from comment #8)
> (In reply to Chris Smith from comment #7)
> > Unfortunately I had to create a local ebuild as the systemd ebuild has no
> > epatch_user entry.
> 
> Sure it does: It calls autotools-utils_src_prepare, which in turn calls
> epatch_user.

Just another refinement I missed. Thanks!

[Comment 10 Mike Gilbert 2015-04-17 19:12:29 UTC]

*** Bug 546900 has been marked as a duplicate of this bug. ***

[Comment 11 Mike Gilbert 2015-04-26 17:15:59 UTC]

Please give systemd-219_p112 a try.

+*systemd-219_p112 (26 Apr 2015)
+
+  26 Apr 2015; Mike Gilbert <[e-mail]> +systemd-219_p112.ebuild:
+  Add a snapshot from the v219-stable branch upstream.

[Comment 12 Juergen Rose 2015-05-06 19:31:45 UTC]

Mounting of loop devices works again.