-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misleading default value in --etcd-snapshot-dir opt descriptions (server
, etcd-snapshot
)
#11570
Comments
Suffixing |
Merged to master, will backport in February cycle. |
$ k3s -v
$ sudo ls /var/lib/rancher/k3s/server/db/
$ k3s server --help | grep '-dir'
🟢 Validated $ k3s -v
$ sudo ls /var/lib/rancher/k3s/server/db/
$ k3s server --help | grep '-dir'
$ k3s -v
$ sudo ls /var/lib/rancher/k3s/server/db/
$ k3s server --help | grep '-dir'
🟢 Validated $ k3s -v
$ sudo ls /var/lib/rancher/k3s/server/db/
$ k3s server --help | grep '-dir'
$ k3s -v
$ sudo ls /var/lib/rancher/k3s/server/db/
$ k3s server --help | grep '-dir'
🟢 Validated $ k3s -v
$ sudo ls /var/lib/rancher/k3s/server/db/
$ k3s server --help | grep '-dir'
$ k3s -v
$ sudo ls /var/lib/rancher/k3s/server/db/
$ k3s server --help | grep '-dir'
🟢 Validated $ k3s -v
$ sudo ls /var/lib/rancher/k3s/server/db/
$ k3s server --help | grep '-dir'
|
Environmental Info:
K3s Version:
Node(s) CPU architecture, OS, and Version:
Cluster Configuration:
Single node cluster (server+agent) - in my opinion not that relevant within the context of this report.
Describe the bug:
The default
--etcd-snapshot-dir
value reported by theserver
andetcd-snapshot
K3S CLI command--help
dialogues does not match the effective path created and used in runtime.Take a look at the
--help
output for both commands:Assuming
--etcd-snapshot-dir
is not provided, the effective path is actually${data-dir}/server/db/snapshots
, instead of${data-dir}/db/snapshots
(note the missingserver
path segment).Steps To Reproduce:
To preface this section, I've initially observed this issue on a different system, running NixOS. The K3s service was installed and managed via the k3s nixpkg, obviously adding a layer of abstraction between the K3s distributables and the end user. To rule out the potential configuration skew, I've reproduced this on Arch via AUR, whose install process I understand better.
Install
v1.31.4+k3s1
Add a minimal working example etcd snapshot configuration to the systemd service
k3s server
invocation. Just enough to enable etcd (instead of SQLite) and get a snapshot created quickly, without flooding the storage:/usr/bin/k3s server --cluster-init --etcd-snapshot-schedule-cron="* * * * *" --etcd-snapshot-retention=1
Ensure service is enabled and reload daemons to get the above configuration running:
Manually trigger an etcd snapshot via
k3s etcd-snapshot
Wait a minute, for the next etcd snapshot cron schedule tick.
Note
The service is running as root, and therefore the effective default
--data-dir
directory is/var/lib/rancher/k3s
.Expected behavior:
The snapshots are saved under
/var/lib/rancher/k3s/db/snapshots
, since this is whatk3s server --help
told me.Actual behavior:
The snapshots are saved under
/var/lib/rancher/k3s/server/db/snapshots
:Additional context / logs:
I've looked in the sources, and the effective data dir appears to be resolved here, on server startup:
k3s/pkg/server/server.go
Lines 466 to 486 in a562d09
k3s/pkg/server/server.go
Lines 40 to 42 in a562d09
The above applies to both the
server
andetcd-snapshot
commands, since to my understanding, the snapshots invoked manually byetcd-snapshot save
send aPOST /db/snapshot
to the server, which in turn calculates the snapshot write path, using theDataDir
config value resolved on startup.Full systemd unit file
The text was updated successfully, but these errors were encountered: