Как передать флаги при запуске службы systemd?

Обратите внимание, что аналогичный вопрос был задан:
Как передать флаги при запуске "сервиса"?
Но я прочитал некоторое время назад, что Linux переключился с init.d на systemd, и с тех пор, как этому Q&A исполнилось 6 лет, я подумал, что это может относиться к init.d

Мой вопрос:
Как вы передаете флаги / аргументы при запуске службы systemd? Допустим, я перезагружаю systemctl Kubelet, это означает, что у меня запущена служба Kubelet, ну как я могу увидеть и изменить флаги / аргументы, передаваемые этой службе? (Например, --anonymous-auth=false)

Также вот немного контекста:
Я близок к планированию моего сертификационного экзамена CNCF Kubernetes, экзамен основан на производительности и охватывает некоторые мелочи, которые обычно отвлекаются от администратора кластера.

Что я узнал, так это то, что есть 7 основных двоичных файлов, которые составляют Kubernetes: [docker, etcd, kube-apiserver, kube-controller-manager, kube-планировщик, kube-proxy и kubelet]

Некоторые из этих двоичных файлов плоскости управления Kubernetes "размещаются самостоятельно"/ выполняются как модули в Kubernetes, и вы передаете аргументы / флаги, например --service-cluster-ip-range=10.0.0.0/16

Следующий URL-адрес содержит пример некоторых основных двоичных файлов, выполняемых как контейнеры Docker в Kubernetes, и флаги, передаваемые как аргументы в спецификации YAML. https://kubernetes.io/docs/setup/scratch/

Другие основные бинарные файлы Kubernetes, такие как Kubelet и Docker, не очень подходят для самостоятельного хостинга и вместо этого работают как демоны системы Linux, и они работают с использованием systemd и управляются с помощью systemctl и journalctl. В любом случае мне приходилось входить в систему узла и выполнять systemctl restart docker.service и systemctl restart kubelet.service раньше, но я не знаю, как посмотреть или изменить какие флаги / аргументы им передаются.

Источник

4 ответа

Решение

Отсюда это можно сделать так:

  1. Создайте файл аргументов, скажем /etc/.argconf

    ARG1=-o
ARG2=--verbose

  2. И ваш файл.service:

    EnvironmentFile=/etc/.progconf
ExecStart = /usr/bin/prog $ARG1 $ARG2

Другой метод из того же поста, как показано ниже:

[Unit]
Description=Test passing multiple arguments

[Service]
Environment="SCRIPT_ARGS=%I"
ExecStart=/tmp/test.py $SCRIPT_ARGS

И имя файла должно быть myseervice@.service принять к сведению @ поскольку это требуется при передаче аргументов таким способом в службу. Затем вы запускаете этот сервис так:

sudo systemctl start myseervic@"arg1 arg2 arg3".service
Источник

TL;DR

Когда мы бежим systemctl start <name>.service systemd действительно выполняет/lib/systemd/system/<name>.service

Это может быть полезно для других новичков вроде меня.

Запустим сервис и проверим статус (неудачно или успешно):

systemctl start <name>.service 
systemctl status <name>.service

Вы найдете эту строку на выходе для статуса:

/lib/systemd/system/<name>.service

Это файловая система, которую выполняет. Если вы пойдете по этому пути и откроете с помощью Vim, это будет структура, показанная принятым ответом.

Что касается того, где разместить файлы, я не могу высказать своего мнения, но, по крайней мере, мы знаем, какую файловую систему читает.

Источник

Точно так же, как каждая реализация / вкус / распространение Linux немного отличается.
Я узнал, что каждая реализация Kuberntes немного отличается.
И что есть разные способы реализации systemd.

При всей этой изменчивости я считаю, что лучший способ сделать это, по-видимому:
Чтобы использовать команду find, чтобы найти, где находится *.service

WorkerNodeBash# find / -name "*.service" | grep -i "кубе"
WorkerNodeBash # nano /etc/systemd/system/kubelet.service

[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/kubernetes/kubernetes
After=containerd.service
Requires=containerd.service

[Service]
ExecStart=/usr/local/bin/kubelet \
  --config=/var/lib/kubelet/kubelet-config.yaml \
  --container-runtime=remote \
  --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock \
  --image-pull-progress-deadline=2m \
  --kubeconfig=/var/lib/kubelet/kubeconfig \
  --network-plugin=cni \
  --register-node=true \
  --pod-manifest-path=/etc/kubernetes/manifests \
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

(Вышеизложенное исходит от Kubernetes для реализации сложного способа, я также выполнил kubeadm, посмотрел в этом же файле и не увидел аргументов, но благодаря изучению использования команды find я смог выполнить поиск:
WorkerNodeBash # find / -type f -name "*.yaml" | греп "кубе"
И я нашел файл конфигурации, в котором упоминалось KUBELET_EXTRA_ARGS=, и передал их туда.

Источник

В то время как systemd выполняет файл, найденный в:

/lib/systemd/system/<name>.service

если вы посмотрите, вы найдете файл <name>.serviceэто ссылка на файл в формате .

Это значит, что вы можете удалить файл из /etc/systemd/systemно все еще есть файл в /lib/systemd/systemчтобы позволить вам добавить его обратно, если или когда это необходимо.

Источник
Другие вопросы по тегам