Message ID | 20221020135531.57483-1-arturo.buzarra@digi.com |
---|---|
State | New |
Headers | show |
Series | run-postinsts: Set dependency for ldconfig to avoid boot issues | expand |
On Thu, Oct 20, 2022 at 6:56 AM abuzarra via lists.openembedded.org <Arturo.Buzarra=digi.com@lists.openembedded.org> wrote: > > If a package with a postsints script requires ldconfig, the package class adds > a ldconfig postinst fragment to initialize it before. Systemd has its own > ldconfig.service to initialize it and sometimes if both services are running > at the same time in the first boot, the first one will work, but the second > one will fail with the following error: > > ldconfig[141]: /sbin/ldconfig: Renaming of /etc/ld.so.cache~ to /etc/ld.so.cache failed: No such file or directory > > This commit adds a ordering dependency between them to make sure that only one > service is running at the same time. > > Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com> > --- > .../run-postinsts/run-postinsts/run-postinsts.service | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service > index 7f72f3388a..b6b81d5c1a 100644 > --- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service > +++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service > @@ -1,9 +1,9 @@ > [Unit] > Description=Run pending postinsts > DefaultDependencies=no > -After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount > +After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount ldconfig.service ldconfig is not always enabled, it's controlled via a DISTRO_FEATURE so this will fail for such systems. Maybe adding it conditionally via a systemd unit fragment drop-in file would be a better way to go. > Before=sysinit.target > > [Service] > Type=oneshot > ExecStart=#SBINDIR#/run-postinsts > -- > 2.38.0 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#171992): https://lists.openembedded.org/g/openembedded-core/message/171992 > Mute This Topic: https://lists.openembedded.org/mt/94453597/1997914 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Thu, 20 Oct 2022 at 17:08, Khem Raj <raj.khem@gmail.com> wrote: > > -After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount > > +After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount ldconfig.service > > ldconfig is not always enabled, it's controlled via a DISTRO_FEATURE > so this will fail for such > systems. Maybe adding it conditionally via a systemd unit fragment > drop-in file would be a better way to go. But will it fail? I thought Requires= is the hard dependency, and After= sets only the ordering, but not dependencies. Alex
On Thu, Oct 20, 2022 at 8:18 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Thu, 20 Oct 2022 at 17:08, Khem Raj <raj.khem@gmail.com> wrote: > > > -After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount > > > +After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount ldconfig.service > > > > ldconfig is not always enabled, it's controlled via a DISTRO_FEATURE > > so this will fail for such > > systems. Maybe adding it conditionally via a systemd unit fragment > > drop-in file would be a better way to go. > > But will it fail? I thought Requires= is the hard dependency, and > After= sets only the ordering, but not dependencies. > Good question. After= will wait for dependency but not explicitly activate it whereas Requires= will activate it as well if it's not activated yet. I think it's best to try this unit on a system without ldconfig.service for finding the exact behaviour. > Alex
On Thu, 20 Oct 2022 at 17:27, Khem Raj <raj.khem@gmail.com> wrote: > Good question. After= will wait for dependency but not explicitly > activate it whereas Requires= will > activate it as well if it's not activated yet. I think it's best to > try this unit on a system without ldconfig.service > for finding the exact behaviour. 'man systemd.unit' seems to say that the wait will only happen if the dependency is being started for some reason, including reasons unrelated to this unit. It stops just short of saying what happens if the dependency is not going to start at all (which would be 'nothing happens, this unit simply starts'). Not a well written description, there. Alex
On Thu, Oct 20, 2022 at 8:37 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Thu, 20 Oct 2022 at 17:27, Khem Raj <raj.khem@gmail.com> wrote: > > Good question. After= will wait for dependency but not explicitly > > activate it whereas Requires= will > > activate it as well if it's not activated yet. I think it's best to > > try this unit on a system without ldconfig.service > > for finding the exact behaviour. > > 'man systemd.unit' seems to say that the wait will only happen if the > dependency is being started for some reason, including reasons > unrelated to this unit. It stops just short of saying what happens if > the dependency is not going to start at all (which would be 'nothing > happens, this unit simply starts'). Not a well written description, > there. right. thats why I think its good to try it out > > Alex
Hi Arturo Thanks for the patch! On 10/20/22 15:55, abuzarra via lists.openembedded.org wrote: > If a package with a postsints script requires ldconfig, the package class adds > a ldconfig postinst fragment to initialize it before. Systemd has its own > ldconfig.service to initialize it and sometimes if both services are running > at the same time in the first boot, the first one will work, but the second > one will fail with the following error: > > ldconfig[141]: /sbin/ldconfig: Renaming of /etc/ld.so.cache~ to /etc/ld.so.cache failed: No such file or directory > > This commit adds a ordering dependency between them to make sure that only one > service is running at the same time. > > Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com> > --- > .../run-postinsts/run-postinsts/run-postinsts.service | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) There's a problem with the way your patches are received. I used to have it too. If I apply your patch through "git am", the author of the commit will be: abuzarra via lists.openembedded.org <Arturo.Buzarra=digi.com@lists.openembedded.org> instead of Arturo Buzarra <arturo.buzarra@digi.com> Because of this issue, the maintainer has to manually fix this field when accepting your patch. Worse, if he doesn't catch this, that's harder to fix afterwards. You should be able to fix this by running: git config --global sendemail.from "arturo.buzarra@digi.com" This should add a "From" field to the sent patch which "git am" should be able to match with your name. See https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Sending_using_git-send-email Could you try to send an update? You could send it to me again through private-email first. Thanks in advance Michael.
I actually ran across this issue myself and was wondering what the status is. Since it seems the patch is not included yet, but I've tested it on our systems and it does seem to prevent the issue. Unless I've missed another fix/patch someplace else that makes this one redundant. About the "After=" discussion, "After" should only affect the ordering of jobs that are scheduled, but not actually start any by itself. Therefore it should be fairly save to include this patch. Sincerely, Jermain Horsman
diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service index 7f72f3388a..b6b81d5c1a 100644 --- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service +++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service @@ -1,9 +1,9 @@ [Unit] Description=Run pending postinsts DefaultDependencies=no -After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount +After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount ldconfig.service Before=sysinit.target [Service] Type=oneshot ExecStart=#SBINDIR#/run-postinsts
If a package with a postsints script requires ldconfig, the package class adds a ldconfig postinst fragment to initialize it before. Systemd has its own ldconfig.service to initialize it and sometimes if both services are running at the same time in the first boot, the first one will work, but the second one will fail with the following error: ldconfig[141]: /sbin/ldconfig: Renaming of /etc/ld.so.cache~ to /etc/ld.so.cache failed: No such file or directory This commit adds a ordering dependency between them to make sure that only one service is running at the same time. Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com> --- .../run-postinsts/run-postinsts/run-postinsts.service | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)