7.1.7.1.5. cobbler.modules.process_management package

7.1.7.1.5.1. Submodules

7.1.7.1.5.2. cobbler.modules.process_management.detection module

Low-level OS/environment detection helpers for process-management backend selection. Contains no restart logic – see process_management.service.restart_service() and process_management.docker.restart_service().

cobbler.modules.process_management.detection.is_containerized() → bool[source]

Return whether the current process is running inside a container.

Checks, in order: the presence of /.dockerenv, the container environment variable (set by systemd-nspawn and by docker/images/cobblerd/Dockerfile’s own base image conventions), and “docker”/”containerd” substrings in /proc/1/cgroup as a last resort (covers older cgroup v1 hosts). Any one signal being true suffices.

cobbler.modules.process_management.detection.is_service() → bool[source]

Return whether this system uses service.

This method currently checks if the path /usr/sbin/service exists.

cobbler.modules.process_management.detection.is_supervisord() → bool[source]

Return whether this system uses supervisord.

This method currently checks if there is a running supervisord instance on localhost.

cobbler.modules.process_management.detection.is_systemd() → bool[source]

Return whether this system uses systemd.

This method currently checks if the path /usr/lib/systemd/systemd exists.

7.1.7.1.5.3. cobbler.modules.process_management.docker module

Process management module that restarts a Docker container, chosen by a label, instead of a local process. This is useful when DHCP/DNS run as separate sidecar containers rather than inside the same process namespace as cobblerd.

exception cobbler.modules.process_management.docker.DockerException[source]

Bases: Exception

Placeholder used only when the optional docker SDK isn’t installed, so except DockerException below stays a valid exception handler (catching None would raise TypeError at runtime) instead of relying on an invariant static analysis can’t verify. Never actually raised: the early DOCKER_SDK_LOADED guard in restart_service() means this branch’s true fallback is never reached in practice.

cobbler.modules.process_management.docker.register() → str[source]

The mandatory Cobbler module registration hook.

Returns:

“process_management” if the optional docker Python package is available, else “”.

cobbler.modules.process_management.docker.restart_service(api_handle: CobblerAPI, service_name: str) → int[source]

Restart the Docker container labeled as responsible for service_name.

Exactly one container must be found carrying the label cobbler.io/managed-service=<value>, where <value> is looked up from the docker_service_labels setting (falling back to the raw service_name if it isn’t mapped). Zero matches or more than one match is treated as a hard error - never a silent no-op and never a restart of more than one container.

Parameters:

  • api_handle – The api instance to resolve settings.

  • service_name – The name of the service to restart (e.g. “dhcpd”, “named”, “dnsmasq”).

Returns:

0 on success, matching process_management.service.restart_service()’s convention. Any other value indicates failure.

7.1.7.1.5.4. cobbler.modules.process_management.service module

Default/backward-compatible process management module. Restarts services the way Cobbler always has: via supervisord, systemd or SysV. This is the module used when cobblerd and the managed services (DHCP, DNS, …) run in the same process namespace/host.

cobbler.modules.process_management.service.register() → str[source]

The mandatory Cobbler module registration hook.

Returns:

Always “process_management”

cobbler.modules.process_management.service.restart_service(api_handle: CobblerAPI, service_name: str) → int[source]

Restart a service via the traditional, non-containerized process managers (supervisord, systemd, SysV). Checks which manager is present is done in the order just described, delegating to process_management.supervisor/process_management.systemd for the first two so that behavior stays identical whether a manager is auto-detected here or selected explicitly via those modules.

Parameters:

  • api_handle – The api instance to resolve settings. Unused by this module, present to match the process_management module contract.

  • service_name – The name of the service to restart.

Returns:

0 on success. Any other value indicates failure.

7.1.7.1.5.5. cobbler.modules.process_management.supervisor module

Process management module that always restarts a service through supervisord’s XML-RPC API. Select this explicitly when you know the host manages services via supervisord and want to skip the supervisord/systemd/SysV auto-detection process_management.service performs.

cobbler.modules.process_management.supervisor.register() → str[source]

The mandatory Cobbler module registration hook.

Returns:

Always “process_management”

cobbler.modules.process_management.supervisor.restart_service(api_handle: CobblerAPI, service_name: str) → int[source]

Restart a service through supervisord’s XML-RPC API.

Parameters:

  • api_handle – The api instance to resolve settings. Unused by this module, present to match the process_management module contract.

  • service_name – The name of the service to restart.

Returns:

0 on success. Any other value indicates failure.

7.1.7.1.5.6. cobbler.modules.process_management.systemd module

Process management module that always restarts a service via systemd (systemctl restart). Select this explicitly when you know the host uses systemd and want to skip the supervisord/systemd/SysV auto-detection process_management.service performs.

cobbler.modules.process_management.systemd.register() → str[source]

The mandatory Cobbler module registration hook.

Returns:

Always “process_management”

cobbler.modules.process_management.systemd.restart_service(api_handle: CobblerAPI, service_name: str) → int[source]

Restart a service via systemctl restart.

Parameters:

  • api_handle – The api instance to resolve settings. Unused by this module, present to match the process_management module contract.

  • service_name – The name of the service to restart.

Returns:

0 on success. Any other value indicates failure.

7.1.7.1.5.7. Module contents

This module represents all Cobbler methods of restarting the daemons (DHCP, DNS, …) that Cobbler manages the configuration of. All present modules may be used through the configuration file settings.yaml, in the process_management section.

In the following the specification of a process management module is given:

  1. The module must define a register() -> str function taking no arguments. It must return "process_management" to be picked up as a member of this category, or "" if an optional dependency required by the module (e.g. the docker Python package) is not available.

  2. The module must define a restart_service(api_handle: "CobblerAPI", service_name: str) -> int function. It restarts the given service (for example "dhcpd", "named" or "dnsmasq") and returns 0 on success. Any other value indicates failure.

  3. Errors should result in a log message to the standard Python logger obtained via logging.getLogger() in addition to a non-zero return code.

The list of currently known process management modules is:

  • process_management.service

  • process_management.systemd

  • process_management.supervisor

  • process_management.docker

process_management.systemd/process_management.supervisor restart a service via systemd/supervisord directly, with no auto-detection - select one of these explicitly when you already know which process manager the host uses and want to skip the detection process_management.service performs (which delegates to these same two modules for those cases, falling back to a SysV service invocation, or an error, if neither is present).

modules.process_management.module also accepts the special value "auto", which is not a real module in this package - it is resolved by CobblerAPI.get_process_management_module() to process_management.docker or process_management.service depending on whether cobblerd is running inside a container (see process_management.detection.is_containerized()). An explicit process_management.service/ process_management.docker setting is never overridden by container detection - only "auto" is affected.