On March 27, 2014 11:20:04 AM GMT+02:00, "Thomas Bächler" <thomas@xxxxxxxxxxxxx> wrote: >Am 27.03.2014 09:41, schrieb Gesh: >> Basically, if I understood what happens correctly, the units under >/etc/systemd/system/*.wants/ - or their targets, if they're symlinks - >replace their corresponding units in the dependency graph. > >Not exactly. > >When you place a unit in foo.wants, then foo gets an additional Wants= >dependency. Basically, this is a way to extend units with new Wants= >and >Requires= statements without modifying unit files. You don't *replace* >the dependency graph, but *extend* it. > But what if bar.unit Wants=foo.unit and I add a custom foo.unit to bar.unit.wants/ ? Will both be run? Will the custom foo.unit replace the built-in? >> In addition, all unit files are installed to >/usr/lib/systemd/system/, > >Unit files can also be installed to /etc/systemd/system/, for example >if >you want to use a modified version of a system-supplied unit file. > I meant in the sense of convention. Of course a sysadmin can drop units into /etc. It's its entire raison d'être. >When you run start or enable on a unit name, system looks into those >directories, taking the first one it finds. > >/run/systemd/generator.early >/etc/systemd/system >/run/systemd/system (*) >/run/systemd/generator (*) >/usr/lib/systemd/system >/run/systemd/generator.late > >I am not 100% sure if I got the order of the ones marked with (*) >right. > >As you can see here, there are units installed by the package manager >(/usr/lib), units installed by the admin (/etc), temporary units >installed either by automatic tools or by the admin >(/run/systemd/system) and units installed by generators during systemd >startup or reload (/run/systemd/generator*). > >Again, backing up the ones in /usr/lib does not make sense since those >are contained in packages and can be reinstalled. Backing up the ones >in >/run makes no sense either since they only live until you reboot (or >reload the configuration, in the case of generator units). However, >backing up /etc/systemd/system entirely (not just the symlinks) make >lots of sense, since the admin is likely to have custom units in there. > >> and the symlinks must have the same name as their targets, so only >the symlinks' names need to be backed up. > >Not necessarily. For example, >/etc/systemd/system/display-manager.service points to >/usr/lib/systemd/system/kdm.service. Most symlinks have the same name, >but that's only convention, not necesity. > >> Therefore, only what's under /etc/systemd/system/ needs to be backed >up, ignoring symlinks' targets. > >I'd back up the symlinks including their targets. This makes it easier >to restore configuration. > So basically, you back up the directory under /etc not following symlinks, then when restoring use pkgfile, filenames and installed-package-list to determine what packages you need to reinstall to get those links working. >> Besides that, the .wants directories in /usr/lib/systemd/system/ are >managed by pacman, and represent upstream decisions to automatically >start their units. > >Indeed. OK. I assume the links under /etc are generated by systemctl when enabling a unit with an [Install] section? Thanks for the clarifications, Gesh
