[systemd-devel] How to add a unit path to systemd?
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? I understand I could configure systemd at compile time, or use the SYSTEMD_UNIT_PATH env var at the kernel command line, but since /usr/share/ is probably mounted _after_ default.target is first referenced (?), they won't do what I need? -- Best, Daniel smime.p7s Description: S/MIME Cryptographic Signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add a unit path to systemd?
On Do, 09.08.18 10:20, Daniel Wang (wonder...@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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add a unit path to systemd?
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 > wrote: > >> On Do, 09.08.18 10:20, Daniel Wang (wonder...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add a unit path to systemd?
On Fr, 10.08.18 10:31, Filipe Brandenburger (filbran...@google.com) wrote: > Hi Lennart, > > On Fri, Aug 10, 2018 at 3:30 AM Lennart Poettering > wrote: > > 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 > > > 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. > > I was pointing Daniel at the /usr/share/factory support in tmpfiles, > which will populate a system with /var and /etc and I believe that > includes enabling units and applying presets. No, that's not correct. Units are enabled via presets from PID 1 during earliest boot, before we start looking for unit files to load. The factory stuff is copied as part of systemd-tmpfiles.service, i.e. much later during boot (though still in the "early" boot phase, i.e. before basic.target has been reached). This means most regular configuration files can be installed via factory, but the ones PID 1 needs itself can't, and that includes unit files. > How do things work in that case? Is there an implicit daemon-reload > that happens once /etc is populated from /usr/share/factory/etc? It doesn't. Unit files can't be installed via the factory logic. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add a unit path to systemd?
On Fr, 10.08.18 10:10, Daniel Wang (wonder...@google.com) wrote: > > 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)? > 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? We generally design our stuff to not require PID 1 daemon reload as part of the normal boot-time code paths. So no, it's not precisely "recommended practice" to do this, but it should work OK with current systemd versions. (That said, the initrd *does* issue a reload after mounting the root fs, in order to pull in some bits and pieces from the root fs — such as the root fs' /etc/fstab — before proceeding, but I'd argue this is a very special case, that is probably even unfortunate but kinda unavoidable) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add a unit path to systemd?
On Sa, 11.08.18 10:21, Andrei Borzenkov (arvidj...@gmail.com) wrote: > 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. Not anymore. At this point if the individual unit files don't change across the reload it should be fully reliable to reload PID 1. What remains is the ambiguity if you change a unit file's set of ExecStart= lines and it is not clear where to proceed while systemd is executing one of them that doesn't exist anymore in the new version. In older systemd versions we'd avoid any ambiguity by always continuing with the frist ExecStart= line in a unit file after a reload, which was deterministic in a way, but pretty often wrong. > 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). I agree with this sentiment. It's better to keep "daemon-reload" out of the clean code paths of booting, and using it exclusively for exceptional code paths, i.e. during upgrades and reconfiguration. > Nor do I think that daemon-reload was ever even designed for such > use cases. That is pretty much true. (but see the initrd case, mentioned in the other mail) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
