deb-systemd-invoke.
Run commands with systemd's execution environment
SYNOPSIS
deb-systemd-invoke [ACTION] [UNIT_NAME...]
deb-systemd-invoke tmpfiles [UNIT_NAME...]
deb-systemd-invoke udev-trigger
PARAMETERS
ACTION
Represents a systemctl command to execute against specified units. Common actions include start, stop, restart, try-restart, reload, reload-or-restart, daemon-reload, enable, disable, mask, unmask, preset, revert, and set-property.
UNIT_NAME...
One or more systemd unit names (e.g., my-service.service, my-socket.socket) or unit file paths that the specified ACTION should apply to. For the tmpfiles action, this can refer to specific temporary file configuration names if needed.
tmpfiles
A dedicated action to manage temporary files and directories as defined by systemd-tmpfiles configuration files. This invokes systemd-tmpfiles --create --remove --boot and other relevant arguments safely.
udev-trigger
A dedicated action to trigger udev events. This is typically used after installing or upgrading packages that include new hardware rules or drivers, invoking commands like udevadm trigger.
DESCRIPTION
deb-systemd-invoke is a utility specific to Debian and Ubuntu-based systems, designed to be used primarily within package maintainer scripts (e.g., postinst, prerm, postrm). Its main purpose is to safely and conditionally interact with systemd components like systemctl and systemd-tmpfiles.
It acts as an intelligent wrapper, ensuring that systemd commands are only executed if systemd is the active init system and the environment is suitable for the action (e.g., not during a chroot, or if a service is already stopped or enabled as desired). This approach prevents errors and ensures packages behave correctly across various system states, including upgrades, installations, removals, and even in environments where systemd might not be fully running or isn't the primary init system. The command handles various unit types (services, sockets, timers, paths) and also provides specific actions for temporary files management and udev triggering, making it a critical component for seamless package operations on Debian derivatives.
CAVEATS
This command is specific to Debian and Ubuntu Linux distributions and is primarily intended for use by package maintainer scripts. It is not generally meant for interactive user use. Its functionality is conditional on systemd being the active init system, though it is designed to gracefully handle environments where systemd is not fully operational or present, preventing errors in such contexts.
ROLE IN MAINTAINER SCRIPTS
deb-systemd-invoke is frequently called from package maintainer scripts such as postinst (post-installation), prerm (pre-removal), and postrm (post-removal). For example, a postinst script might use deb-systemd-invoke restart my-service.service after an upgrade to restart a service, while a prerm script might use deb-systemd-invoke stop my-service.service before package removal. It intelligently determines if the service should be acted upon based on the installation state, active init system, and whether the service is already running or enabled.
CONDITIONAL EXECUTION LOGIC
A key feature of deb-systemd-invoke is its robust conditional execution logic. Before calling systemctl or systemd-tmpfiles, it performs checks to ensure the action is appropriate for the current environment. These checks include:
1. Confirming systemd is the active init system.
2. Verifying the environment is a fully operational system (e.g., not a chroot, installer environment, or container that doesn't run systemd).
3. Determining if the unit is enabled, active, or genuinely needs the requested action.
This intelligent behavior prevents errors in non-systemd setups or during partial system operations, significantly enhancing the reliability of Debian packages.
HISTORY
deb-systemd-invoke was developed as a crucial part of Debian's integration of systemd as the default init system. Its creation addressed the complex challenge of transitioning existing package maintainer scripts, which traditionally interacted with SysVinit, to work reliably and robustly with systemd. It provides an abstraction layer that ensures packages can correctly start, stop, enable, or disable services, and manage temporary files, in both live systemd environments and during packaging operations like chroots or upgrades where systemd might not be fully active or even present.
SEE ALSO
systemctl(1), systemd-tmpfiles(8), udevadm(8), dpkg(1), apt(8)