14 votos

¿Cómo paso banderas al iniciar un servicio systemd?

Tenga en cuenta que se ha formulado una pregunta similar:
¿Cómo pasar banderas al iniciar el servicio?
Pero leí hace un tiempo que Linux cambió de init.d a systemd, y dado que esa pregunta y respuesta tienen 6 años, pensé que podría referirse a init.d

Mi pregunta es:
¿Cómo se pasan banderas/argumentos al iniciar un servicio de systemd? Por ejemplo, si hago systemctl restart Kubelet, eso significa que tengo el servicio Kubelet en ejecución, ¿cómo podría ver y modificar qué banderas/argumentos se pasan a ese servicio? (como --anonymous-auth=false)

También aquí hay un poco de contexto:
Estoy cerca de programar mi examen de certificación de Kubernetes de CNCF, el examen se basa en el rendimiento y cubre algunos detalles complicados que generalmente se abstraen de un Administrador de clúster.

Algo que aprendí es que hay 7 binarios principales que componen Kubernetes: [docker, etcd, kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy y kubelet]

Algunos de estos binarios del plano de control de Kubernetes son "auto alojados"/se ejecutan como pods en Kubernetes, y se pasan argumentos/banderas como --service-cluster-ip-range=10.0.0.0/16

La siguiente URL tiene un ejemplo de algunos binarios principales que se ejecutan como contenedores Docker en Kubernetes, y las banderas se pasan como argumentos en la especificación YAML. https://kubernetes.io/docs/setup/scratch/#scheduler-pod-template

Otros binarios principales de Kubernetes como Kubelet y Docker no son adecuados para el auto alojamiento y en su lugar se ejecutan como Demonios del Sistema Linux, y se ejecutan usando systemd y se gestionan con systemctl y journalctl. De todos modos, he tenido que iniciar sesión en un nodo y hacer systemctl restart docker.service y systemctl restart kubelet.service antes, pero en realidad no sé cómo ver o modificar qué banderas/argumentos se les pasan.

17voto

George Puntos 628

Desde aquí se puede hacer lo siguiente:

  1. Crea un archivo de argumentos llamado /etc/.argconf

    ARG1=-o
    ARG2=--verbose
  2. Y tu archivo .service:

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

Otro método de esa misma publicación es el siguiente:

[Unit]
Description=Prueba de pasar múltiples argumentos

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

Y el nombre del archivo debe ser myservice@.service toma nota del @ ya que es necesario al pasar argumentos de esta manera a un servicio. Luego ejecutas ese servicio de la siguiente manera:

sudo systemctl start myservice@"arg1 arg2 arg3".service

4voto

Kevin from MBioEX Puntos 146

TL;DR

When we run systemctl start .service systemd really executes /lib/systemd/system/.service

Esto puede ser útil para otros novatos como yo.

Vamos a ejecutar un servicio y revisar el estado (si falla o tiene éxito):

systemctl start .service 
systemctl status .service

Encontrarás esta línea en la salida del estado:

/lib/systemd/system/.service

Ese es el archivo que systemd ejecuta. Si sigues esa ruta y lo abres usando Vim, es la estructura mostrada por la respuesta aceptada.


En cuanto a dónde colocar los archivos, no puedo dar una opinión, pero al menos sabemos qué archivo está leyendo systemd.

2voto

neokyle Puntos 153

Al igual que cada implementación/sabor/distribución de Linux es un poco diferente.
Aprendí que cada implementación de Kubernetes es un poco diferente.
Y que hay diferentes maneras de implementar systemd.

Con toda esa variabilidad, creo que la mejor manera de hacer esto parece ser:
Utilizar el comando find para encontrar dónde está ubicado *.service

WorkerNodeBash# find / -name "*.service" | grep -i "kube"
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

(Lo anterior proviene de la implementación de Kubernetes the hard way, también he hecho kubeadm y miré en este mismo archivo y no vi ningún argumento, pero gracias a aprender cómo usar el comando find pude buscar:
WorkerNodeBash# find / -type f -name "*.yaml" | grep "kube"
Y encontré un archivo de configuración que mencionaba KUBELET_EXTRA_ARGS=, y los pasé ahí.

2voto

Paul Olson Puntos 11

Mientras que systemd ejecuta el archivo encontrado en:

/lib/systemd/system/.service

si buscas en /etc/systemd/system encontrarás un archivo .service que es un enlace de vuelta al archivo en /lib/systemd/system.

Esto te permite eliminar el archivo de /etc/systemd/system pero todavía tener el archivo en /lib/systemd/system para poder agregarlo de nuevo si es necesario.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X