[systemd-devel] How to add a unit path to systemd?

[Andrei Borzenkov]

10.08.2018 20:10, Daniel Wang пишет:
>> Alternatively, you actually can issue daemon reload during the
> boot process
> 
> Suppose I use a systemd service (say foo.service) to do this, is it a
> supported/recommended practice to do a daemon reload as part of a unit's
> activation (i.e., through its ExecStart)?

>From practical experience - there is slow but constant stream of bug
fixes related to daemon-reload. It is supposed to be transparent, but it
*is* losing parts of systemd state.

So my personal opinion - daemon-reload is suitable for one-off task in
mostly static controlled environment (like updating in-memory unit
definition after editing on-disk file after initial boot was completed),
but using it during high volume activity like system boot increases
chances of misbehavior. Problems caused by daemon-reload are rather hard
to diagnose and reproduce (as they are highly dynamic - you need to hit
the right bug in the right moment).

Nor do I think that daemon-reload was ever even designed for such use cases.

> I want my new units to block default.target. Is it safe to issue a
> `systemctl start default.target` with foo.service' ExecStart or
> ExecStartPost?
> 

Yes, it is used in real life. This is big hammer that must be used
because systemd is too inflexible to support dynamic changes after (or
even during) initial boot.

> 
> On Fri, Aug 10, 2018 at 3:30 AM Lennart Poettering <lennart at poettering.net>
> wrote:
> 
>> On Do, 09.08.18 10:20, Daniel Wang (wonderfly at google.com) wrote:
>>
>>> Hi,
>>>
>>> I want to append to systemd's unit search path a directory on my OEM
>>> partition, which is mounted  by a .mount unit, at /usr/share/. I will be
>>> putting unit files in that partition, some of which I want to run before
>>> default.target. Is it possible to do so without a systemctl
>>> daemon-reload?
>>
>> /usr/share appears like a surprising place for this…
>>
>> In general, in systemd the assumption is that unit files are available
>> during earliest boot, so that the initial transaction can be
>> calculated with all units taken into account. Hence a relatively clean
>> solution might be to mount your partition already in the initrd, so
>> that systemd sees it in place already.
>>
>> Alternatively, you actually can issue daemon reload during the boot
>> process, but you'd have to enqueue the new units appearing explicitly,
>> i.e. trigger a second transaction because what isn't there won't be
>> considered in the initial one.
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
>>
> 
> 
> 
> 
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>