Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Lennart Poettering]

On Mon, 06.06.16 14:56, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> On Mon, Jun 6, 2016 at 2:26 PM, Martin Pitt  wrote:
> > Andrei Borzenkov [2016-06-06 13:55 +0300]:
> >> What is advantage in having static *.wants etc directories in
> >> /usr/lib/systemd vs. Wants etc directives directly in unit definition?
> >> They complicate troubleshooting (you no more have complete definition
> >> by looking just at unit source), they complicate building (extra steps
> >> to install them); what are they good for?
> >
> > These are much simpler to ship in packages than shipping a
> > foo.service.d/mywants.conf with "Wants=".
> 
> Sorry I had to be more clear. What is advantage of shipping them in
> systemd? Systemd has well defined early boot services that are always
> needed. Why they are shipped as links instead of actually expressing
> those mandatory dependencies in unit definitions themselves?

Well, downstream can split up the RPMs/DEBs in a multitude of
ways. For example, things like udev, rfkill, backlight could be split
into one subpackage that is only installed on physical systems but not
when run in a container, as those three services only make sense if
your system runs on physical hardware. How downstream decides to split
things up into RPMs is really up to them, but we should make it easy
to make the modules separate enough to support this.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Simon McVittie]

On 06/06/16 15:17, Martin Pitt wrote:
> Of course it could also just do the usual WantedBy= in the unit and
> call systemctl enable on installation (that's what the Debian package
> does)

Most Debian packages with systemd services do this, but there are
exceptions.

> but there are cases where you don't really want to make the
> enablement configurable by the admin.

One example of this is dbus.service, which is statically enabled by
shipping symlinks in /lib/systemd/system in the .deb (as befits its "OS
infrastructure" status, in particular as something that is used by other
systemd components).

Conversely, polkitd.service is statically *disabled* (it doesn't ship
symlinks in the .deb and doesn't have a WantedBy), so it can be started
on-demand via D-Bus activation, but is never started "eagerly" during
boot (there would be no point).

-- 
Simon McVittie
Collabora Ltd. 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Martin Pitt]

Andrei Borzenkov [2016-06-06 14:56 +0300]:
> Sorry I had to be more clear. What is advantage of shipping them in
> systemd? Systemd has well defined early boot services that are always
> needed. Why they are shipped as links instead of actually expressing
> those mandatory dependencies in unit definitions themselves?

I didn't mean links in the systemd package itself, but other packages
which want to hook into targets or services. E. g. the network-manager
package could ship a
network-online.target.wants/network-manager.service symlink.

Of course it could also just do the usual WantedBy= in the unit and
call systemctl enable on installation (that's what the Debian package
does), but there are cases where you don't really want to make the
enablement configurable by the admin.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Andrei Borzenkov]

On Mon, Jun 6, 2016 at 2:26 PM, Martin Pitt  wrote:
> Andrei Borzenkov [2016-06-06 13:55 +0300]:
>> What is advantage in having static *.wants etc directories in
>> /usr/lib/systemd vs. Wants etc directives directly in unit definition?
>> They complicate troubleshooting (you no more have complete definition
>> by looking just at unit source), they complicate building (extra steps
>> to install them); what are they good for?
>
> These are much simpler to ship in packages than shipping a
> foo.service.d/mywants.conf with "Wants=".


Sorry I had to be more clear. What is advantage of shipping them in
systemd? Systemd has well defined early boot services that are always
needed. Why they are shipped as links instead of actually expressing
those mandatory dependencies in unit definitions themselves?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Jan Alexander Steffens]

On Mon, Jun 6, 2016 at 1:27 PM Martin Pitt  wrote:

> Andrei Borzenkov [2016-06-06 13:55 +0300]:
> > What is advantage in having static *.wants etc directories in
> > /usr/lib/systemd vs. Wants etc directives directly in unit definition?
> > They complicate troubleshooting (you no more have complete definition
> > by looking just at unit source), they complicate building (extra steps
> > to install them); what are they good for?
>
> These are much simpler to ship in packages than shipping a
> foo.service.d/mywants.conf with "Wants=". In both cases the .service
> isn't completely self-contained but extended with an external file,
> but the symlinks are structurally simpler.
>

 Also, the conf snippets were introduced later. That said, the way symlinks
in these directories are handled is a bit weird. IIRC only the name of the
link matters, unless a unit by that name isn't known already, in which case
it's loaded through the link.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Martin Pitt]

Andrei Borzenkov [2016-06-06 13:55 +0300]:
> What is advantage in having static *.wants etc directories in
> /usr/lib/systemd vs. Wants etc directives directly in unit definition?
> They complicate troubleshooting (you no more have complete definition
> by looking just at unit source), they complicate building (extra steps
> to install them); what are they good for?

These are much simpler to ship in packages than shipping a
foo.service.d/mywants.conf with "Wants=". In both cases the .service
isn't completely self-contained but extended with an external file,
but the symlinks are structurally simpler.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Andrei Borzenkov]

What is advantage in having static *.wants etc directories in
/usr/lib/systemd vs. Wants etc directives directly in unit definition?
They complicate troubleshooting (you no more have complete definition
by looking just at unit source), they complicate building (extra steps
to install them); what are they good for?

This is precisely about static links in /usr/lib, not about admin
overrides in /etc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel