systemd-tmpfiles-setup.service is not running after reboot #1581
Comments
That's odd. That service should always run on boot. Can you dump out the service contents? Here is what I see on a fresh instance (booted on AWS):
|
Hi, Here is the error from my system(but does not happen each time)
regards f0 |
That is really weird. Are you using coreos-cloudinit? If so, can you share your config? |
@crawford yes we use coreos-cloudinit, i need to clean up the config a bit , and then i can share |
@crawford here is the file (it is a cleaned up version, so maybe the syntax is broken) |
The reason this happens sporadically is because you are using coreos-cloudinit to start |
@crawford ok i check what i can provide... |
I don't recommend using |
@crawford ok here is the svg from systemd-analyze |
Do you have the logs? You provided a snippet of the full output earlier. That analyze graph doesn't show dependencies. |
@crawford i have only this in the logs for systemd-tmpfiles-setup.service
|
@crawford any hints where i can find more logs? in the mantime i have modified the cloud-init to only enable the systemd services , and i plan to migrate to ignition. I only need a solution for the runtime changes..... |
@crawford hit again by this error, this time with sysvinit.target
|
@crawford maybe this is a multipath dependency problem i found this |
@crawford when i disable the multipathd, the problem goes away, but then i have no datastore..... |
@crawford with the patch from https://www.redhat.com/archives/dm-devel/2015-March/msg00101.html its fixed, no dependency cycle and a working multipath :-) |
@crawford ping |
@f0 sorry for the delay. Since that patch works, it means that cloud-init is not at fault and using Ignition would always trigger the error. We'll have to go ahead and pull that fix into our units. Thank you so much for tracking this down. |
We'll upgrade the multipath-tools package to upstream's 0.6.2, which includes the unit dependency fixes. |
Issue Report
Bug
systemd-tmpfiles-setup.service is not running after reboot, thus causing fleet to not start with the following error.
CoreOS Version
Environment
Google Cloud Platform
Expected Behavior
sudo fleetctl list-machines
works as expected.Actual Behavior
sudo systemctl status systemd-tmpfiles-setup.service
sudo fleetctl list-machines
does not work as thefleet.service
has not started due to permissions.Reproduction Steps
sudo fleetctl list-units
(works).sudo fleetctl list-units
(no longer works).sudo journalctl -fu fleet
orsudo systemctl status fleet
Other Information
Sometimes on reboot, things will come back up. But this is maybe 1/5 times. Manually running
sudo systemctl start systemd-tmpfiles-setup.service
resolves the issue on the host. But this is not sustainable.The text was updated successfully, but these errors were encountered: