[systemd-devel] Loading systemd units files at startup

[Mantas Mikulėnas]

On Wed, Jan 4, 2017 at 4:02 PM, Eswaran Vinothkumar (BEG-PT/PJ-IOT1) <
Vinothkumar.Eswaran at de.bosch.com> wrote:

> Hello systemd developers,
>
>
>
> Currently, I am working on a task to reduce the boot time of an embedded
> product. systemd is used as the init system. I have a couple of questions,
> could you please clarify?
>
>
>
> 1.   From the systemd-analyze plot, I am seeing that it takes around 2
> seconds to load the systemd unit files. Is there any way to reduce this
> time? I read a blog about systemd-readahead and systemd-replay services
> used in such cases to reduce the loading time, but it also have mentioned
> that the services are not maintained in the latest systemd versions. Is it
> advisable to use such services?
>
There still are other readahead implementations, although I doubt they'll
help at all if you're reading from flash memory... also, they usually run
as regular early services, after all units have loaded.

In fact, if something like *unit loading* is slow, you might have other
problems... Use systemd-bootchart or other similar tools to figure out
whether the loading is I/O-bound or CPU-bound. It could also be that some
*unit generators* take a long time to run – consider masking or outright
deleting some of them.

> 2.   There are some systemd services which are used mostly for debugging
> purposes, so I tried to mask those services. My question is if the service
> is masked , do the service files gets loaded during the systemd
> initialization? I have masked around 5 services but I am not seeing any
> reduction in the systemd unit files loading time though there is a
> considerable reduction in the overall boot time.
>
AFAIK, no; systemd stops looking after it finds the first matching unit.

You could also remove the unneeded unit files entirely and compare the
results. (But see reply to #1 first.)

> 3.       I have read that the preferred way to have the mount points is
> to write in /etc/fstab. This will create a *.mount file using
> systemd_fstab_generator. I am seeing that in the project for the debugfs
> there is a systemd mount file defined in  /lib/systemd/system/ and also an
> option present in /etc/fstab (‘*debugfs  /sys/kernel/debug  debugfs
> noauto 0 0’).*
>
On embedded systems, where you make your own rules, I'd say creating your
own mount units would be more direct and easier to debug – also possibly
avoiding a slow generator call.

(Though, on the other hand, some filesystems are mounted by
src/core/mount-setup.c before processing any units. Later on,
systemd-remount-fs applies options from fstab but not from custom .mount
units...)

Which file has precedence when the system is  initialized?
>
>
>
> /lib/systemd/system/sys-kernel-debug.mount
>
> or
>
> /run/systemd/generator/sys-kernel-debug.mount
>
>
fstab takes priority over packaged .mount units – it's one of the ways
sysadmins can override systemd default mount options.

The (mostly) full order is:

* /run/systemd/system
* /run/systemd/generator.early
* /etc/systemd/system
* /run/systemd/system
* /run/systemd/generator
* /usr/lib/systemd/system
* /lib/systemd/system
* /run/systemd/generator.late

See src/shared/path-lookup.c for the full (not-quite-documented) details.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170104/75b4f86f/attachment.html>