On March 27, 2014 11:20:04 AM GMT+02:00, "Thomas Bächler" <thomas@archlinux.org> 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