Your message dated Mon, 14 Sep 2015 17:28:14 +0200
with message-id <[email protected]>
and subject line Re: Bug#798965: systemd: Unit mnt.mount entered failed state
has caused the Debian Bug report #798965,
regarding systemd: Unit mnt.mount entered failed state
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
798965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798965
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Am 14.09.2015 um 16:26 schrieb Frank Heckenbach:
> - Remembering what little I know about systemd, I did
> "systemctl daemon-reload", and indeed this seemed to fix the
> problem.
Correct, you need to run daemon-reload after changes to /etc/fstab.
Using inotify on configuration files was rejected upstream since you
don't know, when the config files are in a consistent state.
Thus closing the bug report.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
