Re: [systemd-devel] systemd: questions about dbus dependency service
On Mo, 04.12.23 13:01, Pintu Agarwal (pintu.p...@gmail.com) wrote: > Hi, > Any comments or suggestions on the below ? I already replied. https://lists.freedesktop.org/archives/systemd-devel/2023-November/049706.html Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd: questions about dbus dependency service
Hi, Any comments or suggestions on the below ? On Tue, 28 Nov 2023 at 22:48, Pintu Agarwal wrote: > > Hi, > > I need some clarification about systemd services that are dependent on dbus > service. > > We have a service that depends on dbus.service, so our service has to be > started after dbus.socket and dbus.service. > But dbus.service comes after local-fs.target and sysinit.target. > However, our service needs to be started very early on boot-up, maybe within > local-fs target itself, otherwise it is causing regression in our boot KPI. > > How can we solve this issue in the most efficient way? > > We are using Linux Kernel 5.15 with arm64 and a high speed quad-core > processor. > Also, the storage type is NAND with limited speed (12.5 MBPS). > The filesystem is UBI + squashfs volumes. > > Thanks, > Pintu
Re: [systemd-devel] systemd: questions about dbus dependency service
On Di, 28.11.23 22:48, Pintu Agarwal (pintu.p...@gmail.com) wrote: > Hi, > > I need some clarification about systemd services that are dependent on dbus > service. > > We have a service that depends on dbus.service, so our service has to be > started after dbus.socket and dbus.service. It's usually a good idea to not wait for dbus.sevice. Waiting for dbus.socket is sufficient, it makes sure clients can connect to D-Bus (even if dbus needs to finish starting up to respond to it). This will increase parallelization during boot. > But dbus.service comes after local-fs.target and sysinit.target. > However, our service needs to be started very early on boot-up, maybe > within local-fs target itself, otherwise it is causing regression in our > boot KPI. dbus is not a suitable IPC for early boot services, unless you speak the dbus protocol directly between client and service, without involving the broker. But that's messy. systemd's PID 1 does this (i.e. dbus without a broker), because it must be accessible early on, but I hate that code, and I'd rather kill it. In new code that must run in early boot we usually use a different IPC (varlink), that does not involve any broker, and thus always works. Lennart -- Lennart Poettering, Berlin
[systemd-devel] systemd: questions about dbus dependency service
Hi, I need some clarification about systemd services that are dependent on dbus service. We have a service that depends on dbus.service, so our service has to be started after dbus.socket and dbus.service. But dbus.service comes after local-fs.target and sysinit.target. However, our service needs to be started very early on boot-up, maybe within local-fs target itself, otherwise it is causing regression in our boot KPI. How can we solve this issue in the most efficient way? We are using Linux Kernel 5.15 with arm64 and a high speed quad-core processor. Also, the storage type is NAND with limited speed (12.5 MBPS). The filesystem is UBI + squashfs volumes. Thanks, Pintu
