Replace confusing systemd log

[manuelbuil]

Some versions of network manager have a bug in the component nm-cloud-setup.service and that's why we check if it exists when starting k3s and fail to start k3s if it does:

k3s/install.sh

Line 907 in 6aef26e

ExecStartPre=/bin/sh -xc '! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service'

If if does not exist, we see in the logs:

Failed to get unit file state for nm-cloud-setup.service: No such file or directory

which is fine but it confuses a lot of users that believe that is the source of their problems.

We should find a better log to avoid that confusion

[brandond]

I guess we could just redirect output of that command to /dev/null?

[manuelbuil]

I guess we could just redirect output of that command to /dev/null?

Yes, that could be a good idea. Assuming the log will still be there if nm-cloud-setup.service exists

[brandond]

We use the --quiet flag, which gives no output if it exists. Unfortunately it does not suppress the error if it doesn't exist.

[rancher-max]

Validated using latest install script

• On a system that doesn't have these services:

$ journalctl -eu k3s -f
Feb 15 21:29:34 ip-172-31-40-199 sh[1907]: + /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service
Feb 15 21:29:34 ip-172-31-40-199 systemd[1]: Starting Lightweight Kubernetes...

• On a system that does (and that should fail):

$ journalctl -eu k3s -f
Feb 15 21:30:12 ip-172-31-17-27.us-east-2.compute.internal systemd[1]: Starting Lightweight Kubernetes...
Feb 15 21:30:12 ip-172-31-17-27.us-east-2.compute.internal sh[16306]: + /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service
Feb 15 21:30:12 ip-172-31-17-27.us-east-2.compute.internal systemd[1]: k3s.service: Control process exited, code=exited, status=1/FAILURE
Feb 15 21:30:12 ip-172-31-17-27.us-east-2.compute.internal systemd[1]: k3s.service: Failed with result 'exit-code'.
Feb 15 21:30:12 ip-172-31-17-27.us-east-2.compute.internal systemd[1]: Failed to start Lightweight Kubernetes.