Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

systemd-240 fails to mount squashfs again, waiting for loop0 till timeout #11342

Closed
mgorny opened this issue Jan 6, 2019 · 2 comments
Closed

systemd-240 fails to mount squashfs again, waiting for loop0 till timeout #11342

mgorny opened this issue Jan 6, 2019 · 2 comments
Assignees
@keszybz
Labels
bug 🐛 Programming errors, that need preferential fixing pid1
Milestone
v241

Comments

@mgorny
Copy link
Contributor

mgorny commented Jan 6, 2019

systemd version the issue has been seen with

240 (this is a regression compared to 239)

Used distribution

Gentoo

Expected behaviour you didn't see

I have the following in fstab:

/home/mgorny/repos.ro.sqfs      /var/db/repos   squashfs        comment=systemd.automount       0 0

The filesystem is mounted on boot. After unmounting it, both auto-mounting and systemctl start var-db-repos.mount used to mount it again.

Unexpected behaviour you saw

After unmounting the filesystem once:

$ systemctl start var-db-repos.mount                                                                                        
A dependency job for var-db-repos.mount failed. See 'journalctl -xe' for details.
$ journalctl -xe
[...]
sty 06 10:10:11 pomiocik systemd[1]: dev-loop0.device: Job dev-loop0.device/start timed out.
sty 06 10:10:11 pomiocik systemd[1]: Timed out waiting for device /dev/loop0.
-- Subject: Unit dev-loop0.device has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit dev-loop0.device has failed.
-- 
-- The result is RESULT.
sty 06 10:10:11 pomiocik systemd[1]: Dependency failed for /var/db/repos.
-- Subject: Unit var-db-repos.mount has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit var-db-repos.mount has failed.
-- 
-- The result is RESULT.
sty 06 10:10:11 pomiocik systemd[1]: var-db-repos.mount: Job var-db-repos.mount/start failed with result 'dependency'.
sty 06 10:10:11 pomiocik systemd[1]: dev-loop0.device: Job dev-loop0.device/start failed with result 'timeout'.

Steps to reproduce the problem

  1. Get or make a squashfs.
  2. Add it to fstab as pasted above (with either automount or regular mount).
  3. Reboot.
  4. umount /my/squashfs
  5. systemctl start my-squashfs.mount
@bl33pbl0p
Copy link
Contributor

Is the loop module loaded (and does /dev/loop0 device node exist)?

@bl33pbl0p
Copy link
Contributor

bl33pbl0p commented Jan 6, 2019 •
edited

OK, thank you, I can reproduce this (We chatted a bit on IRC).

It looks like after the first mount, systemd polls for /proc/self/mountinfo and internally binds the mount unit to the loop device by updating What=. Then, any subsequent mount unit triggers will fail as a start job for device is enqueued (but the loop device can only be plugged in when something attaches image to it) so it fails each time with JOB_DEPENDENCY result.

A workaround is to do systemctl daemon-reload after every such umount, but yes, this looks like a bug.

In generated mount unit, What= is set to image file, but after PID1 updates it, it changes to /dev/loop0.

@poettering poettering added the bug 🐛 Programming errors, that need preferential fixing label Jan 6, 2019
@poettering poettering added this to the v241 milestone Jan 6, 2019
@poettering poettering added the pid1 label Jan 6, 2019
@keszybz keszybz self-assigned this Jan 17, 2019
keszybz added a commit to keszybz/systemd that referenced this issue Jan 17, 2019
@keszybz
pid1: fix cleanup of stale implicit deps based on /proc/self/mountinfo
24e0dfd 
The problem was introduced in a374220:
we have a unit which has a fragment, and when we'd update it based on
/proc/self/mountinfo, we'd say that e.g. What=/dev/loop8 has origin-fragment.
This commit changes two things:
- origin-fragment is changed to origin-mountinfo-implicit
- when we stop a unit, mountinfo information is flushed and all deps based
  on it are dropped.

The second step is important, because when we restart the unit, we want to
notice that we have "fresh" mountinfo information. We could keep the old info
around and solve this in a different way, but keeping stale information seems
inelegant.

Fixes systemd#11342.
@keszybz keszybz mentioned this issue Jan 17, 2019
Merged
keszybz added a commit to keszybz/systemd that referenced this issue Jan 18, 2019
@keszybz
pid1: fix cleanup of stale implicit deps based on /proc/self/mountinfo
2e6f1ab 
The problem was introduced in a374220:
we have a unit which has a fragment, and when we'd update it based on
/proc/self/mountinfo, we'd say that e.g. What=/dev/loop8 has origin-fragment.
This commit changes two things:
- origin-fragment is changed to origin-mountinfo-implicit
- when we stop a unit, mountinfo information is flushed and all deps based
  on it are dropped.

The second step is important, because when we restart the unit, we want to
notice that we have "fresh" mountinfo information. We could keep the old info
around and solve this in a different way, but keeping stale information seems
inelegant.

Fixes systemd#11342.
keszybz added a commit to keszybz/systemd that referenced this issue Jan 21, 2019
@keszybz
pid1: fix cleanup of stale implicit deps based on /proc/self/mountinfo
2deabd6 
The problem was introduced in a374220:
we have a unit which has a fragment, and when we'd update it based on
/proc/self/mountinfo, we'd say that e.g. What=/dev/loop8 has origin-fragment.
This commit changes two things:
- origin-fragment is changed to origin-mountinfo-implicit
- when we stop a unit, mountinfo information is flushed and all deps based
  on it are dropped.

The second step is important, because when we restart the unit, we want to
notice that we have "fresh" mountinfo information. We could keep the old info
around and solve this in a different way, but keeping stale information seems
inelegant.

Fixes systemd#11342.
keszybz added a commit to keszybz/systemd that referenced this issue Jan 26, 2019
@keszybz
pid1: fix cleanup of stale implicit deps based on /proc/self/mountinfo
c52c2dc 
The problem was introduced in a374220:
we have a unit which has a fragment, and when we'd update it based on
/proc/self/mountinfo, we'd say that e.g. What=/dev/loop8 has origin-fragment.
This commit changes two things:
- origin-fragment is changed to origin-mountinfo-implicit
- when we stop a unit, mountinfo information is flushed and all deps based
  on it are dropped.

The second step is important, because when we restart the unit, we want to
notice that we have "fresh" mountinfo information. We could keep the old info
around and solve this in a different way, but keeping stale information seems
inelegant.

Fixes systemd#11342.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@keszybz keszybz

Labels
bug 🐛 Programming errors, that need preferential fixing pid1
Milestone
v241
Development

No branches or pull requests
4 participants
@mgorny @keszybz @poettering @bl33pbl0p