Bug#798965: systemd: Unit mnt.mount entered failed state

[Frank Heckenbach]

Package: systemd
Version: 215-17+deb8u2
Severity: important

The following happened to me, as far as I can recollect after the fact:

- While booting I had an entry in /etc/fstab like
  /dev/sdc1 /mnt ... noauto

- Later, I changed the entry to "/dev/sdb1 ..." and mounted it manually.

- Later again, I plugged in a completely unrelated disk, which was
  detected as /dev/sdc, and partitioned it (I did not mount
  anything).

- Suddenly I found /mnt unmounted.

- This was mostly reproducible (i.e. mount /mnt; partition /dev/sdc,
  /mnt is umounted).

- The only hint I found was this small entry in syslog:

  Sep 14 12:40:25 base systemd[1]: Unit mnt.mount entered failed state.

- To get details, I did:

  systemctl status mnt.mount
  * mnt.mount - /mnt
    Loaded: loaded (/etc/fstab)
    Active: failed (Result: exit-code) since Mon 2015-09-14 12:42:08 CEST; 636ms ago
     Where: /mnt
      What: /dev/sdc1
      Docs: man:fstab(5)
            man:systemd-fstab-generator(8)
   Process: 2186 ExecUnmount=/bin/umount -n /mnt (code=exited, status=0/SUCCESS)

   Sep 14 12:42:08 pax systemd[1]: Unit mnt.mount entered failed state.

- So there's the error here: It thinks /mnt had mounted /dev/sdc1
  rather than /dev/sdb1 (which it really did, and which mount
  confirmed -- and it couldn't possibly have been /dev/sdc1 anyway,
  since I'd just been creating the partition).

- The only connection to /dev/sdc1 I could remember was the old
  entry in /etc/fstab. I verified that I had really changed it, so
  something was obviously using stale information.

- Remembering what little I know about systemd, I did
  "systemctl daemon-reload", and indeed this seemed to fix the
  problem.

I claim this is a bug because what I did had nothing to do with
systemd (from a user's perspective).

It's OK when systemd requires a reload when one edits systemd's
configuration. It might be acceptable when editing e.g. legacy
scripts under /etc/init.d for which systemd claims to be a
replacement.

But it's not OK to require extra steps when just using plain old
Unix commands and configuration (/etc/fstab, mount, creating
partitions).

If systemd must interfere with mounts at all, it must do so
transparently, i.e. in this case, catch changes to /etc/fstab by
itself or recheck it automatically when acting on it.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  acl             2.2.52-2
ii  adduser         3.113+nmu3
ii  initscripts     2.88dsf-59
ii  libacl1         2.2.52-2
ii  libaudit1       1:2.4-1+b1
ii  libblkid1       2.25.2-6
ii  libc6           2.19-18+deb8u1
ii  libcap2         1:2.24-8
ii  libcap2-bin     1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20     1.6.3-2
ii  libkmod2        18-3
ii  liblzma5        5.1.1alpha+20120614-2+b3
ii  libpam0g        1.1.8-3.1
ii  libselinux1     2.3-2
ii  libsystemd0     215-17+deb8u2
ii  mount           2.25.2-6
ii  sysv-rc         2.88dsf-59
ii  udev            215-17+deb8u2
ii  util-linux      2.25.2-6

Versions of packages systemd recommends:
ii  dbus            1.8.20-0+deb8u1
ii  libpam-systemd  215-17+deb8u2

Versions of packages systemd suggests:
pn  systemd-ui  <none>

-- no debconf information