<br>On Sunday, February 10, 2019, Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com">arvidjaar@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">09.02.2019 21:45, Matt Schuckmann пишет:<br>
> I have an embedded system with a readonly rootfs.<br>
> <br>
> I've setup a very early service that mounts a writable aufs overlay over /etc/.<br>
> <br>
> <br>
> The problem I'm having is systemd is not starting any services that I have enabled in that overlay that were not initially enabled in the readonly rootfs.<br>
> <br>
> ?I've tried placing a calls to systemctl daemon-reload or systemctl daemon-reexec just after mounting the overlay but the services are not started, after the fact systemctl will report that the services are enabled but inactive.<br>
> <br>
<br>
If you are doing it as part of normal startup, then systemd has already<br>
computed initial "transaction". While daemon-reload makes it rescan for<br>
and see additional unit definitions, it does not change currently<br>
running "transaction".<br>
<br>
> <br>
> What do I need to do to get systemd to automatically start the services that are marked enabled in that overlay?<br>
> <br>
<br>
I am not aware of any clean way to do it. Attempting to re-queue start<br>
of default.target will likely be noop as this request is already queued.</blockquote><div><br></div><div>Unless I am misunderstanding something (in the code), it wouldn't be a noop. After the reload/reexec, systemd should have updated the Wants=/Requires= property of target. Now, the transaction that was activated previously will not change based on this (because it was computed in the past, checked for consistency, minimised for impact, jobs merged/collapsed and then activated). At this point, there isn't even a transaction, it's just a set of jobs installed on units waiting on each other in run queue.</div><div><br></div><div>However, systemd, if you happen to trigger a start job on default.target replacing the installed job now, will compute a transaction again, and trigger jobs for everything again. Since this is all across transactions, this will result in another transaction being applied, duplicate jobs produced in both getting merged in installed one, but also the enabled units starting up, with new jobs installed for those.</div><div><br></div><div>So invoking a 'systemctl start default.target --job-mode replace' again will make the enabled units start up.</div><div><br></div><div>However, this has one disadvantage: You may end up having start jobs triggered for already started->inactive units again (think oneshots) (because there jobs slots are free after it finishing, so nothing to coalesce, hence a trigger again). For running units, state change is noop so it installs and finishes immediately. Where this can be surprising is later activation triggers a stop job for some unit enabled on boot (through Conflicts=, PartOf=), and then you end up trigger a start for it again, producing incorrect results.</div><div><br></div><div>Still, all this said, it would be more correct to do it from initramfs as grawity suggests, and then have all of this computed as part of initial transaction at boot.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The only workaround I can think of is to make initial boot into target<br>
that mounts overlay and then triggers start of actual default target.<br>
______________________________<wbr>_________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/systemd-devel</a><br>
</blockquote>