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@xxxxxxxxxxxxx> 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. > >> > >Paul, > >Don't forget > >/run/systemd/system: Runtime units and /usr/lib/systemd/system: Units > >of installed packages > > > >Regards, > >Ary > > 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 > /etc/systemd/system/. 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 /usr/lib/systemd/system. > 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 [1]. 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 course. > Thanks, > Gesh Hope this helped. --Sean [1] https://bbs.archlinux.org/viewtopic.php?pid=1153751#p1153751
