如果我理解OP，他试图在容器内运行systemctl *。这是行不通的，因为systemd一开始就不在容器内运行。它不能在无特权的容器内完成。在SO中还有另一个关于why he should not run systemd within a container的问题。
我很快在谷歌上搜索到了2014年关于using systemd within a container in docker的页面，上面有一个简短的解释。修复方法是使用特权容器（运行docker run --privileged ...），这可能是一个坏主意，但可能适合OP。有一个2019年的update of that last article，底线是他们开发了自己的容器引擎（所以没有docker）。
显而易见的解决方案是拥有一个服务，因此不需要systemd，尽管在OP的情况下这可能是不可能的。
总之，可能的解决方案：

• 不使用systemd
• 使用特权容器
• 不要使用Docker

在您的终端中，您可以键入：

$ sudo dockerd

神奇的是
所以，打开其他终端并尝试它

$ docker ps -a

如果权限仍有问题，请运行：

$ sudo usermod -aG docker your-user

您需要通过此命令启动容器以启用systemd。

docker run -itd --privileged docker pull ubuntu:18.04 /usr/sbin/init

您是否尝试使用：而不是systemd？
我有一个类似的问题，它解决了它。

在我自己摆弄了Systemd并撞上了这个之后，我在Docker中找到了一个很好的解决方案来解决这个问题。
您可以设置cronjob，使其在容器重新引导时运行。
Dockerfile.yml：

COPY startup.sh /home/$USERNAME
WORKDIR /home/$USERNAME
RUN chmod +x startup.sh
RUN runuser -u $USERNAME -- echo "@reboot /home/$USERNAME/startup.sh" >> cronjobs
RUN runuser -u $USERNAME -- crontab cronjobs
RUN runuser -u $USERNAME -- rm cronjobs

https://askubuntu.com/questions/814/how-to-run-scripts-on-start-up#816

您可能忘记在使用Docker之前启动它

sudo service docker start