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
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 <lenn...@poettering.net>
>> On Do, 09.08.18 10:20, Daniel Wang (wonder...@google.com) wrote:
>>> 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
>> /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 Poettering, Red Hat
> systemd-devel mailing list
systemd-devel mailing list