systemctl-reenable

Re-enable a unit, restoring its default symlinks

$ systemctl reenable [unit]

$ systemctl reenable [unit1 unit2 ...]

$ systemctl reenable [unit] --now

systemctl-reenable [OPTIONS] UNIT...

UNIT...
    The name(s) of one or more systemd unit(s) (e.g., a service, socket, or timer) to be re-enabled.

--user
    If this script passes arguments through, this flag would instruct the underlying systemctl commands to operate on the user's private instance of the service manager, rather than the system-wide instance.

--now
    If this script passes arguments through, this flag would instruct the underlying systemctl commands to immediately stop the unit during the disable phase and start it after the enable phase. This often results in a restart of the service.

systemctl-reenable is not a standard command provided by the Systemd project itself. Instead, it typically refers to a user-created script or alias that serves as a convenience wrapper for executing a sequence of standard systemctl commands.

Its primary purpose is to ensure that a Systemd unit's symlinks are correctly established or refreshed. This is achieved by first disabling the specified unit(s) and then immediately enabling them again. Conceptually, it performs:
systemctl disable --now <UNIT>
followed by
systemctl enable --now <UNIT>

This pattern is often used for troubleshooting when a unit fails to start due to corrupted or incorrect symlinks, or after manual modifications to unit files outside of the standard systemctl workflow. It ensures that Systemd's internal state and the filesystem symlinks in directories like /etc/systemd/system/*.wants/ or /usr/lib/systemd/system/*.wants/ are consistent and up-to-date for the specified service, socket, or timer unit.

systemctl-reenable is not a built-in Systemd command. Its existence and exact behavior depend entirely on whether a system administrator or distribution has created such a script or alias.

• Implementation Varies: If you find this command, always inspect its content (e.g., which systemctl-reenable then cat <path>) to understand precisely what it executes.
• Impact on Running Services: If the underlying implementation includes --now (which is common for this type of utility), the targeted unit will be stopped and restarted, potentially causing a brief interruption.
• Error Handling: A simple script might not have robust error handling for failed disable or enable operations.

systemctl-reenable does not have an official development history as part of the Systemd project. It emerged as a common pattern or a utility script created by users and system administrators to simplify the process of fixing systemd unit symlinks. Before this conceptual command, users would manually run systemctl disable --now <unit> followed by systemctl enable --now <unit>. The creation of such a wrapper script streamlines this two-step process, especially in automation or troubleshooting scenarios, by providing a single, memorable command.

systemctl(1), systemd.unit(5), systemd.service(5), systemd.socket(5), systemd.timer(5)