* install.sh: test if BIN_DIR is readonly, else use /opt
On flatcar /usr is a readonly partition, while /opt is allowed for
writing.
Signed-off-by: Vincent Batts <vbatts@kinvolk.io>
* install.sh: only warn on Flatcar about selinux
This check is a bit more explicit, but only warn about finding the rpm
installed policy when on Flatcar Container Linux
Signed-off-by: Vincent Batts <vbatts@kinvolk.io>
* Update install.sh
Co-authored-by: Brad Davidson <brad@oatmail.org>
Signed-off-by: Vincent Batts <vbatts@kinvolk.io>
Co-authored-by: Brad Davidson <brad@oatmail.org>
It's a bad practice to install packages via rpm directly. It's better to install all packages with Yum/Dnf. It's also possible to install packages directly via an URL, which is the purpose of this PR.
Wants= is required to actually set the dependency on network-online.service
After= is required or k3s.service will be started at the same time as network-online.service
In network environments with slow DHCP, both are required to ensure valid network configuration for k3s
Signed-off-by: Adam Farden <adam@farden.cz>
Adds the line `After=network-online.target` to the k3s systemd service
file. This applies the fix mentioned in
[this GH comment](https://github.com/rancher/k3s/issues/1626#issuecomment-642253812)
which I can confirm makes k3s networking survive reboot in Raspbian
Buster.
[It appears, in some docs I found](https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files)
that this is a recommended and usual way of specifying that we need the
target to be _completed_ before starting k3s. Using just the `Wants=`
directive doesn't work for this task, you have to add both directives
at once to do this. Quote:
> `Wants=`: This directive is similar to `Requires=`, but less strict.
> `Systemd` will attempt to start any units listed here when this unit
> is activated. If these units are not found or fail to start, the
> current unit will continue to function. This is the recommended way to
> configure most dependency relationships. **Again, this implies a
> parallel activation unless modified by other directives**
> [...]
> `After=`: The units listed in this directive will be started before
> starting the current unit. This does not imply a dependency
> relationship and **one must be established through the above
> directives if this is required.**
- _(Emphasis mine)_
Signed-off-by: Matthew Clive <arcticlight@arcticlight.me>
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
This allows us to fail quickly if we're handed a schemeless or plain
HTTP URI, rather than having the agent barf when the systemd unit
starts. For an operator, this makes for a cleaner error up front and
clear messaging for how to fix the situation.
Signed-off-by: Josh McSavaney <mcsaucy@csh.rit.edu>
When for some reason, k3s crashes, and can't startup again, e.g. when
the data backend is not available (dqlite crashed, database server is
offline, ...), on openrc systems, supervise-daemon will try to restart
it, as per supervise-daemon(8):
respawn-max:
Sets the maximum number of times a daemon will be respawned during
a respawn period. If a daemon dies more than this number of times
during a respawn period, will give up trying to respawn it and exit.
The default is 10, and 0 means unlimited.
Setting respawn-max to 0, makes sure a k3s process on openrc systems will
keep trying to come online, even if the database backend is offline for a
longer period of time.
This aligns the openrc service configuration with the systemd
configuration, which has
Restart=always
RestartSec=5s
The option --no-deploy was deprecated by
0374c4f63d
and is now replaced in the install.sh documentation by --disable
Signed-off-by: omichaelis <38879457+oliviermichaelis@users.noreply.github.com>
When k3s is installed on an OS with default high ulimits, performance
issues can be observed. This was discovered on CoreOS where the default
value is 1073741816. Symptoms include very slow file operations such
as installing a Rook/Ceph cluster will take ~6 hours instead of ~10 minutes.
A google search for 'container LimitNOFILE' will show that most major
projects set this already, including the (unused) containerd systemd unit
found in this repository at /vendor/github.com/containerd/containerd/containerd.service
k3OS is not affected becuasse the default there is already 1048576.
See description in coreos/fedora-coreos-tracker#329
