[arch-general] Configuring enabled services
Dear all, I've been rereading the old arguments on the rc.conf split. Disregarding everything discussed there, one interesting point came up during that discussion.[1] Is it possible to have some configuration file, e.g. /etc/systems/services.conf that would list all the units one wants to be enabled at boot? This would both simplify backups and reduce the magic of and dependence on systemctl. Is there any reason this can't or shouldn't be done? With best regards, Gesh [1] - http://permalink.gmane.org/gmane.linux.arch.general/43459
On Wednesday 19 Mar 2014 12:52:55 Gesh wrote:
Dear all, I've been rereading the old arguments on the rc.conf split. Disregarding everything discussed there, one interesting point came up during that discussion.[1] Is it possible to have some configuration file, e.g. /etc/systems/services.conf that would list all the units one wants to be enabled at boot? This would both simplify backups and reduce the magic of and dependence on systemctl. Is there any reason this can't or shouldn't be done? With best regards, Gesh [1] - http://permalink.gmane.org/gmane.linux.arch.general/43459
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
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
On March 19, 2014 9:16:57 PM GMT+02:00, Ary Kleinerman <akleinerman@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.
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/. 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. 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? Thanks, Gesh
That is correct, when you call `systemctl enable foo.unit` then the [Install] section of the unit file is "executed". "Static" means that the unit has no [Install] section, meaning it is permanently enabled/disabled as far as the systemctl enable/disable tool is concerned. Other than pulling themselves in when other units start, a unit can also symlink another unit name to itself using the Alias= option, and specify other units to enable/disable as a group using the Also= option. On 27 March 2014 07:13, Gesh <gesh@gesh.uni.cx> wrote:
On March 19, 2014 9:16:57 PM GMT+02:00, Ary Kleinerman <akleinerman@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.
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/. 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. 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? Thanks, Gesh
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@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.
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
Am 26.03.2014 23:13, schrieb Gesh:
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/. 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.
What this means for backing up the configuration is that you simply back up /etc/systemd/system without resolving symlinks (and ignore that those symlinks point to paths outside of your backup). rsync can do that for you. This has the benefit of also backing up all permanent unit overrides and drop-ins that the admin may have made.
On March 27, 2014 9:25:24 AM GMT+02:00, "Thomas Bächler" <thomas@archlinux.org> wrote:
Am 26.03.2014 23:13, schrieb Gesh:
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/. 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.
What this means for backing up the configuration is that you simply back up /etc/systemd/system without resolving symlinks (and ignore that those symlinks point to paths outside of your backup). rsync can do that for you. This has the benefit of also backing up all permanent unit overrides and drop-ins that the admin may have made.
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. In addition, all unit files are installed to /usr/lib/systemd/system/, and the symlinks must have the same name as their targets, so only the symlinks' names need to be backed up. Therefore, only what's under /etc/systemd/system/ needs to be backed up, ignoring symlinks' targets. Besides that, the .wants directories in /usr/lib/systemd/system/ are managed by pacman, and represent upstream decisions to automatically start their units. Is this understanding correct? Thank you for your time, Gesh
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.
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. 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.
Besides that, the .wants directories in /usr/lib/systemd/system/ are managed by pacman, and represent upstream decisions to automatically start their units.
Indeed.
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
Am 27.03.2014 13:26, schrieb Gesh:
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?
I don't know what happens if you try, but there can only be one unit of the same name.
Am 19.03.2014 20:16, schrieb Ary Kleinerman:
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
/usr/lib/systemd only contains configuration managed by the package manager and /run/systemd contains only runtime configuration - this is all irrelevant for backups.
participants (6)
-
Ary Kleinerman
-
Emil Lundberg
-
Gesh
-
Paul Gideon Dann
-
Sean Greenslade
-
Thomas Bächler