Set SYSTEMD_IGNORE_CHROOT=yes

[rayandas]

Related issue: rancher/rancher#41601

As systemd installed in the latest hyperkube-base, when the user is trying to start a systemd service, it's running within a chroot environment, hence the "start" command is being ignored. Refer to the below error:

# systemctl start rpc-statd.service
Running in chroot, ignoring command ‘start’

This PR adds an env variable SYSTEMD_IGNORE_CHROOT and set it to yes so that it ignores the chroot environment.

[superseb]

Can you include how it was tested and/or if the linked issue was reproduced and solved?

[rayandas]

@superseb I couldn't reproduce the issue but after going through the comments on the issue it's certain that if systemctl start rpc-statd.service is giving this error Running in chroot, ignoring command ‘start’, which means it's running within a chroot environment. So any systemctl command will give the same chroot error. And that is why the script in /usr/sbin/start-statd is failing. As we can't modify the script, I added ENV SYSTEMD_IGNORE_CHROOT=yes to the Dockerfile. So it instructs systemd to ignore the chroot environment when running systemd commands.

So I built hyperkube-base using this env and updated hyperkube and KDM, then provisioned an RKE1 cluster, ssh-ed into the node and exec into kubectl container, ran a systemctl command, it's running successfully and not giving the chroot error.

So now the script in /usr/sbin/start-statd will runn successfully and if systemd is present, it'll not stop rpc.statd or its dependencies. And if systemd is not present then it'll run the rpc.statd manually using exec rpc.statd --no-notify as mentioned on the script.

[jiaqiluo]

According to the systemd docs, the proper value to use is 1, can you change it to 1 and also validate it works?

[rayandas]

Sure

[jiaqiluo]

Hi, @rayandas. Can you confirm if the fix works after changing the value to 1?
I will approve the PR once I hear your confirmation.

[rayandas]

Closing on behalf of #20