On Fri, 17.04.15 14:06, Matt Hoosier ([email protected]) wrote: > The bootcharting that I do seems to show that about 1.2 - 1.5 sec are spent > internal to systemd before any external processes get run for the > particular embedded CPU I'm using. That gap is a killer at the moment. > > I'm sure this is quite the naive question, but: is there a simple option I > can insert into my "super-important" first service that would cause all > other units to be forestalled until my service reports that it's > initialized? I.e., something like: > > [Unit] > DefaultDependencies=no > Before=very-first-normal-systemd-unit.service > > I didn't have luck identifying such a > very-first-normal-systemd-unit.service on my own, but I'm admittedly rather > inexperienced poking around the internal default suite of units packaged > with systemd.
This is not available, though often requested. But I doubt this can ever work, since "running before 'everything'" or "running after 'everything'" is not particularly usefully defined as this all breaks down as soon as you have two services that want to be run like this. The right way is usually to simply add the right deps of the stuff you really want to be run before. That all said, I would be open to adding a "priority" concept to units: if we are about to fork off a large number of processes at the same time we do so sequentially but provide no control currently about the order then. I'd be open making this configurable with a priority values that can ensure we fork off some things before others when both are runnable. This would not really fix your issue, sicne it wouldn't really delay any other services, it would only configure the order of the fork()s, but they'd still take place in a tight loop. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
