vaultlocker: /var/lib/nova/instances fails to mount at boot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Nova Compute Charm |
New
|
Undecided
|
Unassigned |
Bug Description
$ journalctl -xe -u var-lib-
-- Reboot --
Jan 11 16:09:25 ps5-ra1-n5 systemd[1]: Dependency failed for /var/lib/
-- Subject: A start job for unit var-lib-
-- Defined-By: systemd
-- Support: http://
--
-- A start job for unit var-lib-
--
-- The job identifier is 29 and the job result is dependency.
Jan 11 16:09:25 ps5-ra1-n5 systemd[1]: var-lib-
$ journalctl -xe -u vaultlocker-
-- Reboot --
Jan 11 16:10:00 ps5-ra1-n5 systemd[1]: Starting vaultlocker retrieve: 6da89b4b-
-- Subject: A start job for unit vaultlocker-
-- Defined-By: systemd
-- Support: http://
--
-- A start job for unit vaultlocker-
--
-- The job identifier is 30.
Jan 11 16:10:00 ps5-ra1-n5 sh[4071]: DEBUG:urllib3.
Jan 11 16:10:10 ps5-ra1-n5 sh[4071]: DEBUG:urllib3.
Jan 11 16:10:10 ps5-ra1-n5 sh[4071]: INFO:vaultlocke
Jan 11 16:10:10 ps5-ra1-n5 sh[4071]: DEBUG:urllib3.
Jan 11 16:10:10 ps5-ra1-n5 sh[4071]: INFO:vaultlocke
Jan 11 16:10:16 ps5-ra1-n5 systemd[1]: vaultlocker-
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: http://
--
-- The unit vaultlocker-
Jan 11 16:10:16 ps5-ra1-n5 systemd[1]: Finished vaultlocker retrieve: 6da89b4b-
-- Subject: A start job for unit vaultlocker-
-- Defined-By: systemd
-- Support: http://
--
-- A start job for unit vaultlocker-
--
-- The job identifier is 30.
Made an attempt at adding a timeout and retry to the fstab entry, but that did not appear to have any effect.
Could this be a pure ordering issue that happens on this system for some reason?
The `vaultlocker- decrypt@ .service` is running after networking, and that might be at odds with when systemd schedules the fstab compat/auto entries.
Creating systemd mount files directly on recent systems instead of relying on the fstab compat thing could be an approach to get more control of ordering.