Skip to content
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

Fix server systemd detection #5851

Merged
merged 1 commit into from
Jul 21, 2022
Merged

Conversation

brandond
Copy link
Member

@brandond brandond commented Jul 13, 2022

Proposed Changes

  • Use INVOCATION_ID to detect execution under systemd, since as of a9b5a19 NOTIFY_SOCKET is now cleared by the server code.

    The invocation ID is passed to the activated processes as environment variable. It is additionally stored as extended attribute on the cgroup of the unit.

  • Set the unit type to notify by default for both server and agent, which is what Rancher-managed installs have done for a while.

Note that the systemd cgroup controller does NOT work with rootless due to the issue documented here:

Types of Changes

bugfix

Verification

See test steps at #5454 (comment)

Testing

Needs a test...

Linked Issues

User-Facing Change

Fixed a regression that caused systemd cgroup driver autoconfiguration to fail on server nodes.

Further Comments

I would have preferred to use SYSTEMD_EXEC_PID, but that wasn't added until v248-2 in March of 2021. INVOCATION_ID is more available, as it's been around since 232.

@brandond brandond requested a review from a team as a code owner July 13, 2022 00:08
* Use INVOCATION_ID to detect execution under systemd, since as of a9b5a19 NOTIFY_SOCKET is now cleared by the server code.
* Set the unit type to notify by default for both server and agent, which is what Rancher-managed installs have done for a while.

Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
@RedHawker
Copy link

RedHawker commented Jul 29, 2022

The change to install.sh broke our installation of 1.22.6+k3s1.
We didn't specify INSTALL_K3S_TYPE, so we got exec for the type, but now you default to notify.
The documentation for INSTALL_K3S_TYPE is now also incorrect at https://rancher.com/docs/k3s/latest/en/installation/install-options/
The documentation for INSTALL_K3S_TYPE is also no longer correct within the script itself.

@brandond

@brandond
Copy link
Member Author

brandond commented Jul 29, 2022

@RedHawker can you explain how this broke your system? All currently supported k3s releases should work with the notify type for both agent and server. It looks fine to me:

root@ubuntu01:~# curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.22.6+k3s1 sh -
[INFO]  Using v1.22.6+k3s1 as release
[INFO]  Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.22.6+k3s1/sha256sum-amd64.txt
[INFO]  Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.22.6+k3s1/k3s
[INFO]  Verifying binary download
[INFO]  Installing k3s to /usr/local/bin/k3s
[INFO]  Skipping installation of SELinux RPM
[INFO]  Creating /usr/local/bin/kubectl symlink to k3s
[INFO]  Creating /usr/local/bin/crictl symlink to k3s
[INFO]  Skipping /usr/local/bin/ctr symlink to k3s, command exists in PATH at /usr/bin/ctr
[INFO]  Creating killall script /usr/local/bin/k3s-killall.sh
[INFO]  Creating uninstall script /usr/local/bin/k3s-uninstall.sh
[INFO]  env: Creating environment file /etc/systemd/system/k3s.service.env
[INFO]  systemd: Creating service file /etc/systemd/system/k3s.service
[INFO]  systemd: Enabling k3s unit
Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.
[INFO]  systemd: Starting k3s
root@ubuntu01:~# systemctl status k3s
● k3s.service - Lightweight Kubernetes
     Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-07-29 20:27:44 UTC; 3min 32s ago
       Docs: https://k3s.io
    Process: 790729 ExecStartPre=/bin/sh -xc ! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service (code=exited, status=0/SUCCESS)
    Process: 790731 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)
    Process: 790732 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
   Main PID: 790733 (k3s-server)
      Tasks: 98
     Memory: 1.3G
        CPU: 37.956s
     CGroup: /system.slice/k3s.service

The documentation for INSTALL_K3S_TYPE is also no longer correct within the script itself.

#     Type of systemd service to create, will default from the k3s exec command
#     if not specified.

The comment is not incorrect. It does not say that the default is exec. It says that it "will default from the exec command" (the INSTALL_K3S_EXEC variable); but the default is now notify for both server and agent. I agree that it could be clarified.

If this continues to be an issue for you, please open a new issue. Commenting on the PR itself does not give us anything to work against.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants