07.03.2016 22:23, Greg Freemyer пишет:
On Mon, Mar 7, 2016 at 1:49 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
07.03.2016 21:41, Greg Freemyer пишет:
The destination does not exist (it used to).
But ignoring that rather big issue, why does a failed mount of a tertiary filesystem cause systemd to crash and burn.
Because all mount points in /etc/fstab are mandatory unless marked as optional. There is nothing new - countless number of times I had to "fix" server that stayed in "rescue mode" because someone removed access to SAN storage but forgot to edit fstab. Without any systemd involved.
Andrei,
Would a bugzilla asking for a more descriptive error log be accepted?
That is something for upstream. See below.
All I got was this one liner:
Mar 06 19:14:51 cloud1 mount[1633]: mount: /srv_new/portal_backup_container: failed to setup loop device: No such file or directory
It would be nice to see something like:
"THE ABOVE FAILED MOUNT TRIGGERED SYSTEMD MAINTENANCE MODE:"
Instead, the one liner was lost in a clutter of hundreds of lines of output in the journal.
In fact I started with 500 lines of Journal logs that occurred near the failure. I whittled that down to these before I found the issue, but nothing in the below jumps out at me as a "MAJOR PROBLEM, MUST FIX BEFORE COMPUTER IS USABLE" type of log entry. In fact nothing in the logs even says systemd maintenance mode is being entered.
================ Mar 06 19:10:59 cloud1 clamd[1489]: SelfCheck: Database status OK. Mar 06 19:14:10 cloud1 sudo[1620]: gaf : TTY=pts/0 ; PWD=/home/gaf ; USER=root ; COMMAND=/usr/bin/vi /usr/lib/systemd/system/systemd-udev-root-symlink.service Mar 06 19:14:51 cloud1 systemd[1]: Cannot add dependency job for unit systemd-udev-root-symlink.service, ignoring: Unit systemd-udev-root-symlink.service failed to load: Invalid argument. See system logs and 'systemctl status systemd-udev-root-symlink.service' for details. Mar 06 19:14:51 cloud1 mount[1633]: mount: /srv_new/portal_backup_container: failed to setup loop device: No such file or directory Mar 06 19:14:51 cloud1 systemd[1]: Failed to mount /home/portal_backup/portal_backup. Mar 06 19:14:51 cloud1 systemd[1]: Dependency failed for Local File Systems.
Every now and then request to provide information, *what* dependencies failed, appears on systemd list/tracker. Apparently it is not entirely trivial and I'm not sure if anyone offered at least prototype implementation. But as I mentioned in another reply, I do not see how you can get so far in the first place. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org