[systemd-devel] [PATCH] core: add default extra dependency option
walyong.cho at samsung.com
Fri Feb 28 03:45:35 PST 2014
On 02/28/2014 06:16 PM, Thomas Bächler wrote:
> Am 28.02.2014 10:02, schrieb WaLyong Cho:
>> systemd is already provide a special unit. If the type of unit is
>> service then that is 'basic.target'. Additionally default extra
>> dependency can be listed in system.conf and then other service unit will
>> have "After=" dependency implicitly.
>> In config directory /etc/systemd/default-extra-dependencies, if a
>> service unit is listed ignore-units or exist symlink in ignore-units.d
>> then the service units can be launched before extra dependencies.
> I am confused about the motivation here. This change adds several extra
> configuration primitives - one in system.conf, a new directory, and a
> mechanism to opt out of the new configuration. This is quite a lot for
> something that I find marginally useful at best. I think this
> functionality even enables an administrator to unwillingly break his
> system - setting this option likely has many unforeseen consequences,
> depending on the installed services.
This is just for optimizing boot up speed extremely. systemd said
"systemd provides aggressive parallelization capabilities," and
according to this too many service could race each on boot up time. This
functionality may be useless in desktop environment. However, it is
different in the embedded environment. Generally, in embedded, system is
made up with lower performance hardware. But User want to boot up his
device in short time. Actually, the boot up may be continued after some
of service(what listed config). But if the others are not important to
user then this functionality will be useful.
As we are concerned, this functionality can break boot order.
But, unlike desktop, additional package will rarely NOT be installed
after product in embedded device. So in embedded environment,
administrator(s) will try to rearrange service launching order (like
me). If some of services wants be started before others then this
functionality can be useful. If not, that service should list others on
According to this, circular dependency can be occurred easily. But as I
said, administrator or user (who well know about systemd.) will solve
such circular dependency problem easily.
Don't worry, if the service unit have "DefaultDependencies=no" that will
ignore this dependency.
> Furthermore, the configuration only affects .service units, but that is
> not reflected in any of the option names, suggesting it is a
> configuration that would affect *any* unit. Why should this
> functionality exist for .service units, but not for others?
> What's the reason you want to add new dependencies to all units at the
> same time?
Most other type of units(mount, socket, timer, path and etc) are
processed ahead of boot. And most of them are not optional. They are
mandatory. So if this implicit dependency adding is also applied to
other type then more dependency break will be occurred.
More information about the systemd-devel