[arch-general] Configuring enabled services
sean at seangreenslade.com
Wed Mar 26 20:51:22 EDT 2014
On Thu, Mar 27, 2014 at 12:13:08AM +0200, Gesh wrote:
> On March 19, 2014 9:16:57 PM GMT+02:00, Ary Kleinerman <akleinerman at buinet.com.ar> wrote:
> >> There's not really much magic going on. Are you aware of:
> >> /etc/systemd/system
> >> This contains symlinks that do already pretty much what you describe,
> >and this
> >> is systemd's native configuration.
> >Don't forget
> >/run/systemd/system: Runtime units and /usr/lib/systemd/system: Units
> >of installed packages
> Thanks for the pointers. If I understand what's going on correctly,
> units specify in their [Install] section whether, when they're
> enabled, they should be pulled in by other units. Those symlinks
> usually populate the appropriate directory under
Systemd builds a dependency tree, starting at the initial boot target.
This target is usually called "default.target". From there, dependencies
are pulled in based on the deps listed in the various targets. Some
targets, such as multi-user.target, specify a folder called
multi-user.target.wants that contains units that the target "wants,"
i.e. are soft dependencies of it. So to enable a unit on startup, it
needs to be made a dependency (either a "want" or a "need") of a target
that is pulled in by the boot dependency tree. Those symlinks in the
[Install] section add the unit to the dependency list of the folder's
unit. (This is usually multi-user.target). But units do not _need_ this
type of symlink to be pulled in. If a dependency is hard-coded into a
unit that is part of the startup tree, it will be started.
> Besides that, some packages install
> symlinks under /usr/lib/systemd/system/ as part of their files to
> get pulled in by other units without requiring user intervention.
There's nothing special about symlinks, as I mentioned above. But yes,
if a package wants to have itself enabled on boot by default, it can
insert a symlink to its unit file into the .wants folder in
> Finally, systemctl list-unit-files will list all unit files with their
> enabled/disabled/static status, where static means that they run by
> default (when pulled in) and disabled means they can be installed -
> that is, they have an [Install] section - but haven't been yet. And
> systemctl enable/disable manages the symlinks under
> /etc/systems/system specified by the [Install] section. Is my
> understanding of the situation correct?
As for the static/active/disabled terminology, see . The systemctl
enable/disable thing is just a handy way of managing the symlinks. If a
unit does not have an [Install] section, systemctl enable/disable will
do nothing. The unit can still be enable by manually symlinking, of
Hope this helped.
More information about the arch-general