On 12/10/16 13:48, Craig Sanders via luv-main wrote:
On Wed, Oct 12, 2016 at 10:42:03AM +1100, Allan Duncan wrote:
On my todo list. It happens when I boot after failing to alter fstab to match the actual disks connected.
it seems to happen at the slightest excuse, whether the machine ends up booting or not. just what everyone needs, one or more 90 second delays during the boot process.
maximising downtime by putting long delays in the way of whoever's trying to fix the problem is not a good idea.
is this delay configurable to something more reasonable, like 30 or 15 or even 5 seconds? can it be disabled?
can i at least have a --stop-wasting-my-fucking-time option?
(that would be more useful than their deprecated --kill-my-kernel-please, aka --debug)
yep. can you even access journald logs if you're booted up with a rescue disk?
Good question - went and looked: systemctl -b -1 will pull up the log from the boot before the rescue boot.
--list-boots will give you the history in the database.
neither of those work. that would be because they're journalctl options, not systemctl.
Indeed - I am always mixing the two.
also, the default for the Storage setting in /etc/systemd/journald.conf (at least in debian) is "auto", so no persistent storage of journal unless you manually create /var/log/journal (which, of course, you wouldn't do until *after* you realise you need to and only after you've figured out what needs to be done. bad default)
Fedora has it commented out, so I guess that means the default is "persistent" 'cause I have them waaay back. After some online searching I have found the fstab options nofail and x-systemd.device-timeout= given in the systemd.mount man page. Another tidbit: https://gryzli.info/2016/06/18/systemd-systemctl-list-unit-files-timeouts/ [refers to https://github.com/systemd/systemd/issues/1961 ]