<para><filename>os-release</filename> must not contain repeating keys. Nevertheless, readers should pick

the entries later in the file in case of repeats, similarly to how a shell sourcing the file would. A

reader may warn about repeating entries.</para>

the default system target started at boot — is commonly aliased to either

<literal>alias@bar.service</literal>) are not aliased. Those rules preserve the requirement that the

instance (if any) is always uniquely defined for a given unit and all its aliases. The target of alias

symlink must point to a valid unit file location, i.e. the symlink target name must match the symlink

source name as described, and the destination path must be in one of the unit search paths, see UNIT FILE

LOAD PATH section below for more details. Note that the target file may not exist, i.e. the symlink may

be dangling.</para>

<varname>Wants=</varname> and <varname>Requires=</varname>, see below. The preferred way to create

symlinks in the <filename>.wants/</filename> or <filename>.requires/</filename> directories is by

specifying the dependency in [Install] section of the target unit, and creating the symlink in the file

system with the <command>enable</command> or <command>preset</command> commands of

<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. The

target can be a normal unit (either plain or a specific instance of a template unit). In case when the

source unit is a template, the target can also be a template, in which case the instance will be

"propagated" to the target unit to form a valid unit instance. The target of symlinks in

<filename>.wants/</filename> or <filename>.requires/</filename> must thus point to a valid unit file

location, i.e. the symlink target name must satisfy the described requirements, and the destination path

must be in one of the unit search paths, see UNIT FILE LOAD PATH section below for more details. Note

that the target file may not exist, i.e. the symlink may be dangling.</para>

<para>Moreover, additional units might be loaded into systemd from directories not on the unit load path

by creating a symlink pointing to a unit file in the directories. You can use <command>systemctl

link</command> for this; see

<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. The file

system where the linked unit files are located must be accessible when systemd is started (e.g. anything

underneath <filename>/home/</filename> or <filename>/var/</filename> is not allowed, unless those

directories are located on the root file system).</para>

<para>It is important to distinguish "linked unit files" from "unit file aliases": any symlink where the

symlink <emphasis>target</emphasis> is within the unit load path becomes an alias: the source name and

the target file name must satisfy specific constraints listed above in the discussion of aliases, but the

symlink target doesn't have to exist, and in fact the symlink target path is not used, except to check

whether the target is within the unit load path. In constrast, a symlink which goes outside of the unit

load path signifies a linked unit file. The symlink is followed when loading the file, but the

destination name is otherwise unused (and may even not be a valid unit file name). For example, symlinks

<filename index='false'>/etc/systemd/system/alias1.service</filename> → <filename index='false'>service1.service</filename>,

<filename index='false'>/etc/systemd/system/alias2.service</filename> → <filename index='false'>/usr/lib/systemd/service1.service</filename>,

<filename index='false'>/etc/systemd/system/alias3.service</filename> → <filename index='false'>/etc/systemd/system/service1.service</filename>

are all valid aliases and <filename index='false'>service1.service</filename> will have

four names, even if the unit file is located at

<filename index='false'>/run/systemd/system/service1.service</filename>. In contrast,

a symlink <filename index='false'>/etc/systemd/system/link1.service</filename> → <filename index='false'>../link1_service_file</filename>

means that <filename index='false'>link1.service</filename> is a "linked unit" and the contents of

<filename index='false'>/etc/systemd/link1_service_file</filename> provide its configuration.</para>

<listitem><para>This option may be used more than once, or a space-separated list of unit names may

be given. A symbolic link is created in the <filename>.wants/</filename> or

<filename>.requires/</filename> directory of each of the listed units when this unit is installed by

<command>systemctl enable</command>. This has the effect of a dependency of type

<varname>Wants=</varname> or <varname>Requires=</varname> being added from the listed unit to the

current unit. The primary result is that the current unit will be started when the listed unit is

started, see the description of <varname>Wants=</varname> and <varname>Requires=</varname> in the

[Unit] section for details.</para>

<para>In case of template units listing non template units, the listing unit must have

<varname>DefaultInstance=</varname> set, or <command>systemctl enable</command> must be called with

an instance name. The instance (default or specified) will be added to the

<filename>.wants/</filename> or <filename>.requires/</filename> list of the listed unit. For example,

<command>WantedBy=getty.target</command> in a service <filename>getty@.service</filename> will result

in <command>systemctl enable getty@tty2.service</command> creating a

<filename>getty.target.wants/getty@tty2.service</filename> link to

<filename>getty@.service</filename>. This also applies to listing specific instances of templated

units: this specific instance will gain the dependency. A template unit may also list a template

unit, in which case a generic dependency will be added where each instance of the listing unit will

have a dependency on an instance of the listed template with the same instance value. For example,

<command>WantedBy=container@.target</command> in a service <filename>monitor@.service</filename> will

result in <command>systemctl enable monitor@.service</command> creating a

<filename>container@.target.wants/monitor@.service</filename> link to

<filename>monitor@.service</filename>, which applies to all instances of

<filename>container@.target</filename>.</para></listitem>

systemctl = executable(

public_programs += systemctl

systemd_id128 = executable(

public_programs += systemd_id128

if want_tests != 'false'

test('test-systemctl-enable',

test_systemctl_enable_sh,

# https://github.com/mesonbuild/meson/issues/2681

args : [systemctl.full_path(),

systemd_id128.full_path()])

static int verify_conditions(char **lines, LookupScope scope, const char *unit, const char *root) {

if (arg_scope != LOOKUP_SCOPE_SYSTEM) {

bool use_full_bus = arg_scope == LOOKUP_SCOPE_SYSTEM;

if (use_full_bus || arg_scope != LOOKUP_SCOPE_SYSTEM) {

LookupScope scope,

LookupScope scope,

arg_scope == LOOKUP_SCOPE_SYSTEM ? "" : " --user");

if (arg_scope == LOOKUP_SCOPE_SYSTEM && times.security_start_time > 0) {

r = lookup_paths_init_or_warn(&lp, arg_scope, 0, NULL);

return r;

r = lookup_paths_init_or_warn(&paths, arg_scope, 0, NULL);

return r;