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 "Before=". 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. Thank you, WaLyong Cho. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
