This repository has been archived by the owner on Jan 4, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 41
cluster fails to start when running with systemd >= v240 #339
Labels
Comments
https://github.com/systemd/systemd/blob/401faa3533280b05fee972e0c64885caf4b31e4c/units/var-lib-machines.mount#L10 this might be the reason why it's not spawning. When I try to spawn it on Ubuntu 19.04 with systemd version 240. I get this error:
I'm testing current workaround now: diff --git a/pkg/bootstrap/node.go b/pkg/bootstrap/node.go
index 890e974..9272b7e 100644
--- a/pkg/bootstrap/node.go
+++ b/pkg/bootstrap/node.go
@@ -39,7 +39,7 @@ const (
ctHashsizeValue string = "131072"
ctMaxSysctl string = "/proc/sys/net/nf_conntrack_max"
machinesDir string = "/var/lib/machines"
- machinesImage string = "/var/lib/machines.raw"
+ machinesImage string = "/var/lib/machines/flatcar.raw"
baseImageStableVersion string = "1478.0.0"
) |
invidian
added a commit
to invidian/kube-spawn
that referenced
this issue
May 24, 2019
Systemd prior to version 240 was creating /var/lib/machines.raw as btrfs volume for storing machined disks. However, this functionality is now remove and now it stores it as regular files. More details here: https://github.com/systemd/systemd/blob/401faa3533280b05fee972e0c64885caf4b31e4c/units/var-lib-machines.mount#L10 Additionally, it someone already have /var/lib/machines baked by btrfs, machined won't create machines.raw, which will also cause setting up cluster to fail. This patch adds check, if machineImage exists and it not, it fallbacks to just checking disk space available for /var/lib/machines. Closes kinvolk#339 kinvolk#293 Signed-off-by: Mateusz Gozdek <[email protected]>
invidian
added a commit
to invidian/kube-spawn
that referenced
this issue
May 27, 2019
Systemd prior to version 240 was creating /var/lib/machines.raw as btrfs volume for storing machined disks. However, this functionality is now remove and now it stores it as regular files. More details here: https://github.com/systemd/systemd/blob/401faa3533280b05fee972e0c64885caf4b31e4c/units/var-lib-machines.mount#L10 Additionally, it someone already have /var/lib/machines baked by btrfs, machined won't create machines.raw, which will also cause setting up cluster to fail. This patch adds check, if machineImage exists and it not, it fallbacks to just checking disk space available for /var/lib/machines. Refs kinvolk#339 kinvolk#293 Signed-off-by: Mateusz Gozdek <[email protected]>
invidian
added a commit
to invidian/kube-spawn
that referenced
this issue
May 27, 2019
Systemd prior to version 240 was creating /var/lib/machines.raw as btrfs volume for storing machined disks. However, this functionality is now remove and now it stores it as regular files. More details here: https://github.com/systemd/systemd/blob/401faa3533280b05fee972e0c64885caf4b31e4c/units/var-lib-machines.mount#L10 Additionally, it someone already have /var/lib/machines baked by btrfs, machined won't create machines.raw, which will also cause setting up cluster to fail. This patch adds check, if machineImage exists and it not, it fallbacks to just checking disk space available for /var/lib/machines. Refs kinvolk#339 kinvolk#293 Signed-off-by: Mateusz Gozdek <[email protected]>
invidian
added a commit
to invidian/kube-spawn
that referenced
this issue
May 27, 2019
Systemd prior to version 240 was creating /var/lib/machines.raw as btrfs volume for storing machined disks. However, this functionality is now remove and now it stores it as regular files. More details here: https://github.com/systemd/systemd/blob/401faa3533280b05fee972e0c64885caf4b31e4c/units/var-lib-machines.mount#L10 Additionally, it someone already have /var/lib/machines baked by btrfs, machined won't create machines.raw, which will also cause setting up cluster to fail. This patch adds check, if machineImage exists and it not, it fallbacks to just checking disk space available for /var/lib/machines. Refs kinvolk#339 kinvolk#293 Signed-off-by: Mateusz Gozdek <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When trying to test kube-spawn with systemd v240 or newer, it does not start the whole cluster.
Only one of the nodes becomes active, and only the node gets registered to systemd-machined. Actually all of the nodes should be active. Which node becomes active seems to be pretty random. Sometimes the master is active, sometimes one of the workers is active. In some cases, every node becomes inactive.
On the other hand, when running with systemd v239, everything works fine.
I have not managed to track down its reason. Probably git-bisect between v239 and v240 is needed.
The text was updated successfully, but these errors were encountered: