☰

¿El archivo override.conf cambia el archivo de servicio real conf?

tag-icon • tag-icon systemd configuration services
¿El archivo override.conf cambia el archivo de servicio real conf?

Creé un override.confarchivo systemd-journal-catalog-update.servicey lo coloqué en systemd-journal-catalog-update.service.d/el directorio. El propósito es eliminar systemd-tmpfiles-setup.servicedelsystemd-journal-catalog-update.service file.

El archivo tiene esto ahora:

[Unit]
After=local-fs.target systemd-tmpfiles-setup.service

Mi override.confarchivo tiene esto:

[Unit]
After=
After=local-fs.target

Sin embargo, el systemd-journal-catalog-update.servicearchivo no parece estar cambiando. ¿Estoy entendiendo mal cómo override.conffunciona el archivo? Sé que puedo modificar manualmente el archivo de servicio original, pero las circunstancias del proyecto limitan esta opción. Cualquier ayuda/consejo que puedan darnos será muy apreciado.

Respuesta1

Lo que desea (eliminar una dependencia de la unidad a través de un archivo desplegable) no es posible, según elunidad.systemdpágina de manual:

Las dependencias (Después de =, etc.) no se pueden restablecer a una lista vacía, por lo que las dependencias solo se pueden agregar en elementos desplegables. Si desea eliminar dependencias, debe anular toda la unidad.

Se puede anular un archivo de unidad completo siguiendo el Ejemplo dos en la página de manual:

Hay dos métodos para anular la configuración del proveedor en archivos unitarios: copiar el archivo unitario de /usr/lib/systemd/system a /etc/systemd/system y modificar la configuración elegida. [...] La ventaja del primer método es que se anula fácilmente la unidad completa, la unidad del proveedor ya no se analiza en absoluto. Tiene la desventaja de que las mejoras al archivo unitario realizadas por el proveedor no se incorporan automáticamente en las actualizaciones.

En tu caso, debes (como root)

  • cp /usr/lib/systemd/system/systemd-journal-catalog-update.service /etc/systemd/system
  • systemctl daemon-reload
  • systemctl restart systemd-journal-catalog-update

Después de eso, systemctl statusapuntará al archivo de servicio en /etc:

# systemctl status systemd-journal-catalog-update
● systemd-journal-catalog-update.service - Rebuild Journal Catalog
     Loaded: loaded (/etc/systemd/system/systemd-journal-catalog-update.service; static)
     Active: active (exited) since Sat 2021-05-22 16:27:07 CEST; 3 weeks 2 days ago
[...]

Lo anterior systemctl cattampoco mostrará el archivo en /etc/:

# systemctl cat systemd-journal-catalog-update
# /etc/systemd/system/systemd-journal-catalog-update.service
#  SPDX-License-Identifier: LGPL-2.1-or-later
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Rebuild Journal Catalog
[...]

Ahora puede editar el archivo /etccomo desee, ejecutarlo systemctl daemon-reloadnuevamente y systemctl restart systemd-journal-catalog-updateejecutar el servicio con su archivo de unidad personalizado y su configuración.

Tenga en cuenta lo siguiente mencionado en la página de manual:

Tiene la desventaja de que las mejoras al archivo unitario realizadas por el proveedor no se incorporan automáticamente en las actualizaciones.

Dado que systemd ahora lee un archivo de unidad completamente diferente del que está en el paquete systemd de su distribución, debe aplicar manualmente cualquier actualización del archivo /usr/liba su propia copia. .rpmnew(de distribuciones basadas en RPM) o .pacnew(de distribuciones basadas en pacman) archivos que generalmente se generan si un archivo de configuración rastreado por el administrador de paquetes ha sido modificado por el administrador local y el paquete no se generará en este caso.

información relacionada