systemd debug (embedded case)

Question

How to trace systemd unit files, to be specific, device unit files? I use 3.18 version of linux kernel. On my board after systemd has started, (mypartition).device runs and, I suppose, remounts the rootfs and it takes about 2 seconds to complete as systemd-analyze plot shows. I want to know what it does during those 2 seconds, because remounting of rootfs takes not so much time (usually few milliseconds). How I can understand systemd-analyze plot, there are so many unit files, is it possible to know which unit causes running of the others? I tried to find .device unit file in my system, but I could not find anything.

Answer 1

Kernel version 3.18 was released in December 2014, so it's quite old. It was one of the Long-Term Support kernels and may still receive irregular updates from Greg Kroah-Hartman even though the "official" End-Of-Life for this kernel version was in January 2017. Because of this, the kernel version is not necessarily a reliable indicator of the age of any other OS components anyway, especially on embedded systems.

What does your system report with systemctl --version?

On modern versions of systemd, filesystem mounting is handled by the *.mount units. Specifically, to view the contents of the root filesystem mount unit, -.mount, you'll need systemctl cat -- -.mount to force the interpretation of -.mount as a unit name (instead of an option). With that command, you should see that the mount unit will have an automatic After= ordering dependency on the device/target representing the device containing the root filesystem.

The *.device units appear as a device is detected by the kernel and gains its representation in the /sys virtual filesystem and the udev-maintained device nodes (when applicable, e.g. network devices are handled without device nodes).

The *.device units are typically all autogenerated, so you won't normally find any *.device unit files anywhere. Instead, udev rules may influence the creation of a device unit: for example, if an udev rule sets the property SYSTEMD_READY=0 for a device, the device creation is omitted until that property is removed or changed to SYSTEMD_READY=1. See man systemd.device for more details.

Essentially, the *.device units exist to represent hardware devices, mostly so that other units will be able to define dependencies on them. By default, the device units won't depend on any other units; instead, they will by definition "depend" on the userspace-accessible device they represent.

The 2 seconds you're seeing might be from any combination of the following operations:

• detection and preparation of the bus that contains the disk controller (if applicable for your system architecture)
• detection and resetting of the disk controller itself
• detection and resetting of the disk(s) as the Linux kernel driver takes over control of it, to get the disk into a known state after whatever operations the system firmware may have already done with it (this probably takes the most of the 2 seconds, as disks may have extensive internal self-test routines they'll run at reset)
• reading, identifying and processing the partition table on the disk (the Linux kernel supports several partition table formats: depending on hardware architecture, more than one of them might be applicable)